有没有人反对使用Thread.Sleep（）？

Question

在评论this other SO post中的答案时，有人提出使用Thread.Sleep（）方法是一种代码气味。

我很难相信没有使用这种方法并不能表明你做错了什么。我能想到一对情绪：

• 以编程方式关闭其他应用程序;除非您想要杀死该应用程序（有时甚至是这样），您需要等待几秒钟才能正常终止。
• .NET 2.0代码：是的，它仍然存在。 Thread.Yield（）不是在.NET 4之前发明的，所以如果你想让其他应用程序在你的某个轮询循环中执行它们的事情，那么短暂间隔的Thread.Sleep（）是要做的事情。它。

那么，为什么Thread.Sleep会成为一个如此可怕的代码行，以便在它会闻到的任何情况下使用？

Answer 1

我认为你误解了代码的味道。代码气味经常被滥用或倾向于暗示设计不佳。这意味着你应该调查它，不你应该避免它！

Thread.Sleep通常表示某个线程正在等待某个东西，但无法知道它应该等待多长时间。这通常表明应该是闭环的控制函数实现为开环。

它有时也被用作增加公平性的破碎方式。但公平性通常很糟糕，因为它有成本（额外的上下文切换）并且不像你的线程会提出工会申诉。通常没有理由对他们公平，因为他们都在合作完成工作。

当然，如果这是完成工作的最佳方式，或者在其他解决方案需要更多努力或需要更高风险的情况下足够好，您应该使用它。

Answer 2

通常是代码气味，但有些情况，例如您的示例，可以这样做。
说它是代码味道并不意味着它永远不会使用它。

人们称其为代码味道的原因是我们已经看到许多不理解多线程使用Thread.Sleep的人试图超越竞争条件。

Answer 3

我不一定反对Thread.Sleep()，但有时还有其他（和更好的）方法让线程等待。

如果您处于轮询循环中且等待特定条件，则AutoResetEvent很可能更接近您想要的内容。

Answer 4

有合法用途。

坦率地说，所有“代码嗅觉”的例子都有合法用途。

偶catch { }。 也许甚至goto。

如果某些东西通常被称为代码气味，那么它应该让您停下来思考/询问您对它的每个用途是否合适。但是不要把它当作一条不会被打破的一揽子规则，并且不要让它担心你决定/询问你使用它是否合适的时间。