BackgroundWorker 和线程答案

【问题标题】：BackgroundWorker and ThreadsBackgroundWorker 和线程
【发布时间】：2009-04-14 14:19:52
【问题描述】：

使用两者来完成给定任务的优缺点是什么。

百万美元的问题是使用哪一个以及何时使用？

非常感谢。

【问题讨论】：

【解决方案1】：

如果您所说的“线程”是指显式使用 System.Threading.Thread 类来创建、配置和启动您自己的线程，那么答案是您需要做更多的工作，涉及更多的 CPU 周期，而不仅仅是从线程池中拉出一个线程（这是其他技术所做的），但它为您提供了更大的灵活性，因为它允许您指定线程优先级，以及使用线程池线程无法提供的其他几个特性。

当所需的线程数在设计时未知时，“线程池”方法更合适。池最初包含少量线程，“准备好”供您调用它们。它可以按需动态创建新线程，并为您管理未使用线程的创建、协调和删除。您可以使用三种机制来访问和使用池中的线程。

使用 Delegate.BeginInvoke()（最常用的技术）
使用计时器（多种变体）
System.Threading.ThreadPool 提供了其他几个功能（BackGroundWorker 类、QueueUserWorkItem() 等）。

【讨论】：

【解决方案2】：

看看this great threading overview:

[BackgroundWorker] 提供以下功能：

“取消”标志，用于指示工作人员在不使用 Abort 的情况下结束

用于报告进度、完成和取消的标准协议

IComponent 的实现允许它位于 Visual Studio 设计器中工作线程上的异常处理

能够更新 Windows 窗体和 WPF 控件以响应工作人员的进度或完成情况。

最后两个功能特别有用 - 这意味着您不必在工作方法中包含 try/catch 块，并且无需调用 Control.Invoke 即可更新 Windows 窗体和 WPF 控件。

【讨论】：

【解决方案3】：

仅当您不必使用 UI（WinForms 或 WPF）时才使用线程，而当您必须处理 UI 时才使用后台工作人员。

您可以避免 UI 和后台工作人员的很多问题。

【讨论】：

【解决方案4】：

我曾经将 BackgroundWorker 关联为 Threads 将执行的操作的包装器。所以我在 GUI 工作上使用 BackgroundWorker，在更专业或更脏的工作（Windows 服务等）上使用线程

【讨论】：

【解决方案5】：

BackgroundWorker 类是一种向表单添加线程以执行一些繁重操作而不阻塞 UI 的简单方法。您可以对线程执行相同的操作，但代码要稍微多一些。

【讨论】：

【解决方案6】：

BackgroundWorker 类只是为您提供切换到 UI 线程上下文的事件，但不要混淆； DoWork 事件（实际上是你做工作的地方）仍然在另一个线程的上下文中执行（因为这是整个事情的重点）并且在那里执行任何类型的 UI 交互或更新都会在最好的，最坏的情况下崩溃。当您尝试执行需要更新 UI 并且其范围不超出表单范围的操作时，应在表单上使用 BackgroundWorker。对于其他后台操作，请考虑使用 ThreadPool（用于短期操作）或创建您自己的 Thread。

BackgroundWorker 为 ProgressChanged 事件提供了便利，但不要太适应并开始在 DoWork 中进行 UI 更新。

【讨论】：