在 Windows 服务中使用 Thread.Sleep()

发布于 2024-07-25 11:17:46 字数 268 浏览 2 评论 0原文

我正在编写一个需要长时间休眠的 Windows 服务(最长休眠时间为 15 小时,最短休眠时间为 30 分钟)。 我目前正在使用 Thread.Sleep(calculatedTime) 将我的代码置于睡眠模式。 Thread.Sleep 是最好的选择还是我应该使用计时器? 我已经在谷歌上搜索了一段时间,但找不到简洁的答案。 由于这是一个Windows服务,我不必担心锁定UI,所以我想不出不使用Thread.Sleep的理由。

任何见解将不胜感激。

I'm writing a windows service that needs to sleep for long periods of time (15 hrs is the longest it will sleep, 30 mins is the shortest). I'm currently using Thread.Sleep(calculatedTime) to put my code into sleep mode. Is Thread.Sleep the best option or should I be using a timer? I've been googling this for a while and can't find a concise answer. Since this is a windows service, I don't have to worry about locking the UI, so I can't think of a reason not to use Thread.Sleep.

Any insight would be appreciated.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

木槿暧夏七纪年 2024-08-01 11:17:46

我会使用计时器 Thread.Sleep,它可能会导致阻塞,从而阻止服务关闭。

如果间隔时间分布广泛且有规律,您也可以安排它。 但如果你谈论的是长的、不一致的间隔,那么计时器会更好。

I would use a timer, Thread.Sleep, could cause a blocking piece that could prevent the service from shutting down.

If the interval is that wide spread, and regular, you might just schedule it as well. But if you are talking about long, non-consistent intervals, then yes a Timer would be better.

花开浅夏 2024-08-01 11:17:46

由于服务控制管理器可能会随时要求停止服务,因此您的线程应该始终准备好响应这些请求,因此您不应使用 Thread.Sleep()。 相反,在主线程中创建一个手动重置事件,并在工作线程中使用其 WaitOne 方法并设置超时。 当时间到期时,WaitOne 将返回 false。

当调用服务类的 OnStop 或 OnShutdown 方法时,设置事件,这将导致 WaitOne 返回 true,然后您可以退出工作线程。

Since a service may be asked to stop at any time by the Service Control Manager, your thread should always be ready to respond to these requests, so you should not use Thread.Sleep(). Instead, create a manual-reset event in the main thread and use its WaitOne method with a timeout in your worker thread. WaitOne will return false when the time expires.

When your service class's OnStop or OnShutdown methods are called, set the event and that will cause WaitOne to return true and you can then exit your worker thread.

臻嫒无言 2024-08-01 11:17:46

在很多情况下,使用 Thread.Sleep() 通常被认为是不好的做法。

如果您希望该服务在后台运行,则应该使用计时器。

如果该服务只需要按计划的时间间隔运行,我建议您考虑使用 Windows 任务计划程序,以允许 Windows 在您需要时运行该应用程序。

It's generally regarded as bad practice to use Thread.Sleep() in a lot of cases.

If you want the service to run in the background, you should use a timer.

If the service only needs to be run at scheduled intervals, I'd recommend you look into using Windows task scheduler to allow Windows to run the application when you need it to.

所谓喜欢 2024-08-01 11:17:46

你不应该预先计算如此大量的时间并睡几个小时。 最多睡一分钟,然后醒来重新计算时间,再睡一分钟就可以了。 我认为计算非常便宜,或者可以通过缓存变得非常便宜。 我的建议试图缓解的问题是计算机时钟出人意料地“跳动”,这主要是由于网络时间服务纠正的时间漂移​​,也是因为夏令时,尤其是因为用户调整时钟。 因此,最好在如此长的时间间隔内不断重新计算时间,即使这意味着每分钟左右都要醒来。 如果您在“过去”醒来,请不要感到惊讶(即不要断言),时钟可以及时调整。

You should not pre-calculate such large amounts of time and sleep for hours. Sleep for a minute at best, then wake up and re-calculate the time, sleep again for no more that a minute. I assume the calculation is very cheap or it can be made very cheap with caching. The problem my advise is trying to mitigate is that computer clocks are surprisingly 'jumpy', mostly due to time drift corrected by network time service, also because of daylights savings and not least because user adjusting the clock. So is better to constantly recompute the time for such long intervals, even if it means waking up every minute or so. And don't be surprised (ie. don't assert) if you wake up in the 'past', clocks can adjust back in time.

小苏打饼 2024-08-01 11:17:46

另一件需要考虑的事情是,线程是有限的资源,每个线程都会为其堆栈消耗一部分内存(1MB?)。 它们还可能增加调度程序的负载。

现在,如果您的服务没有做太多其他事情,那么浪费的空间是微不足道的,但在开始分配多个线程之前意识到这一点是明智的。 使用线程池和/或计时器效率更高。

Another thing to consider is that threads are finite resources and each thread consumes a portion of memory (1MB?) for the its stack. They may also increase load for the scheduler.

Now, if your service isn't doing much else the wasted space is trivial, but it is wise to be aware of this before you start allocating multiple threads. Using a ThreadPool and/or Timers is much more efficient.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文