使用Thread.Sleep(n)会导致性能问题吗？

Question

我正在为我的项目使用Thread.Sleep(n).我听说Thread.Sleep会导致性能问题但不确定.

我的要求是:

等待5分钟增量,最多30分钟(5分钟延迟的6倍).在此之后,开始增加1小时并执行5次(另外5小时).

下面我提供了我在不同场景中使用Thread.Sleep(n)的示例代码:

Thread.Sleep(1000 * 60 * 5); //-------waiting for 5 minutes
var isDownloaded = false;
try
{
    var attempt = 0;
    while (attempt < 11)
    {
        isDownloaded = TryDownloading(strPathToDownload, strFileToDownload);
        if (isDownloaded)
            break;
        attempt++;
        if (attempt < 6)
            Thread.Sleep(1000 * 60 * 5); //--------waiting for 5 minutes
        else
        {
            if (attempt < 11)
                Thread.Sleep(1000 * 60 * 60); //-------waiting for 1 hour
            else
                break;
        }
    }

}

在上面的代码我试图下载最多11次下载尝试的文件.最初它等待5分钟,然后尝试下载第一次尝试的文件,如果失败则尝试接下来的5次尝试,每次尝试间隔5分钟.如果他们在前六次尝试中失败,则接下来的5次尝试,每次尝试间隔1小时.

所以我们决定在我们的控制台应用程序中使用Thread.Sleep来延迟时间.

这会导致任何问题或性能问题吗？

如果Thread.Sleep(n)导致性能问题,那么这将是一种更好的替代方式,而不是使用Thread.Sleep(n)？

最后,MSDN是否建议Thread.Sleep(n)有害或不应该使用？

Answer 1

这绝对没问题.以下是睡眠费用:

• 你保持一个线程占用.这需要一点点记忆.
• 设置OS内部的等待.那是O(1).睡眠的持续时间无关紧要.这是一个小而不变的成本.

就这样.

然而,糟糕的是忙于等待或进行轮询循环,因为这会导致实际的CPU使用率.只是在睡眠或等待中花费时间不会产生CPU使用率.

TL; DR:使用睡眠进行延迟,不要使用睡眠进行轮询.

我必须说,对睡眠的厌恶有时只是训练有素的反射.在谴责睡眠之前,一定要分析具体的用例.

Answer 2

不要使用 ASP.NET 工作进程来运行长时间运行的任务！

应用程序池可能随时被回收，您将丢失休眠线程。

考虑改用 Windows 服务。您可以使用数据库或消息传递在网站和 Windows 服务之间进行通信。