许多 setTimeouts 的结果答案

【问题标题】：the consequence of MANY setTimeouts许多 setTimeouts 的结果
【发布时间】：2015-10-08 15:19:40
【问题描述】：

我正在构建一个用户可以生成自定义计时器的页面。这些计时器通过 setTimeout 在 heroku nodejs 后端运行。但是，我有点担心可能有数千个长时间的 setTimeouts 同时运行。

我发现了this SO 问题，该问题指出 javascript 计时器在浏览器中的单独线程上运行。 nodejs中的情况是否相同？如果是这样，在这个线程上拥有数千个计时器的后果是什么？

编辑：有关我正在尝试做的事情的更多信息。我正在构建一个同步页面，可以将其放在屏幕上，然后用户可以在浏览器中访问该页面并更改其实例上的内容。这将反映在页面的所有打开实例中。用户还应该能够设置计时器，这应该在计时器结束时推送新内容。这就是我正在考虑使用服务器端 setTimeouts 来做的事情。我知道我可能应该使用 Heroku 调度程序插件之一，但我想降低成本（这种页面并不完全是赚钱的人）。最后，用户应该能够使用新的 url 等生成他们自己的页面实例。这就是可扩展性问题发挥作用的地方。如果页面存在 100 个实例，每个实例设置了 10 个定时器，即后端有 1000 个定时器。

【问题讨论】：

你到底想做什么？ “数千个计时器”听起来不是解决任何问题的合适方法。
这听起来不是一个明智的设计决定，即使它是“安全的”。如果您进一步解释您的用例，我相信您将能够得到一些有趣的响应（例如，不要使用 setTimeout :-)
为什么不试试看它是否适合你？
我已经用更多信息更新了我的问题。 @mscdex 我想:) 但是如果 setTimeout 扩展得非常厉害，我不想浪费太多时间。我一直无法找到有关 setTimeout 在倒计时时如何准确工作的具体信息。当它激活时，会有大量关于发生了什么的信息（js 执行堆栈），但我对此并不真正感兴趣。我对它激活之前发生的事情更感兴趣。
NodeJS 中的计时器通过 libuv 计时器工作，并以链表的形式实现。它们的速度相对较快，如果真的只有几万，那也没什么好担心的。

标签： javascript node.js settimeout

【解决方案1】：

基于mscdex在cmets中的解释：

timers.js 的源代码很容易理解，但基本上发生的情况是，所有对 setTimeout() 和 setInterval() 的调用具有相同的到期/间隔都组合在一起，并使用相同的后备计时器。这些 setTimeout()/setInterval() 请求按照添加顺序附加到与该计时器相关联的列表中，因此每次计时器触发时，它都会迭代列表（执行回调），直到它达到没有的超时还没过期。此时，它等待当前时间与该组中的下一次超时之间的增量。我希望这是有道理的。

我得出的结论是，拥有许多 setTimeout 不会影响性能，因为它们实际上都是一个计时器。只是回答自己，因为没有其他人回答。

【讨论】：

你在描述什么听起来更像是一个带有队列的cron。