为什么是线睡眠这么有害

Question

为什么是线睡眠这么有害

我经常看到它提到Thread.Sleep();不应该用，但我不明白为什么会这样。如果Thread.Sleep();有可能造成麻烦，有没有其他的解决方案，有相同的结果，将是安全的？

例如。

while(true){
    doSomework();
    i++;
    Thread.Sleep(5000);}

另一个是：

while (true){
    string[] images = Directory.GetFiles(@"C:\Dir", "*.png");

    foreach (string image in images)
    {
        this.Invoke(() => this.Enabled = true);
        pictureBox1.Image = new Bitmap(image);
        Thread.Sleep(1000);
    }}

Answer 1

打电话的问题Thread.Sleep是在这里解释得很简洁:Thread.Sleep有其用途：在MTA线程上测试/调试时模拟冗长的操作。在.NET中，没有其他理由使用它。Thread.Sleep(n)表示至少阻塞当前线程的时间(或线程量子数)。n毫秒。在不同版本/类型的Windows和不同的处理器上，时间间隔的长度是不同的，通常从15毫秒到30毫秒不等。这意味着线程几乎可以保证阻塞时间超过n毫秒。线程重新唤醒的可能性。n毫秒几乎是不可能的。所以,Thread.Sleep对时机来说是毫无意义的.线程是一个有限的资源，它们需要大约200000个周期来创建，大约需要100000个周期来销毁。默认情况下，它们为其堆栈预留1MB的虚拟内存，并为每个上下文开关使用2000至8000次循环。这使得任何等待线程都成为巨量浪费。首选的解决办法是：威汉德斯最犯的错误是使用Thread.Sleep使用时间-构造(演示和回答, 不错的博客-条目)编辑：我想加强我的回答：我们有两个不同的用例：我们在等待，因为我们知道一个具体的时间周期，我们应该继续(使用Thread.Sleep, System.Threading.Timer或类似)我们在等待，因为某些情况会在某一时间发生变化.关键字is/are一段时间！如果条件检查在我们的代码域中，我们应该使用WaitHandles-否则外部组件应该提供某种挂钩.如果它没有，它的设计是不好的！我的回答主要涉及用例2。

Answer 2

场景1-等待异步任务完成：我同意在一个线程正在等待另一个线程完成任务的场景中应该使用WaitHandle/AUTO ManualResetEvent。场景2-计时同时循环：但是，作为粗质对99%不需要知道的应用程序来说，计时机制(而不是线程)是非常好的一点儿没错当阻塞的线程应该“醒来*”时，关于创建线程需要200 k周期的论点也是无效的-计时循环线程无论如何都需要创建，而200 k循环只是另一个大数字(告诉我打开一个文件/Socket/db调用需要多少周期？)。那么，如果时间+线程，睡眠工作，为什么复杂的事情？只有语法律师实用!