BackgroundWorker和Threads

Question

使用这两者来实现特定任务的利弊是什么。

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

非常感谢。

Answer 1

如果通过“Threads”意味着明确使用System.Threading.Thread类来创建，配置和启动自己的线程，那么答案是这样做更多的工作就在你身上，涉及更多的cpu周期而不仅仅是从线程池中拉出一个线程，（这是其他技术所做的），但它为您提供了更大的灵活性，因为它允许您指定线程优先级，以及使用线程池线程无法为您提供的其他一些特性。

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

1. 使用Delegate.BeginInvoke（）（最常用的技术）
2. 使用计时器（多种变体）
3. System.Threading.ThreadPool提供了其他一些功能（BackGroundWorker类，QueueUserWorkItem（）等）。

Answer 2

查看this great threading overview：

  

[BackgroundWorker]提供以下功能：

     

  

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

  

• 报告进度，完成和取消的标准协议

  

• IComponent的一个实现，允许它位于Visual Studio Designer中   工作线程上的异常处理

  

• 能够更新Windows窗体和WPF控件以响应工作进度或完成。

  

     

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

Answer 3

我用来将BackgroundWorker关联为Threads会做什么的包装器。所以我在GUI工作中使用BackgroundWorker，在更专业或更脏的工作（Windows服务等）上使用Threads

Answer 4

仅当您不必使用UI（WinForms或WPF）和后台工作程序时，才需要处理UI。

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

Answer 5

BackgroundWorker类是一种向Form添加线程以在不阻止UI的情况下执行某些繁重操作的简单方法。你可以用一个线程做同样的事情，但编码稍微多一些。

Answer 6

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

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