Question

我正在研究一个控制台应用程序，它将按照设定的时间间隔进行安排和运行，例如每30分钟一次。它的唯一目的是查询Web服务以更新一批数据库行。

Web服务API重新命令每30秒调用一次，并在设置的间隔后超时。以下伪代码作为示例给出：

listId := updateList(<list of terms>)
LOOP
  WHILE NOT isUpdatingComplete(listId)
END LOOP
statuses := getStatuses(“LIST_ID = {listId}”)

我已经用C＃粗略编写了这个：

int callCount = 0;
while( callCount < 5 && !client.isUpdateComplete(listId, out messages) )
{
    listId = client.updateList(options, terms, out messages);
    callCount++;
    Thread.Sleep(30000);
}
// Get resulting status...

在这种情况下使用Thread.Sleep（）是否可以？我知道这通常不是好的做法，但从阅读理由不使用它看起来似乎是可接受的用法。

感谢。

Answer 1

Thread.Sleep确保当至少指定的毫秒数后，当前线程才会返回。有很多地方适合这样做，你的例子看起来很好，假设它在后台线程上运行。

您不想使用它的一些示例 - 在UI线程上或您需要精确计时的位置。

Answer 2

一般来说，Thread.Sleep就像任何其他工具一样：完全可以使用，除非它被严重误用。我不同意“通常不是很好的做法”这一部分，这是人们在做其他事情时滥用Thread.Sleep的结果（即在同步对象上阻塞）。

在你的情况下，程序是单线程的，它没有UI（即线程没有消息循环），你不想与外部事件同步。因此Thread.Sleep就好了。

Answer 3

对Sleep（）的一般反对意见是它浪费了一个线程。

在你的情况下，只有一个线程（可能是2个），所以这不是一个真正的问题。

所以我觉得它看起来很好（但我会在29秒内减少一些松弛）。

Answer 4

没关系，除了你进入睡眠状态后不能打断它，不会中断线程（不推荐）。

这就是为什么ManualResetEvent可能是一个更好的主意，因为它可以从不同的线程发出信号（“唤醒”）。

Answer 5

你可以坚持使用Thread.Sleep方法。但是安排它每隔30分钟运行一次会更优雅 - 所以你不必在应用程序内部等待。

Answer 6

Thread.Sleep不是执行周期性逻辑的最佳选择。 Thread.Sleep（n）表示你的线程将放弃控制n毫秒。无法保证它会在n毫秒后重新获得控制权，这取决于CPU负载。

Answer 7

如果您将线程锁定30分钟，则应每30分钟安排一次Windows任务，以便程序执行然后结束。这样你就不会长时间锁定一个线程。

对于较短的时间，如30秒/ 1分钟，System.Thread.Sleep（）完全没问题。超过5分钟我将使用Windows任务。（我认为英语版本的西班牙语就像那样，我在谈论你从控制面板安排的任务;-)）

可接受使用Thread.Sleep（）

7 个答案: