我经常看到人们使用Thread.Sleep()
来创建处理延迟或类似的操作,但是人们总是因为这种用法而受到嘲笑。
什么情况下使用Thread.Sleep()
是明智/必需的?
我经常看到人们使用Thread.Sleep()
来创建处理延迟或类似的操作,但是人们总是因为这种用法而受到嘲笑。
什么情况下使用Thread.Sleep()
是明智/必需的?
当你需要在后台线程中进行延迟时,应该调用Thread.sleep()
。
不要在同步过程中调用它(它无法实现同步),不要在循环中等待某些内容时调用它(这样会很慢),也不要在UI线程上调用它(这样会导致程序冻结)。
Thread.Sleep
,同时对一组文件或网络套接字进行长时间处理(并在线程完成时进行回调)。这是使用Thread.Sleep
的好方法还是有更好的机制来实现这一点? - Matthew有很少的情况我认为使用Thread.Sleep是可以接受的。在我的想法中,最终归结于以下条件 - 其他人可能会在这些不适用的情况下发表意见,但作为一个经验法则,以下所有条件都需要成立,我才会在生产环境(即非微不足道或测试代码)中使用Thread.Sleep:
当编写测试代码时,如果您想查看某个函数如何处理被随机调用的多个线程。
此外,如果您想模拟延迟进行测试。比如说您想测试一个进度条。
它可以用来强制进行上下文切换(参数为1),或者让出CPU给优先级更高的线程(参数为0)...但这很少需要。
Thread.Sleep
,可能意味着你的设计有问题。最好使用同步机制,如 AutoResetEvent 或 ManualResetEvent,并等待事件发生。我经常看到使用 Thread.Sleep
进行轮询,但如果可能的话,最好尝试使用事件。使用sleep的投诉通常与有效(或者说无效)的多线程设计有关。多线程是一个庞大的主题,我建议您阅读一本好书(《Java并发编程实战》by Goetz)。
如果您想要延迟处理代码一段固定的时间,那么sleep()是个不错的选择(然而,Timer类是实现周期性行为的好方法)。
每当您需要在操作中进行长时间暂停时,请使用它。如果规范说“现在等待至少10秒钟才能继续”,那么请调用sleep(10000)。还有一种选择-您可以将代码重写为状态引擎,以便控制可以被放弃,直到定时器事件被触发。表驱动状态机非常灵活,允许完全异步操作。生成的“代码”可能不会以任何方式类似于要求规范,几乎不可能理解正在发生什么,难以调试,并且是修改、维护和/或增强的噩梦,但您将能够避免那个讨厌的反模式“Sleep(10000)”调用。
正如其他人发布的那样,请勿将其用于线程间通信!所有多任务操作系统都有大量更有效的同步机制。