8

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

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

非常感谢。

4

6 回答 6

12

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

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

  1. 使用 Delegate.BeginInvoke()（最常用的技术）
  2. 使用计时器（几种变体）
  3. System.Threading.ThreadPool 提供了其他几个功能（BackGroundWorker 类、QueueUserWorkItem() 等）。
于 2009-04-14T14:23:38.713 回答
6

看看这个很棒的线程概述：

[BackgroundWorker] 提供以下功能：

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

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

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

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

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

于 2009-04-14T14:29:07.530 回答
4

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

您避免了UI 和后台工作人员的许多问题。

于 2009-04-14T14:24:09.007 回答
3

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

于 2009-04-14T14:23:48.697 回答
1

BackgroundWorker 类是一种向窗体添加线程以执行一些繁重操作而不阻塞 UI 的简单方法。你可以用线程做同样的事情，但编码要多一些。

于 2009-04-14T14:24:35.573 回答
1

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

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

于 2009-04-14T14:41:29.900 回答