Thread.Sleep过去与系统时钟相关联，该系统时钟以大约 16 毫秒的间隔计时，因此任何低于 16 毫秒的时间都会产生 16 毫秒的睡眠。这种行为似乎已经在某种程度上改变了。
发生了什么变化？Thread.Sleep不再与系统时钟相关，而是与高分辨率计时器相关联？还是在 Windows 10 中增加了默认系统时钟频率？
编辑：似乎人们有兴趣知道我为什么使用 Thread.Sleep，它实际上超出了问题的范围，问题是为什么行为发生了变化。但无论如何，我注意到我的开源项目 freepie 的变化https://andersmalmgren.github.io/FreePIE/
它是一个输入/输出模拟器，由最终用户使用 Iron python 控制。那在后台运行。它没有自然中断。所以我需要编组脚本线程，这样它就不会饿死整个核心。
感谢我第一次错过的 Hans Passant 评论，我发现了问题。事实证明，Nvidia 的驱动程序套装是问题制造者。
Platform Timer Resolution:Outstanding Timer Request 程序或服务请求的计时器分辨率小于平台最大计时器分辨率。请求周期 10000 请求进程 ID 13396 请求进程路径 \Device\HarddiskVolume2\Program Files\NVIDIA Corporation\NVIDIA GeForce Experience\NVIDIA Share.exe
这在很多层面上都是如此愚蠢。从长远来看，这对环境甚至是不利的，因为任何带有 nvidia 的计算机都会使用更多的电源。
编辑：汉斯评论，相关部分：
太多的程序想要弄乱它，最重要的是销售移动操作系统的公司的免费产品。从提升的命令提示符处运行 powercfg /energy 以在生成的报告中找到作恶者“Platform Timer Resolution”。
确实，较新的硬件确实具有更精确的计时器。但目的Thread.Sleep并不精确，也不应该用作计时器。
这一切都在文档中：
如果 dwMilliseconds 小于系统时钟的分辨率，则线程可能休眠的时间少于指定的时间长度。如果 dwMilliseconds 大于 1 个滴答但小于 2 个滴答，则等待可能介于 1 到 2 个滴答之间，依此类推。
同样非常重要的是，在时间过去后，您的线程不会自动运行。相反，线程被标记为准备运行。这意味着它只有在没有更高优先级的线程也准备好运行时才会获得时间，而不是在当前运行的线程消耗它们的量子或进入等待状态之前。