我正在研究请求超时机制。我最初的方法是为每个请求创建一个 System.Threading.Timer。并发请求的数量可以扩展到数千。
我想知道我是否应该创建一个 TimeoutScheduler，它会在内部只使用一个计时器，而不是每个请求都使用一个计时器。
任何了解 System.Threading.Timer 内部原理的人都可以给我一些关于 TimeoutScheduler 是否是一个好主意或者它是否只会尝试优化已经足够有效的东西的见解。
注意:对于我的场景，计时器精度并不重要。
(我用 System.Threading.Timer 做了一些性能测试，里面有很多并发计时器。它似乎扩展性很好，但我不确定它是否会给真实系统带来不必要的压力)
最佳答案
我将引导您阅读 Raymond Chen 的这篇文章:
What is the maximum number of timers a program can create?
从技术上讲，创建数千个它们没有问题。请注意，这些使用全局系统资源，因此如果您对它发疯，您最终将达到上限和/或开始饿死其他程序(包括 Windows 本身)。
还有确保在完成定时器后处理它们 ，否则你最终会出现巨大的资源泄漏。
我不得不说，这听起来像是你可以用一个计时器实现的东西；只需维护一个事件请求和超时字典，并在每个滴答声中，浏览整个字典并检查每个条目。您可以通过将其设置为排序列表来提高性能；这样，如果再过 5 分钟没有任何超时，tick 方法将在查看第一个条目后退出。
除了上述之外，您还可以动态调整滴答间隔，以便在安排下一个请求超时时触发；然后在每个滴答上，将下一个滴答重新安排到下一次超时。这几乎不占用系统资源(仅一个计时器)，而且速度非常快(就像您的每个请求一个计时器的想法一样，您只会在请求实际到期时运行昂贵的代码)。
尽管您可以创建数千个计时器，但上述方法的可扩展性会更好，并且也更易于测试和维护。
关于.net - System.Threading.Timer 对于数千个并发计时器是否足够有效？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2375034/