.NET调度多个操作：单个计时器与一个计时器进行操作

Question

我正在开发一个Windows服务应用程序。NET，它执行许多功能(它是一个WCF服务主机)，其中一个目标是运行调度的任务。

我选择创建System.Threading。每个操作的计时器，dueTime设置为下一次执行，并且没有时段以避免重新进入
每次操作结束时，都会更改dueTime以匹配下一次计划执行。

大多数操作计划每分钟运行一次，不是一起运行，而是彼此延迟几秒钟。

现在，在添加了一些操作(大约30次)后，计时器似乎开始不准确，开始操作要晚很多秒，甚至几分钟。

我直接在计时器的回调方法中运行操作逻辑，因此运行的线程应该与计时器相同。

我应该创建一个Task来运行操作，而不是在回调方法中运行它来提高准确性吗？

或者我应该使用一个固定（1秒）到期时间的计时器来检查需要启动哪些操作？我不喜欢
最后一个选项，因为处理重入会更困难。

Answer 1

好的，我做出了一个决定：由于我无法轻松地重现行为，我选择解决根本问题，并使用服务流程仅：

< li >满足客户的WCF要求 < li >计划操作(有问题)

每一个会消耗CPU的操作都是由另一个进程执行的，而另一个进程是由主进程直接控制的。诊断。过程及其事件)并通过WCF与它通信。

当我启动辅助进程时，我通过命令行将主进程的PID传递给它。如果后者被杀，这个过程。Exited事件触发，我也可以关闭子进程。

这样，主服务通常不会占用太多 CPU 时间，并且可以自由地愉快地安排，而不会出现延迟。

感谢所有给我一些建议的人！

Answer 2

我们通常会设置多个计时器来处理单个服务中的不同操作。我们设置间隔并启动，停止服务启动/停止/关闭事件上的计时器（并有一个指示每个事件状态的变量，即bool Stop）当计时器滴答作响时，我们停止计时器，运行处理（这可能需要一段时间，具体取决于进程，即如果它很短，则可能需要比间隔更长的时间。（此代码需要尝试 - 捕获，以便不断出错）在代码处理完毕后，我们检查Toped变量，如果它没有停止，我们再次启动计时器（这处理了你提到的重入性，并允许代码尽可能地坚持间隔）据我所知，计时器通常在大约100ms后更准确，但应该足够接近你想要做的事情。

我们多年来一直奉行这一理念，它没有让我们失望。

如果您将这些任务作为 ASP.NET 应用程序的子系统运行，则还应该查看HangFire，它可以处理后台处理，从而消除了对Windows服务的需求。

定时器需要多精确？您可以始终使用单个定时器并同时运行多个处理线程？或者如果不太关键，则将调用排队到某些操作。

Answer 3

计时器在线程池线程上触发，因此您可能会发现，当您添加大量计时器时，您正在耗尽线程池。

您可以增加线程池的大小，或者确保您的计时器少于线程池的大小。

从回调中释放任务可能无济于事 - 因为您将为来自同一线程池的线程而战。除非您使用长时间运行的任务。