什么时候使用Thread.Sleep（）是明智的？

Question

我总是看到人们使用Thread.Sleep()来创建处理延迟或类似的东西，人们总是被这样使用它而受到嘲笑。

何时合理/需要使用Thread.Sleep()？

Answer 1

当你真正需要在后台线程中延迟时，你应该调用Thread.sleep()。

请勿将其称为帮助同步（它不会），不要在循环中调用它来等待某些事情（它会很慢）并且永远不要在UI线程上调用它（它会冻结）。

Answer 2

当你需要在一些一次性或测试代码中引入暂停时，Thread.Sleep（）就可以了。

在生产代码中，最好尝试找到不同的选项。例如，如果您尝试在某个时间间隔内执行某些操作，请使用许多预先存在的计时器类之一。如果您在输入队列清空时（以及在.NET上）尝试暂停，请考虑改为使用Monitor.Wait()和Monitor.Pulse()。

本文中有关Sleep（）缺点的更多（再次以.NET为中心）解释：Thread.Sleep is a sign of a poorly designed program.

Answer 3

我认为很少有可以接受的情况。最终，它归结为我脑海中的以下条件 - 其他人可能会对这些不适用的情况感兴趣，但根据经验，以下所有内容都需要在生产中使用Thread.Sleep（代码：

，而不是琐碎或测试）

1. 您正在等待资源
2. 相关资源未提供正确的准备就绪通知（WaitHandle或其他内容）
3. 您无法以其他方式修改相关资源
4. 您已经测量并知道您需要等待足够长的时间以使SpinWait不合理，并且通过离开上下文可以获得更好的性能。

Answer 4

编写测试代码时。如果你想看看一个函数如何处理多个线程随机调用的函数。

此外，如果您想模拟测试延迟。假设您想测试进度条。

Answer 5

它可用于强制上下文切换（参数为1）或屈服于其他更高优先级的线程（参数为0）....但这很少需要。

Answer 6

如果您需要Thread.Sleep，可能会出现错误的设计。更好地使用AutoResetEvent或ManualResetEvent等同步机制并等待事件发生。我经常看到使用Thread.Sleep进行轮询，但如果可能的话，最好尝试使用事件。

Answer 7

关于使用睡眠的投诉通常与有效（或相当无效）的多线程设计有关。多线程是一个很大的主题，我只想简单地介绍一下它（Goetz的Java Concurrency in Practice）。

如果你想延迟处理代码一段固定的时间，那么sleep（）是一件好事（但Timer类是实现周期性行为的好方法。）

Answer 8

每当您需要在操作中长时间停顿时使用它。如果规范说“现在等待至少10秒再继续”，则调用sleep（10000）。还有一种方法 - 您可以将代码重写为状态引擎，以便可以放弃控制，直到向其发出计时器事件。表驱动状态机非常灵活，允许完全异步操作。由此产生的“代码”可能不会以任何方式与需求规范相似，它几乎不可能理解正在发生的事情，难以调试以及修改，维护和/或增强的噩梦，但是你将能够避免那种讨厌，反模式'睡眠（10000）'电话。

正如其他人发布的那样，请不要将它用于线程间通信！所有多任务操作系统都有大量更有效的sychro机制。

Answer 9

如果你想要一个线程停止做某事，当你进行无限循环时，你不希望循环不停，因为它也需要大量的CPU能力，在它中添加一个thread.sleep将使循环“休息一下”并给cpu休息一下^^。