await Task.Run与Event.WaitOne的性能差异原因排查

我有一个通信驱动，原本每天会失败数千次，修改一行代码后恢复正常运行。

// 事件最迟会在100ms后被设置
ManualResetEvent sendOutEvent = new ManualResetEvent(false);

...

// 之前，此处有时会卡顿超过800ms
await Task.Run(() => outgoingPacket.sendOutEvent.WaitOne(5000)); 

// 替换为该行后，运行符合预期
outgoingPacket.sendOutEvent.WaitOne(5000);

这段代码每日被调用约100万次，且每次调用都会等待完成后再执行下一次。我知道await结构有些多余，但原本认为两行代码表现应该完全一致，预期await Task.Run仅会稍慢，不会出现高达800ms的卡顿。

我是否忽略了什么？两者的差异在哪里？

调试获取的部分数值 #

使用以下代码：

ThreadPool.GetAvailableThreads(out int workerThreads, out int portThreads);
Console.WriteLine($"workerThreads={workerThreads}, portThreads={portThreads} ThreadCount={ThreadPool.ThreadCount} CompletedWorkItemCount={ThreadPool.CompletedWorkItemCount} PendingWorkItemCount={ThreadPool.PendingWorkItemCount}");

得到如下或类似结果：

workerThreads=32757, portThreads=1000 ThreadCount=20 CompletedWorkItemCount=413166 PendingWorkItemCount=0

有时会看到PendingWorkItemCount > 0，但最大值为20。

核心差异分析 #

• 线程池调度的隐性延迟
  await Task.Run会将WaitOne操作提交给线程池worker线程执行。即便线程池显示有大量可用线程，高频百万级调用下，线程池的任务调度、线程切换开销会被放大：线程池存在线程注入阈值（默认每秒最多新增2个线程），短时间内大量任务提交时，即便有空闲线程，任务排队和调度的微小延迟累积后，会出现个别任务等待数百毫秒才被执行的情况。而直接调用WaitOne是在当前线程阻塞等待，无调度开销，事件触发后能立即响应。

• 异步上下文切换的额外消耗
  await会自动捕获当前同步上下文（如SynchronizationContext），任务完成后需要切换回原上下文继续执行。这个上下文切换的开销在百万级调用下会不断累积，成为卡顿的重要诱因。直接调用WaitOne无需任何上下文切换，阻塞结束后直接继续当前逻辑。

• 任务排队的累积效应
  虽然调试中PendingWorkItemCount最大值仅为20，但高频调用下，线程池任务队列的短时间排队会让每个任务的启动都有微小延迟，当调用量达到百万级时，这些延迟会被放大，最终出现远超预期的卡顿。直接调用完全规避了这个排队环节。

总结 #

看似多余的await Task.Run，在高频阻塞场景下引入了线程池调度、上下文切换的额外开销，这些开销在百万级调用量下被放大，最终导致了严重卡顿。直接调用WaitOne避免了所有额外调度环节，因此运行表现稳定符合预期。

内容的提问来源于Stack Exchange，提问作者jeb