.NET Channel高效使用：Task.Run导致生产者消费者性能下降问题

请参考如下代码：

var channel = Channel.CreateUnbounded<int>(new UnboundedChannelOptions());

var t1 = Task.Run(async () =>
{
    DateTime start = DateTime.Now;

    for (int i = 0; i < 100000000; i++)
    {
        await channel.Writer.WriteAsync(i);
    }

    Console.WriteLine($"Writer took {DateTime.Now - start}");
    channel.Writer.Complete();
});

var t2 = Task.Run(async () =>
{
    while (true)
    {
        try
        {
            int r = await channel.Reader.ReadAsync();
        }
        catch (ChannelClosedException) { break; }
    }
});

await Task.WhenAll(t1, t2);

上述代码执行总耗时约10秒，控制台输出类似Writer took 00:00:10.276747的结果；如果将消费者逻辑的整个while代码块注释掉，写入操作仅耗时约6秒，多次运行测试结果稳定一致。

更值得注意的是，如果新增如下两个独立方法：

static async Task Produce(Channel<int> channel)
{
    DateTime start = DateTime.Now;

    for (int i = 0; i < 100000000; i++)
    {
        await channel.Writer.WriteAsync(i);
    }

    Console.WriteLine($"Writer took {DateTime.Now - start}");
    channel.Writer.Complete();
}

static async Task Consume(Channel<int> channel)
{
    while (true)
    {
        try
        {
            int r = await channel.Reader.ReadAsync();
        }
        catch (ChannelClosedException) { break; }
    }
}

随后按如下方式调用：

var t1 = Produce(channel);
var t2 = Consume(channel);
await Task.WhenAll(t1, t2);

无论是否注释消费逻辑的while代码块，代码执行耗时均稳定在6秒左右。

• Channel定位为高效的生产者/消费者实现机制，为何本场景下消费操作会拖慢生产者的执行效率？
• 为何显式通过Task.Run调度线程执行任务会影响Channel的运行效率？

消费操作拖慢生产者的核心原因 #

先明确UnboundedChannel的底层执行逻辑：无界Channel没有写入背压，WriteAsync几乎不会出现异步挂起的情况。但如果队列上存在等待中的消费者，WriteAsync不会走常规入队流程，会直接把值传递给等待的消费者，同时触发消费者等待任务的续体调度。这个跨线程调度的成本，就是耗时上涨的根源：

• 注释掉消费者时，写入逻辑只需要把值压入Channel内部的并发队列，全程是单线程内存操作，没有任何额外调度、切换开销，1亿条写入跑6秒是纯内存操作的正常速度。
• 启动Task.Run调度的消费者后，消费者会因为队列空提前挂起等待，每次生产者写入都要走「直接传值给消费者+把消费者续体提交到线程池」的流程。这部分逻辑会占用生产者线程的CPU时间，同时两个线程池线程会频繁争抢CPU时间片、产生大量上下文切换，最终把写入耗时拉到10秒。

去掉Task.Run后耗时稳定的原因 #

直接调用Produce和Consume时，两个异步方法没有被强制调度到独立的线程池线程，核心差异在于异步操作的同步完成优化：

• 当两个方法在同一个线程启动时，Consume里的ReadAsync绝大多数场景是同步完成的：只要队列里有值，ReadAsync不会挂起等待，会直接取出值返回，整个消费循环实际是和生产逻辑跑在同一个线程上——相当于生产者写完值，立刻同步执行消费逻辑读走值，全程没有跨线程调度、上下文切换的开销。
• 这种模式下本质是单线程串行执行生产和消费逻辑，自然和纯写入的耗时一致，稳定在6秒。

补充说明：这个性能差异和Channel本身的实现效率无关，是多线程调度的固有成本。测到的4秒差值，就是1亿次跨线程唤醒、线程池任务调度、上下文切换的总开销。不管用哪种生产者消费者实现，只要强制生产和消费跑在两个独立的抢占式调度线程上，都会产生这部分开销。

内容的提问来源于stack exchange，提问作者rory.ap