基于async/await快速处理队列：实现运行过慢的原因与优化方案

• 核心根因：串行处理叠加系统计时器精度限制
  当前实现采用单后台任务串行处理所有队列元素，必须等待上一个元素处理完成才会处理下一个。而Windows操作系统默认的系统计时器精度为15.6ms，你调用Task.Delay(1)时实际等待时长不会低于15.6ms，1000个元素串行累计的耗时刚好为 1000 * 15.6ms ≈ 15.6s 和你测试得到的16s完全吻合。
• 异步调度逻辑错误
  你用TaskFactory.StartNew传入async lambda时，返回值实际是Task<Task>类型，没有调用Unwrap()处理内层异步任务，会导致你设置的TaskCreationOptions.LongRunning参数完全不生效，该参数仅作用于外层包装任务，内层异步逻辑还是会被调度到普通线程池线程执行。
• 线程安全隐患
  processingQueue布尔变量没有加volatile修饰，多线程场景下存在可见性问题，极端情况会出现队列有元素但未触发处理的异常。另外单元测试中使用非线程安全的List<int>收集处理结果，改为并行处理时会出现结果丢失、索引异常等问题。

方案1：保留串行处理逻辑（适用于必须按入队顺序处理的业务场景） #

仅做最小改动修复现有问题即可：

1. 单元测试模拟耗时可以用await Task.Yield()或短时间CPU空转代替Task.Delay(1)，避免触发系统计时器精度限制。
2. 给StartNew的返回值加Unwrap()，修复异步调度逻辑。
3. 给processingQueue变量加volatile修饰，解决多线程可见性问题。

方案2：支持并行处理（适用于无顺序要求、需要高吞吐量的场景） #

无需自己实现队列调度逻辑，直接使用微软官方提供的TPL Dataflow库的ActionBlock<T>，原生支持并行度控制、完成通知、背压等能力，实现更稳定性能更高：

public class ProcessQueue<T>
{
    private readonly ActionBlock<T> _processingBlock;

    public Task ProcessingComplete => _processingBlock.Completion;

    public ProcessQueue(Func<T, Task> processItemFunc, int maxDegreeOfParallelism = 32)
    {
        _processingBlock = new ActionBlock<T>(processItemFunc, new ExecutionDataflowBlockOptions
        {
            // 可根据业务需要调整最大并行度，设置为Unbounded则无限制
            MaxDegreeOfParallelism = maxDegreeOfParallelism
        });
    }

    public void EnqueueAndProcess(T data)
    {
        _processingBlock.Post(data);
    }

    public void Stop()
    {
        _processingBlock.Complete();
    }
}

同时修改单元测试的结果收集对象为线程安全版本：

private ConcurrentQueue<int> processedOutput = new ConcurrentQueue<int>();

private async Task ProcessAsync(int value)
{
    await Task.Delay(1);
    processedOutput.Enqueue(value);
}

按上述实现并行度设置为32时，1000条数据的总耗时可以降到500ms以内，完全符合预期。如果要求输出顺序和入队顺序一致，可以在所有元素处理完成后对结果做一次排序即可。

内容的提问来源于stack exchange，提问作者Greg