CPU密集型Construct多线程方法：阻塞事件与异步实现哪种更优？

我有一个通过Task.Run()启动大量CPU密集型工作线程的方法，每个工作线程还可递归启动更多线程，但所有线程最终都会终止。最初的实现采用CountdownEvent阻塞调用线程，直至所有线程完成：

public Result OrchestrateWorkers(WorkItem[] workitems)
{
    this.countdown = new CountdownEvent(0);
    this.results = new ConcurrentQueue<WorkerResult>();
    foreach (var workItem in workitems)
    {
        SpawnWorker(workItem);
    }
    this.countdown.Wait(); // 等待所有生成的工作线程完成
    return ComputeTotalResult(this.results);
}

公开方法SpawnWorker用于启动工作线程，通过入队结果和递减计数跟踪完成状态：

public void SpawnWorker(WorkItem workItem)
{
    this.countdown.AddCount();
    Task.Run(() => {
        // Worker会接收当前类的实例，因此可以在需要时调用SpawnWorker
        var worker = new Worker(workItem, this);
        var result = worker.DoWork();
        this.results.Enqueue(result);
        countdown.Signal();
    });
}

每个工作线程可随意调用SpawnWorker，且最终都会终止。但此设计中，调用OrchestrateWorkers的线程会被阻塞，无法参与工作，我认为这是一种浪费。

我是否应该重构为如下异步实现？

public Task<Result> OrchestrateWorkersAsync(WorkItem[] workitems)
{
    if (this.tcs is not null) throw new InvalidOperationException("Already running!");
    this.tcs = new TaskCompletionSource<Result>();
    this.countdown = 0;     // 普通整数
    this.results = new ConcurrentQueue<WorkerResult>();
    foreach (var workItem in workitems)
    {
        SpawnWorker(workItem);
    }
    return tcs.Task;
}

public void SpawnWorker(WorkItem workItem)
{
    Interlocked.Increment(ref this.countdown);
    Task.Run(() => {
        var worker = new Worker(workItem, this);
        var result = worker.DoWork();
        this.results.Enqueue(result);
        if (Interlocked.Decrement(ref countdown) == 0)
        {
            this.tcs.SetResult(this.ComputeTotalResult(this.results));
        }
    });
}

编辑补充：我添加了完整可编译运行的示例。在8核系统上测试发现异步实现性能提升约10%，但我想确认这是否是编排动态生成任务的标准方式。

你这套异步实现是能正常工作的，而且确实解决了原方案里调用线程被阻塞浪费的问题——这也是你能测出10%性能提升的核心原因。不过它算不上编排动态递归任务的最标准、最简洁的方案，主要问题在这几点：

1. 状态管理太繁琐：你得手动维护countdown整数和TaskCompletionSource实例，还要加重复调用的校验逻辑，代码维护成本高，一不小心还容易出线程安全问题。
2. 没用到Task本身的组合能力：.NET的Task系统本来就支持任务的追踪和组合，完全没必要自己手动写计数逻辑。

更贴合.NET异步范式的实现方式 #

可以让SpawnWorker返回Task，递归追踪所有子任务，最后用Task.WhenAll等待所有任务完成再计算结果，代码会简洁很多：

public async Task<Result> OrchestrateWorkersAsync(WorkItem[] workitems)
{
    var results = new ConcurrentQueue<WorkerResult>();
    // 启动所有初始任务，等全部完成再往下走
    await Task.WhenAll(workitems.Select(item => SpawnWorkerAsync(item, results)));
    return ComputeTotalResult(results);
}

private async Task SpawnWorkerAsync(WorkItem workItem, ConcurrentQueue<WorkerResult> results)
{
    var worker = new Worker(workItem, this);
    var result = worker.DoWork();
    results.Enqueue(result);
    
    // 这里假设Worker.DoWork会返回需要递归处理的子任务列表，可根据实际逻辑调整
    var childWorkItems = worker.GetChildWorkItems();
    if (childWorkItems.Any())
    {
        // 递归启动所有子任务，等它们都完成
        await Task.WhenAll(childWorkItems.Select(childItem => SpawnWorkerAsync(childItem, results)));
    }
}

两种方案怎么选 #

• 你的异步实现：适合没法修改Worker代码的场景（比如Worker必须保持原有的SpawnWorker调用方式），不用动底层逻辑就能实现异步非阻塞；但缺点就是手动维护状态太麻烦。
• 标准Task组合方案：代码更简洁，完全遵循.NET异步编程的惯用法，不用自己操心计数和线程安全的问题；但需要调整SpawnWorker的逻辑，让它返回Task并递归等待子任务。

关于性能 #

你测出来的10%提升主要是因为调用线程不再被卡死，能去处理其他工作负载。两种异步方案在CPU密集型场景下的性能差距很小，核心区别还是代码的可维护性和可读性。

如果Worker代码没法改，那你的实现完全可以用；如果能调整，更推荐用基于Task.WhenAll的标准方案。

内容的提问来源于stack exchange，提问作者John Källén