System.Threading.Timer的可伸缩性如何?
我正在编写一个需要使用Timer
的应用程序,但可能还有很多。 System.Threading.Timer
类的可伸缩性如何? 文档只是说它“轻量级”,但没有进一步解释。 这些计时器是否被吸入代表Timer
处理所有回调的单个线程(或非常小的线程池),或者每个Timer
都有自己的线程?
我想另一种重新解释这个问题的方法是: System.Threading.Timer
是如何实现的?
我在回答很多问题时这样说:不要忘记框架的(托管)源代码是可用的。 您可以使用此工具来完成所有工作: http : //www.codeplex.com/NetMassDownloader
不幸的是,在这个特定的情况下,很多实现都是在本机代码中,所以你不要看它…
但它们肯定使用池线程而不是每个计时器的线程。
实现大量计时器的标准方法(这是内核在内部执行的方式,我怀疑是间接的,你的大型计时器最终会如何结束)是按照时间 – 到期 – 维护列表 – 所以系统只需要担心检查即将到期的下一个计时器,而不是整个列表。
粗略地说,这给出了启动定时器的O(log n)和用于处理运行定时器的O(1)。
编辑:刚刚看过杰夫里希特的书。 他说(Threading.Timer)它为所有Timer对象使用一个线程,这个线程知道下一个定时器(如上所述)到期时,并根据需要调用ThreadPool.QueueUserWorkItem进行回调。 这样做的结果是,如果在下一个到期之前没有在计时器上完成一个回调服务,那么你的回调将重新进入另一个池线程。 总而言之,我怀疑你会看到有很多计时器的大问题,但是如果大量的计时器在相同的计时器和/或它们的回调运行缓慢,你可能会遇到线程池耗尽。
我想您可能想重新考虑您的设计(也就是说,如果您自己可以控制设计)。 如果你使用这么多的计时器,这实际上是你的一个问题,那么显然有一些潜在的合并。
这是几年前来自MSDN杂志的一篇很好的文章,它比较了三个可用的计时器类,并对它们的实现提供了一些见解:
https://msdn.microsoft.com/en-us/magazine/cc164015.aspx
巩固他们。 创建一个计时器服务并询问计时器。 它只需要保留1个活动计时器(用于下一个到期通话)……
为了比仅仅创建大量的Threading.Timer对象更好,你必须假设它不是Threading.Timer在内部已经完成的。 我有兴趣知道你是如何得出这个结论的(我没有反汇编框架的本地部分,所以你很可能是正确的)。
^^正如DannySmurf所说:巩固它们。 创建一个计时器服务并询问计时器。 它只需要保留1个活动计时器(用于下一个到期呼叫)和所有计时器请求的历史记录,并在AddTimer()/ RemoveTimer()上重新计算。
上述就是C#学习教程:System.Threading.Timer的可伸缩性如何?分享的全部内容,如果对大家有所用处且需要了解更多关于C#学习教程,希望大家多多关注—计算机技术网(www.ctvol.com)!
本文来自网络收集,不代表计算机技术网立场,如涉及侵权请联系管理员删除。
ctvol管理联系方式QQ:251552304
本文章地址:https://www.ctvol.com/cdevelopment/985240.html