1

我有一个创建新计时器的类，并在每次滴答时轮询远程队列（通过 HTTP）。

public void Start()
{
    _timer = new Timer((x) =>
    {
        Console.WriteLine(DateTime.Now.ToString("hh:MM:ss.fff") + " " + typeof(T).Name);                

        var message = (Message)null;
        var messageBody = (T)null;

        try
        {
            if (!_queue.TryGet(out message))
                return;

                messageBody = (T)JsonConvert.DeserializeObject(message.Body, typeof(T));

                _messageDispatcher.Dispatch<T>(messageBody);

                _queue.Delete(message.Id);
            }
            catch (Exception ex)
            {
                _errorHandler.Handle(ex, message);
            }                
        }, null, 0, _queueConsumerConfiguration.PollingInterval);            
    }
}

如果我创建这个类的八个新实例，将轮询间隔设置为 250 毫秒，然后调用它们，我会假设计时器会非常准确地计时。计时器回调中执行的内容无关紧要。然而，这种情况并非如此。

01:03:23.305 MessageSleepForOneSecond
01:03:23.301 MessageSleepForOneSecond
01:03:23.297 MessageSleepForOneSecond
01:03:23.316 MessageSleepForOneSecond
01:03:24.321 MessageSleepForOneSecond
01:03:24.562 MessageSleepForOneSecond
01:03:24.701 MessageSleepForOneSecond
01:03:24.707 MessageSleepForOneSecond
01:03:24.716 MessageSleepForOneSecond
01:03:25.321 MessageSleepForOneSecond
01:03:25.518 MessageSleepForOneSecond
01:03:25.764 MessageSleepForOneSecond
01:03:25.912 MessageSleepForOneSecond
01:03:25.920 MessageSleepForOneSecond
01:03:25.924 MessageSleepForOneSecond
01:03:26.521 MessageSleepForOneSecond
01:03:26.710 MessageSleepForOneSecond
01:03:26.957 MessageSleepForOneSecond
01:03:27.107 MessageSleepForOneSecond
01:03:27.120 MessageSleepForOneSecond
01:03:27.126 MessageSleepForOneSecond
01:03:27.716 MessageSleepForOneSecond
01:03:27.906 MessageSleepForOneSecond
01:03:28.151 MessageSleepForOneSecond
01:03:28.305 MessageSleepForOneSecond
01:03:28.316 MessageSleepForOneSecond
01:03:28.322 MessageSleepForOneSecond
01:03:28.913 MessageSleepForOneSecond
01:03:29.100 MessageSleepForOneSecond
01:03:29.349 MessageSleepForOneSecond
01:03:29.502 MessageSleepForOneSecond
01:03:29.513 MessageSleepForOneSecond
01:03:29.538 MessageSleepForOneSecond
01:03:30.107 MessageSleepForOneSecond
01:03:30.297 MessageSleepForOneSecond
01:03:30.545 MessageSleepForOneSecond
01:03:30.705 MessageSleepForOneSecond
01:03:30.712 MessageSleepForOneSecond
01:03:30.733 MessageSleepForOneSecond
01:03:31.307 MessageSleepForOneSecond
01:03:31.310 MessageSleepForOneSecond
...

这是怎么回事？是什么导致不准确？管理线程池，Windows，...？

4

1 回答 1

3

定时器不是无限准确的，线程调度也不是无限准确的。它们中的任何一个都具有最多 1 毫秒的精度（可通过 配置timeBeginPeriod），在当前版本的 Windows 上默认为 16.7 毫秒（在 15 年以上的旧 Windows 上约为 50 毫秒）。

计时器本身并不是无限准确的，它会生成一个事件，使线程池中的线程准备就绪，该事件将在以后的任何时间安排，不准确，也没有任何硬性保证。如果其他线程正在运行，那么根据处理器负载和线程优先级，“以后的任何时间”可能实际上是以后的任何时间（甚至永远不会）。

仅此一点就足以说明为什么通常您选择的间隔都不准确（巧合除外），但特别是 250 毫秒的间隔不会是准确的（因为 249 毫秒是调度程序默认粒度的最接近倍数，因此新线程可以在最好安排在 265.6ms 之后——这假设在那个确切的时间有一个内核可用，这是不能保证的）。

此外，处理 HTTP 请求可能会花费相当多的时间，因此即使没有其他线程，您创建的工作线程也很有可能比核心数量多。这必然意味着操作系统必须决定在特定时间安排哪一个。不管调度器做什么，最终总会有一个或几个线程出现“不公平”的情况，导致它们“不准确”。

写入控制台也是如此。对控制台的写入是同步的（即当您的两个线程写入控制台时，单个写入可能以任何顺序出现，但它们不会出现乱码）。这必然意味着有一个锁。谁先拿到锁，谁就继续。任何试图在纳秒后获得锁的人都将被阻止。其他一些线程接管时间片。最终，被阻塞的线程将再次“准备好”，但不能严格保证该线程会立即运行。

准备好跑步和跑步是两件截然不同的事情。

于 2013-03-10T13:34:00.940 回答