首页 / C# / c# – 我应该总是使用Task.Delay而不是Thread.Sleep吗？

c# – 我应该总是使用Task.Delay而不是Thread.Sleep吗？

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了c# – 我应该总是使用Task.Delay而不是Thread.Sleep吗？，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含1635字，纯文字阅读大概需要3分钟。

内容图文

参见英文答案 > When to use Task.Delay, when to use Thread.Sleep?                                    4个
我最近看到几条建议说明Thread.Sleep永远不应该用在生产代码中(最近一次是在this SO question).其中许多人主张使用Task.Delay.我发现的大多数解释都使用UI应用程序作为示例,因为Task.Delay的优点是显而易见的(不阻止UI).

在我的例子中,我在一个等待循环内部使用Thread.Sleep来轮询WCF服务的特定条件,如下所示：

DateTime end = DateTime.UtcNow + TimeSpan.FromMinutes(2);
while (DateTime.UtcNow < end)
{
    if (ExternalServiceIsReady() == true)
    {
        return true;
    }
    Thread.Sleep(1000);
}

在这种情况下,Task.Delay的以下潜在优势似乎不适用：

>相对于大约15 ms的典型定时器分辨率,睡眠时间相当大,因此Task.Delay的准确性增加似乎微不足道.
>该进程是单线程(非UI),必须阻塞直到条件为真,因此使用await在这里没有优势.
>不需要取消延迟的能力.

这是一个适合使用Thread.Sleep的情况吗？用Task.Delay(1000)替换我的睡眠线会有什么好处(如果有的话).Wait()？

解决方法:

替换Thread.Sleep(1000)永远不会有优势;在Task.Delay(1000).Wait();.如果要同步等待,只需使用Thread.Sleep.

如果你真的只有一个线程并计划保持这种方式,那么你可以使用Thread.Sleep.但是,在大多数情况下,我仍然会使用Task.Delay,因此它是一个很好的模式.当你不能再使用异步时,我只会阻止在顶部,即便如此,我建议使用某种AsyncContext.

您也可以直接使用System.Threading.Timer *而不是Task.Delay但是您应该记住,计时器执行每个时间间隔并且不等待实际操作完成,因此如果ExternalServiceIsReady需要超过您的间隔时间可以同时多次调用该服务.

一个更好的解决方案是用异步操作替换外部服务的轮询,这样服务就可以在它准备就绪时通知你而不是你每秒都要求它(这并不总是可能的,因为它取决于服务)：

await ExternalServiceIsReadyAsync();

* Task.Delay在内部使用System.Threading.Timer,其分辨率约为15ms.

内容总结

以上是互联网集市为您收集整理的c# – 我应该总是使用Task.Delay而不是Thread.Sleep吗？全部内容，希望文章能够帮你解决c# – 我应该总是使用Task.Delay而不是Thread.Sleep吗？所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端

扫描二维码推送至手机访问。

本文链接：https://qyyshop.com/info/803986.html

来源：【匿名】