众所周知,使用线程可以极大的提高应用程序的效率和响应性,提高用户体验,但是不可以无节制的使用线程,为什么呢?
线程的开销实际上是非常大的,我们从空间开销和时间开销上分别讨论。
线程的空间开销来自这四个部分:
OutOfMemoryException
。线程的时间开销来自这三个过程:
线程创建的时候,系统相继初始化以上这些内存空间。
接着CLR会调用所有加载DLL的DLLMain方法,并传递连接标志(线程终止的时候,也会调用DLL的DLLMain方法,并传递分离标志)。
线程上下文切换。一个系统中会加载很多的进程,而一个进程又包含若干个线程。但是一个CPU内核在任何时候都只能有一个线程在执行。为了让每个线程看上去都在运行,系统会不断地切换“线程上下文”:每个线程及其短暂的执行时间片,然后就会切换到下一个线程了。
这个线程上下文切换过程大概又分为以下5个步骤:
Spinlock
,并确定下一个要执行的线程,然后释放 Spinlock
。如果下一个线程不在同一个进程内,则需要进行虚拟地址交换。所以,由于要进行如此多的工作,所以创建和销毁一个线程就意味着代价“昂贵”,即使现在的CPU多核多线程,如无节制的使用线程,依旧会严重影响性能。
为了免程序员无节制地使用线程,微软开发了“线程池”技术。简单来说,线程池就是替开发人员管理工作线程。当一项工作完毕时,CLR不会销毁这个线程,而是会保留这个线程一段时间,看是否有别的工作需要这个线程。至于何时销毁或新起线程,由CLR根据自身的算法来做这个决定。
线程池技术能让我们重点关注业务的实现,而不是线程的性能测试。
微软除实现了线程池外,还需要关注一个类型:BackgroundWorker
。 BackgroundWorker
是在内部使用了线程池的技术:同时,在WinForm或WPF编码中,它还给工作线程和UI线程提供了交互的能力。
实际上, Thread
和 ThreadPool
默认都没有提供这种交互能力,而 BackgroundWorker
却通过事件提供了这种能力。这种能力包括:报告进度、支持完成回调、取消任务、暂停任务等。
BackgroundWorker
的简单示例如下:
csharpprivate BackgroundWorker backgroundWorker = new BackgroundWorker();
private void AsyncButton_Click(object sender, RoutedEventArgs e)
{
//注册要执行的任务
backgroundWorker.DoWork += BackgroundWorker_DoWork;
//注册报告进度
backgroundWorker.ProgressChanged += BackgroundWorker_ProgressChanged;
//注册完成时的回调
backgroundWorker.RunWorkerCompleted += BackgroundWorker_RunWorkerCompleted;
//设置允许任务取消
backgroundWorker.WorkerSupportsCancellation = true;
//设置允许报告进度
backgroundWorker.WorkerReportsProgress = true;
backgroundWorker.RunWorkerAsync();
}
private void Cancel_Click(object sender, RoutedEventArgs e)
{
//取消任务
if (backgroundWorker.IsBusy)
backgroundWorker.CancelAsync();
}
private void BackgroundWorker_RunWorkerCompleted(object? sender, RunWorkerCompletedEventArgs e)
{
//完成时回调
MessageBox.Show("BackgroundWorker RunWorkerCompleted");
}
private void BackgroundWorker_ProgressChanged(object? sender, ProgressChangedEventArgs e)
{
//报告进度
this.textbox.Text = e.ProgressPercentage.ToString();
}
private void BackgroundWorker_DoWork(object? sender, DoWorkEventArgs e)
{
BackgroundWorker? worker = sender as BackgroundWorker;
if (worker != null)
{
for (int i = 0; i < 20; i++)
{
if (worker.CancellationPending)
{
e.Cancel = true;
break;
}
worker.ReportProgress(i);
Thread.Sleep(100);
}
}
}
建议使用WinForm和WPF的开发人员使用 BackgroundWorker
。
ThreadPool
相对于 Thread
来说具有很多优势,但是 ThreadPool
在使用上却存在一定的不方便。比如:
ThreadPool
不支持线程的取消、完成、失败通知等交互性操作。ThreadPool
不支持线程执行的先后次序。所以随着 Task
类及其所提供的异步编程模型的引入,Task
相较ThreadPool
具有更多的优势。大概有一下几点:
Task是.NET Framework的一部分,它提供了更高级别的抽象来表示异步操作或并发任务。相比之下,ThreadPool较为底层,需要手动管理线程池和任务队列。通过使用Task,我们可以以更简洁、更可读的方式表达并发逻辑,而无需关注底层线程管理的细节。
Task是基于Task Parallel Library(TPL)构建的核心组件,它提供了强大的异步编程支持。利用Task,我们能够轻松定义异步方法、等待异步操作完成以及处理任务结果。与此相反,ThreadPool主要用于执行委托或操作,缺乏直接的异步编程功能。
Task在底层使用ThreadPool来执行任务,但它提供了更优秀的性能和资源管理机制。通过使用Task,我们可以利用TPL提供的任务调度器,智能化地管理线程池的大小、工作窃取算法和任务优先级。这样一来,我们能够更有效地利用系统资源,并获得更好的性能表现。
Task拥有强大的任务关联和组合功能。我们可以使用Task的 ContinueWith()
、 When()
、WhenAll()
、Wait()
等方法定义任务之间的依赖关系,以及在不同任务完成后执行的操作。这种任务组合方式使并发编程更加灵活且易于管理。
Task提供了更好的异常处理和取消支持机制。我们可以利用Task的异常处理机制捕获和处理任务中的异常,而不会导致整个应用程序崩溃。此外,Task还引入 CancellationToken
的概念,可用于取消任务的执行,从而更好地控制并发操作。
所以,尽管ThreadPool在某些情况下仍然有其用途,但在C#编程中,使用Task替代ThreadPool已变为通用实践,推荐优先考虑使用Task来处理并发任务。
以上部分内容引用自
编写高质量代码:改善C#程序的157个建议 / 陆敏技著.一北京:机械工业出版社,2011.9
本文作者:Peter.Pan
本文链接:
版权声明:本博客所有文章除特别声明外,均采用 BY-NC-SA 许可协议。转载请注明出处!