c# - System.Timers.Timer 非常不准确

Question

我编写了一个程序，它通过 Parallel.ForEach 使用所有可用的核心。 ForEach 的列表包含约 1000 个对象，每个对象的计算需要一些时间(约 10 秒)。 在这种情况下，我设置了一个这样的计时器:

timer = new System.Timers.Timer();
timer.Elapsed += TimerHandler;
timer.Interval = 15000;
timer.Enabled = true;

private void TimerHandler(object source, ElapsedEventArgs e)
{
        Console.WriteLine(DateTime.Now + ": Timer fired");
}

目前 TimerHandler 方法是一个 stub ，以确保问题不是由该方法引起的。

我的预期是 TimerHandler 方法将每 ~15 秒执行一次。但是，两次调用此方法之间的时间甚至达到了 40 秒，因此 25 秒太多了。 通过为 Parallel.ForEach 方法使用 new ParallelOptions { MaxDegreeOfParallelism = Environment.ProcessorCount -1 } 不会发生这种情况，并且可以看到预期的 15 秒间隔。

是否有意让我必须确保每个事件计时器始终有一个核心可用？似乎更奇怪了，因为“保留”可能是我计算的宝贵资源。

编辑:正如 Yuval 所指出的，通过 ThreadPool.SetMinThreads 设置池中固定的最小线程数解决了这个问题。我还为 Parallel.ForEach 方法尝试了 new ParallelOptions { MaxDegreeOfParallelism = Environment.ProcessorCount } (因此在初始问题中没有 -1 )这也解决了问题。但是，我没有很好的解释为什么这些修改解决了这个问题。也许创建的线程太多，以至于定时器线程“丢失”了“很长”的时间，直到它再次被执行。

Answer 1

Parallel 类使用称为自复制任务的内部 TPL 工具。它们旨在消耗所有可用的线程资源。我不知道有什么样的限制，但它似乎很费力。我几天前回答过基本相同的问题。

Parallel 类很容易无限制地产生疯狂数量的任务。很容易激发它产生无限线程(每秒 2 个)。我认为如果没有手动指定的最大 DOP，Parallel 类将无法使用。它是一颗定时炸弹，在负载下随机在生产中爆炸。

Parallel 在许多请求共享一个线程池的 ASP.NET 场景中尤其有害。

更新:我忘记说重点了。计时器滴答排队到线程池。如果池已饱和，他们会排队并稍后执行。 (这就是为什么计时器滴答可以同时发生或在计时器停止后发生的原因。)这解释了您所看到的。解决这个问题的方法是修复池重载。

针对此特定场景的最佳解决方案是使用固定线程数的自定义任务调度程序。 Parallel 可以使用该任务调度程序。 Parallel Extension Extras 有这样一个调度程序。从全局共享线程池中获取该工作。通常，我会推荐 PLINQ，但它不能采用调度程序。从某种意义上说，Parallel 和 PLINQ 都是不必要的残废 API。

不要使用 ThreadPool.SetMinThreads。不要弄乱全局进程范围的设置。别管可怜的线程池了。

另外，不要使用 Environment.ProcessorCount -1，因为那样会浪费一个核心。

the timer is already executed in its own thread

定时器是操作系统内核中的一种数据结构。在必须排队之前没有线程。不确定它到底是如何工作的，但滴答声最终会排队到 .NET 中的线程池。 那是问题开始的时候。

作为解决方案，您可以启动一个在循环中休眠的线程以模拟计时器。不过，这是一个 hack，因为它没有解决根本原因:重载的线程池。