c# - Thread.Sleep(1) 耗时超过 1 毫秒

<分区>

我搜索了这个问题，但没有找到答案。如果它是重复的，我会很乐意将其关闭。

我目前正在尝试对一项技术进行一些性能评估，并看到了一些相当令人难以置信的结果，因此我决定进行一些试验。为此，我想尝试看看 Stopwatch 类是否返回了我预期的结果。

Stopwatch sw = Stopwatch.StartNew();
Thread.Sleep(1);
sw.Stop();
Console.WriteLine(sw.ElapsedMilliseconds);

在这种情况下，我几乎看到了 15 毫秒的返回值。我知道 DateTime 的分辨率在那里，但 Thread.Sleep(1) 不应该让一个线程休眠 1 毫秒吗？我使用的系统返回 Stopwatch.IsHighResolution true 并且它在 .NET 4 中运行。

背景: 此代码以其完整且正确的形式旨在收集有关 Aerospike db get 请求的一些数字。数据库不在同一个盒子上。当我打印出 sw.ElapsedMilliseconds 时，查询在中间，我看到的大部分是亚毫秒响应，考虑到我的 Java 等效代码大部分时间返回更可信的 5ms-15ms 响应，这听起来有点可疑。 Java 代码使用了 System.nanoTime() 的差异。我的 C# 代码中的毫微响应是指 Console.WriteLine(sw.ElapsedMilliseconds) 打印 0。

最佳答案

除秒表之外的计时器由时钟中断递增。默认情况下，在 Windows 上每秒滴答 64 次。或 15.625 毫秒。所以小于 16 的 Thread.Sleep() 参数不会给你你正在寻找的延迟，你总是会得到至少 15.625 的间隔。同样，如果您读取 Environment.TickCount 或 DateTime.Now 并等待少于 16 毫秒，那么您将读取相同的值并认为已经过去了 0 毫秒。

始终使用秒表进行小增量测量，它使用不同的频率源。它的分辨率是可变的，取决于主板上的芯片组。但你可以相信它比一微秒更好。秒表。频率为您提供速率。

时钟中断率可以改变，你必须调用timeBeginPeriod()。这可以将您缩短到一毫秒，并实际上使 Thread.Sleep(1) 准确。最好不要这样做，这是非常不友好的。

关于c# - Thread.Sleep(1) 耗时超过 1 毫秒，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/19066900/