C# 服务中的BackgroundWorker组件

我知道BackgroundWorker不应该在Windows服务中使用，但有没有人能提供一份好的在线参考资料来解释原因？

我在Windows服务中使用BackgroundWorker很多次，没有任何不良影响。虽然使用SynchronizationContext可能是不必要的，但我没有观察到它会导致问题或性能差。

BackgroundWorker依赖于当前设置的SynchronizationContext才能正常工作。它是专门为处理UI代码而设计的

---

在服务中自行管理线程通常更好，因为没有UI同步问题。在这里，使用线程API（或.NET 4任务API）是一个更好的选择。

好吧，在服务中使用BGW也没什么大不了的，它只是没有做任何特别有用的事情。其存在的原因是它能够在特定线程上引发ProgressChanged和RunWorkerCompleted事件。让代码在特定线程上运行是一件非常重要的事情。在线程执行代码时，不能简单地将调用注入线程。这导致了可怕的再进入问题。线程必须是“空闲”的，处于注入代码不会引起问题的状态

让线程处于空闲状态是一种相当不自然的情况。您使用线程来运行代码，而不是让它们无所事事地旋转。然而，这是UI线程的工作方式。它99%的时间都在消息循环中，等待Windows告诉它做些什么。一个按钮点击，一个绘画请求，一个键盘按下，诸如此类的事情。当它在消息循环中时，实际上是空闲的。执行注入代码的最佳时机

这就是Winforms的Control.Begin/Invoke和WPF的Dispatcher.Begin/Invoke所做的。它们将委托放入队列中，队列清空，委托目标由消息循环执行。WindowsFormsSynchronizationContext和DispatcherSynchronizationContext类是使用它们的同步提供程序。Winforms和WPF将SynchronizationContext.Current替换为它们的一个实例。这反过来又被BGW用来引发事件。这使得它们在UI线程上运行。它允许您从工作线程更新非线程安全的用户界面组件

您可能可以看到它的发展方向，服务两者都不使用。默认同步提供程序不同步任何内容。它只是使用一个线程池线程来调用Send或Post回调。这就是在服务中使用BGW时会发生的情况。事实上，举办这些活动毫无意义。您还可以让DoWork处理程序直接调用事件处理方法。毕竟，DoWork运行的线程也只是另一个线程池线程

---

好吧，除了让它慢一点之外，没有造成真正的伤害。

谢谢你，里德。我曾读到，它应该只用于用户界面代码，我从来没有在服务中使用过它，但我们的办公室出现了一些“危机”，一些人声称“它已经工作了很多年”之类的事情。我想让他们对这件事有一些独立的看法。为了提高Otavio解决“危机”的能力——以及我们的启发——为什么线程/任务API>BackgroundWorker会出现在服务中？C.劳伦斯报告没有不良影响：可能有什么不良影响？@djacobson:取决于所讨论的服务。如果没有同步上下文，BW只会增加一些额外的开销，而不会带来任何好处。如果您将它用于SC服务，例如WCF，它将按预期运行，但实际上仍然没有必要。简单地调用你的DoWork方法，并让它根据需要调用其他方法……因此，如果我有你的话，听起来主要是“最适合”的问题。这没什么错-谢谢你的详细说明。：）@djacobson：是的-BW只是使服务中的代码更加复杂和缓慢，没有任何优势