大量的计时器 [英] Large Number of Timers
问题描述
我需要编写一个接收事件的组件（该事件具有唯一的ID）。每个事件都需要我发出一个请求。该事件指定一个超时时间，该超时时间等待请求的响应。
I need to write a component that receives an event (the event has a unique ID). Each event requires me to send out a request. The event specifies a timeout period, which to wait for a response from the request.
如果响应在计时器触发之前出现，那很好，我取消了计时器。
如果首先触发计时器，则请求超时，我想继续。
If the response comes before the timer fires, great, I cancel the timer. If the timer fires first, then the request timed out, and I want to move on.
此超时时间是在事件中指定的，因此它不是恒定的。
预期的超时时间为30秒到5分钟。
This timeout period is specified in the event, so it's not constant. The expected timeout period is in the range of 30 seconds to 5 minutes.
我可以看到两种实现方法。
I can see two ways of implementing this.
- 为每个事件创建一个计时器，并将其放入将事件链接到计时器的字典中。
- 创建一个包含以下内容的有序列表Datetime的超时时间，以及一个新的线程每100ms循环一次，以检查是否超时。
选项1似乎是最简单的解决方案，但恐怕创建这么多计时器可能不是一个好主意，因为计时器可能太昂贵了。创建大量计时器时是否有陷阱？我怀疑在后台，计时器的实现实际上可能是Option 2的有效实现。如果此选项是一个好主意，我应该使用哪个计时器？ System.Timers.Timer或System.Threading.Timer。
Option 1 would seem like the easiest solution, but I'm afraid that creating so many timers might not be a good idea because timers might be too expensive. Are there any pitfalls when creating a large number of timers? I suspect that in the background, the timer implementation might actually be an efficient implementation of Option 2. If this option is a good idea, which timer should I use? System.Timers.Timer or System.Threading.Timer.
选项2似乎需要更多工作，与选项1相比，可能不是一个有效的解决方案。
Option 2 seems like more work, and may not be an efficient solution compared to Option 1.
更新
我期望的最大计时器数量为10000，但是更多可能在100的范围内。而且，正常情况是计时器在触发前被取消。
The maximum number of timers I expect is in the range of 10000, but more likely in the range of 100. Also, the normal case would be the timer being canceled before firing.
更新2
我使用 System.Threading.Timer 和 System.Timers.Timer 的1万个实例进行了测试code>，注意线程数和内存。从内存使用情况来看，与 System.Timers.Timer 相比， System.Threading.Timer 似乎更轻。没有为两个计时器创建过多的线程（即-线程池正常工作）。因此，我决定继续使用 System.Threading.Timer 。
I ran a test using 10K instances of System.Threading.Timer and System.Timers.Timer, keeping an eye on thread count and memory. System.Threading.Timer seems to be "lighter" compared to System.Timers.Timer judging by memory usage, and there was no creation of excessive number of threads for both timers (ie - thread pooling working properly). So I decided to go ahead and use System.Threading.Timer.
推荐答案
您应该以最简单的方式进行操作。如果您担心性能，则应通过探查器运行应用程序并确定瓶颈。您可能会很惊讶地发现这是您最不期望的代码，并且您无缘无故地优化了代码。我总是写最简单的代码，因为这是最简单的。请参见 PrematureOptimization
You should do it the simplest way possible. If you are concerned about performance, you should run your application through a profiler and determine the bottlenecks. You might be very surprised to find out it was some code which you least expected, and you had optimized your code for no reason. I always write the simplest code possible as this is the easiest. See PrematureOptimization
我不没有看到为什么使用大量计时器会带来任何陷阱。我们是说一打，还是100或10,000？如果很高，可能会有问题。您可以编写一个快速测试来验证这一点。
I don't see why there would be any pitfalls with a large number of timers. Are we talking about a dozen, or 100, or 10,000? If it's very high you could have issues. You could write a quick test to verify this.
关于要使用哪些Timer类：我不想偷别人的答案，谁可能做得更多研究：查看此问题的答案`
As for which of those Timer classes to use: I don't want to steal anyone elses answer who probably did much more research: check out this answer to that question`
这篇关于大量的计时器的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
