C# 多线程的四种打开方式
C# 发展到今天，多线程的写法也经历了几代演变。你不需要全都精通，但至少要知道它们是什么、什么时候用。
方式一：Thread — 最原始的一把锤子
Thread 是 .NET 最底层的线程类，给你最大的控制权，也意味着你要自己管好一切。
|
1 2 3 |
Thread thread = new Thread(DoWork); thread.IsBackground = true; // 设为后台线程，程序退出时自动带走 thread.Start(parameter); |
适合什么场景？长时间运行的独立任务，比如一个持续监听硬件数据的采集循环。
缺点也很明显：线程创建和销毁开销大，数量一多系统调度压力就上来了。
方式二：ThreadPool — 线程池，省着点用
既然创建线程贵，那我提前建好一批、用完放回去行不行？这就是线程池的思路。
|
1 2 3 4 |
ThreadPool.QueueUserWorkItem(state => { // 你的后台任务 }); |
适合短而频繁的小任务。但在上位机开发里用得不算多——因为我们的任务往往是"长驻"的。
方式三：Task — 现代 C# 的标配
Task 是 .NET 4.0 推出的 TPL（任务并行库）的核心，也是目前最主流的写法。
|
1 2 3 4 5 6 7 8 |
Task.Run(() => { // 后台干活 return result; }).ContinueWith(t => { // 干完了通知 UI }, TaskScheduler.FromCurrentSynchronizationContext()); |
它比 Thread 轻量，比 ThreadPool 灵活。绝大多数上位机场景，用 Task 就对了。
方式四：async/await — 最优雅的写法
如果说 Task 是标配，那 async/await 就是"顶配"。它让异步代码写起来跟同步代码一样顺。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
private async void btnStart_Click(object sender, EventArgs e) { btnStart.Enabled = false; try { // 后台去读数据，UI 线程不阻塞 var data = await Task.Run(() => ReadDataFromDevice()); // await 之后自动回到 UI 线程，直接更新控件 txtResult.Text = data; } finally { btnStart.Enabled = true; } } |
注意看，这里没有 Invoke，没有跨线程异常——await 帮你把后续代码自动封送回了 UI 线程。
一句话总结：能写 async/await 就别写别的，代码干净、bug 少。
跨线程更新 UI，这道坎必须过
做上位机，第一个会撞上的墙就是——"线程间操作无效: 从不是创建控件的线程访问它"。
这条规则你得刻在脑子里：只有创建控件的线程，才能修改控件。
WinForms 怎么搞
最朴素的写法，用 InvokeRequired 判断一下：
|
1 2 3 4 5 6 7 8 9 |
private void UpdateTextBox(string text) { if (txtLog.InvokeRequired) { txtLog.Invoke(new Action<string>(UpdateTextBox), text); return; } txtLog.AppendText(text + Environment.NewLine); } |
每个控件都写一遍太麻烦？封装个扩展方法一劳永逸：
|
1 2 3 4 5 6 7 8 9 10 11 12 |
public static class ControlExtensions { public static void InvokeIfRequired(this Control c, Action action) { if (c.InvokeRequired) c.Invoke(action); else action(); } } // 用起来就一行 txtLog.InvokeIfRequired(() => txtLog.AppendText("收到数据啦")); |
WPF 怎么搞
WPF 用 Dispatcher，思路是一样的：
|
1 2 3 4 |
Application.Current.Dispatcher.Invoke(() => { txtResult.Text = "数据已更新"; }); |
如果用了 MVVM 模式，那就更省心了——INotifyPropertyChanged 的绑定机制会自动处理线程切换，你在后台线程改 ViewModel 属性就行。
三个经典场景，拿来就能用
理论说了一堆，不来点实际的怎么行。下面这三个场景，做上位机的大概率会遇到。
场景一：串口数据持续采集
最常见的需求：打开串口，不停读数据，实时显示到界面上。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 |
private CancellationTokenSource _cts; private Task _readTask; private void btnStart_Click(object sender, EventArgs e) { _cts = new CancellationTokenSource(); _readTask = Task.Run(() => ReadLoop(_cts.Token)); btnStart.Enabled = false; btnStop.Enabled = true; } private void ReadLoop(CancellationToken token) { while (!token.IsCancellationRequested) { try { string data = serialPort.ReadLine(); txtLog.InvokeIfRequired(() => { txtLog.AppendText($"[{DateTime.Now:HH:mm:ss}] {data}\r\n"); }); } catch (Exception ex) { // 异常处理，别让线程崩了 } } } private void btnStop_Click(object sender, EventArgs e) { _cts?.Cancel(); btnStart.Enabled = true; btnStop.Enabled = false; } |
注意两个细节：
- • 用 CancellationToken 来停止，永远不要用 Thread.Abort()，那是暴力手段，容易把资源搞坏
- • 循环里一定要 try-catch，不然后台线程抛个异常，程序直接就没了
场景二：多设备并行读取
手上有五台设备要轮询，一台一台读太慢？并行走起：
|
1 2 3 4 5 6 7 8 9 10 |
private async Task<List<DeviceData>> ReadAllDevicesAsync(){ var tasks = new List<Task<DeviceData>>(); foreach (var device in _devices) { tasks.Add(Task.Run(() => device.ReadData())); } // 等所有设备都读完 var results = await Task.WhenAll(tasks); return results.ToList(); } |
Task.WhenAll 会等所有任务都完成，然后一次性给你结果。配合 async/await，代码干净得不像话。
场景三：生产者-消费者模式
数据采集速度快、处理速度慢，或者 UI 更新太频繁会卡？用队列做个缓冲。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
// 线程安全的队列 private BlockingCollection<DataFrame> _dataQueue = new BlockingCollection<DataFrame>(); // 生产者：采集线程，只管往队列里塞 void ProducerLoop() { while (true) { var frame = ReadFrameFromHardware(); _dataQueue.Add(frame); } } // 消费者：处理线程，慢慢从队列里取 void ConsumerLoop() { foreach (var frame in _dataQueue.GetConsumingEnumerable()) { ProcessAndDisplay(frame); } } |
BlockingCollection 是个好东西——队列空的时候消费者自动阻塞，不占 CPU；有数据来了自动唤醒。做数据缓冲、日志写入都很好用。
