SetTimer（）陷阱

Question

我有一个无窗口的计时器（没有WM_TIMER），只有在给定的时间段过去后才会触发一次回调函数。它实现为SetTimer()/KillTimer()。时间段足够小：100-300毫秒。

在每个如此短的时间间隔内拨打SetTimer()/KillTimer()对是否足够便宜（我的意思是性能）？

如果我有100个这样的定时器定期拨打SetTimer()/KillTimer()怎么办？系统中可能同时存在多少Window定时器对象？

这是个问题： 使用一堆这样的计时器对象并依赖于计时器的良好Windows实现，或者创建一个Windows计时器对象，每个计时器对应一次，例如30毫秒，并订阅所有自定义100-300毫秒的一次性计时器。

由于

Answer 1

当您尝试使用它们时，计时器消息的问题在于它们是低优先级消息。实际上它们是假信息。定时器与底层内核计时器对象相关联 - 当消息循环检测到该触发时，它只是标记当前线程消息队列，并带有一个标志，指示下一次调用GetMessage - 当没有其他消息要处理时 - 应该合成WM_TIMER消息及时返回。

对于潜在的大量计时器对象，系统不会明确地为所有计时器公平地发出计时器消息，并且任何系统负载都可以完全阻止长时间生成WM_TIMER消息。

如果您控制了消息循环，则可以使用维护自己的计时器事件列表（以及应该发生的GetTickCount时间戳）和MSGWaitForMultipleObject - 而不是GetMessage来等待消息。使用dwTimeout参数提供最小间隔 - 从现在开始 - 直到下一个计时器应该发出信号。因此，每次有计时器处理时，它都会从等待消息返回。

和/或者您可以使用waitable timers - 在具有MSGWaitForMultipleObjects的GUI线程上，或者仅在工作线程上，以直接访问较低级别的计时功能。

Answer 2

最大的SetTimer()陷阱是实际上它是 USER对象（尽管它没有在MSDN USER objects list中列出）因此它属于Windows USER对象限制 - 默认情况下每个进程最多10000个对象，每个会话最多65535个对象（所有正在运行的进程）。

这可以通过简单的测试轻松证明 - 只需调用SetTimer()（参数不关心，窗口化和无窗口行为都相同），并在任务管理器中看到USER对象计数增加。

另请参阅ReactOS ntuser.h来源和this article。他们都声明TYPE_TIMER是USER句柄类型之一。

所以要小心 - 创建一堆定时器可能会耗尽系统资源，导致进程崩溃甚至整个系统无响应。