System.Threading.Timer 的可扩展性如何? [英] How scalable is System.Threading.Timer?

问题描述

我正在编写一个需要使用 Timer 的应用程序，但其中可能有很多.System.Threading.Timer 类的可扩展性如何?文档只是说它是轻量级的"，但没有进一步解释.这些计时器是否被吸入代表 Timer 处理所有回调的单个线程(或非常小的线程池)中，还是每个 Timer 都有自己的线程?

我想换一种说法是:System.Threading.Timer 是如何实现的?

解决方案

我这么说是为了回答很多问题:不要忘记框架的(托管)源代码是可用的.你可以使用这个工具来获得这一切:http://www.codeplex.com/NetMassDownloader>

不幸的是，在这种特定情况下，很多实现都是在本机代码中进行的，因此您无法查看它...

不过，他们肯定使用池线程而不是每个计时器的线程.

实现大量计时器的标准方法(这是内核在内部执行它的方式，我怀疑间接地是您的大量计时器最终如何结束)是维护按 time-until-expiry 排序的列表- 所以系统只需要担心检查下一个即将到期的计时器，而不是整个列表.

粗略地说，这给出了启动计时器的 O(log n) 和处理正在运行的计时器的 O(1).

刚刚在看 Jeff Richter 的书.他说(Threading.Timer)它对所有 Timer 对象使用单个线程，该线程知道下一个计时器(即如上)何时到期，并根据需要调用 ThreadPool.QueueUserWorkItem 进行回调.这会导致如果您没有在下一个到期之前完成对计时器上的一个回调的服务，您的回调将重新进入另一个池线程.所以总而言之，我怀疑您会发现拥有大量计时器会带来大问题，但是如果大量计时器在同一计时器上触发和/或它们的回调运行缓慢，您可能会遇到线程池耗尽的情况.

I'm writing an app that will need to make use of Timers, but potentially very many of them. How scalable is the System.Threading.Timer class? The documentation merely say it's "lightweight", but doesn't explain further. Do these timers get sucked into a single thread (or very small threadpool) that processes all the callbacks on behalf of a Timer, or does each Timer have its own thread?

I guess another way to rephrase the question is: How is System.Threading.Timer implemented?

解决方案

I say this in response to a lot of questions: Don't forget that the (managed) source code to the framework is available. You can use this tool to get it all: http://www.codeplex.com/NetMassDownloader

Unfortunately, in this specific case, a lot of the implementation is in native code, so you don't get to look at it...

They definitely use pool threads rather than a thread-per-timer, though.

The standard way to implement a big collection of timers (which is how the kernel does it internally, and I would suspect is indirectly how your big collection of Timers ends up) is to maintain the list sorted by time-until-expiry - so the system only ever has to worry about checking the next timer which is going to expire, not the whole list.

Roughly, this gives O(log n) for starting a timer and O(1) for processing running timers.

Edit: Just been looking in Jeff Richter's book. He says (of Threading.Timer) that it uses a single thread for all Timer objects, this thread knows when the next timer (i.e. as above) is due and calls ThreadPool.QueueUserWorkItem for the callbacks as appropriate. This has the effect that if you don't finish servicing one callback on a timer before the next is due, that your callback will reenter on another pool thread. So in summary I doubt you'll see a big problem with having lots of timers, but you might suffer thread pool exhaustion if large numbers of them are firing at the same timer and/or their callbacks are slow-running.

这篇关于System.Threading.Timer 的可扩展性如何?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！