System.Threading.Timer对数千个并发计时器有效吗？

Question

我正在处理请求超时机制.我最初的方法是为每个请求创建一个System.Threading.Timer.并发请求的数量可以扩展到数千个.

我想知道我是否应该创建一个TimeoutScheduler,它内部只使用一个计时器而不是每个请求一个.

任何知道System.Threading.Timer内部的人都能给我一些见解,看看TimeoutScheduler是不是一个好主意,或者它是否只会尝试优化已经足够高效的东西.

注意:对于我的场景,计时器精度并不重要.

(我使用System.Threading.Timer对很多并发计时器进行了一些性能测试.它似乎可以很好地扩展,但我不确定它是否会给实际系统带来不必要的压力)

Answer 1

我将指导您阅读Raymond Chen的这篇文章:

从技术上讲,创建数千个没有问题.请注意,这些使用全局系统资源,因此如果您对它疯狂,最终会达到上限和/或开始使其他程序(包括Windows本身)挨饿.

还要确保在完成计时器时丢弃计时器,否则最终会导致巨大的资源泄漏.

我不得不说,这听起来像你可以用一个计时器实现的东西; 只需维护一个活动请求和超时的字典,并在每个标记上,浏览整个字典并检查每个条目.您可以通过将其作为排序列表来提高性能; 这样,如果没有其他5分钟超时,则查看第一个条目后,tick方法将退出.

除了上述内容之外,您还可以动态调整刻度间隔,以便在下一个请求被安排超时时触发; 然后在每个刻度线上,重新安排下一个刻度到下一个超时.这几乎不会占用任何系统资源(只有一个计时器)而且速度也非常快(就像你的每个请求的一个计时器一样,你只会在请求实际到期时运行昂贵的代码).

即使您可以创建数千个计时器,上述方法也可以更好地扩展,并且更容易测试和维护.

实际上，Raymond Chen 的文章描述了由 SetTimer 创建的计时器。`System.Threading.Timer` 实际上是一个 Timer Queue Timer (http://msdn.microsoft.com/en-us/library/ms686796(v=VS.85).aspx)，它本质上是一个单一的计时器和一种确定何时触发下一个事件的有效机制。 (2认同)