c# - 当有数百个 Task.Delay 时性能如何

Question

对于发送到服务器的每个调用，我通过 Task.Delay 创建一个新计时器来监视其超时。

假设会有数百个并发调用。因此会有数百个 Task 对计时器进行计数。

我猜 TPL 的内部实现考虑了这种情况并且所有任务都依赖于相同的底层计时器？

我不太了解 Task.Delay 的内部工作机制。

Answer 1

Task.Delay 使用内部 System.Threading.Timer 实现。该计时器类是单个 native 计时器之上的包装器。要同步对单个 native 计时器的访问，在创建新计时器(和更改现有计时器)时需要使用 AppDomain 级别的锁。你可以在 reference source 中看到:

internal bool Change(uint dueTime, uint period)
{
    // ...
    lock (TimerQueue.Instance)
    {
        // ...
    }
    // ...
}

在大多数情况下这很好，但是当您每秒创建大量此类计时器时，您可能会对该锁产生严重的争用。真正知道的唯一方法是在真实环境中分析您的应用程序。

---

就个人而言，我已经通过使用计时器创建过多的自取消 CancellationTokenSource 达到了这一点(您可以在我的博客上看到我是如何避免这种情况的:Surprising Contention In System.Threading.Timer)。

Stephen Toub 也有这篇关于 Coalescing CancellationTokens from Timeouts 的帖子提到:

"Of course, there are always scenarios the push the boundaries of performance, and we’ve recently seen some high-throughput cases where folks were creating one such CancellationToken for each of thousands upon thousands of asynchronous calls being made per second. That’s a lot of Timer and CancellationTokenSource instances."