做上位機這幾年我越來越覺得C#并行處理不是“高級技巧”而是剛需。尤其是網(wǎng)絡(luò)應(yīng)用編程這個方向——你寫一個TCP服務(wù)端要同時扛幾十個客戶端你寫一個Modbus TCP采集程序要輪詢多臺設(shè)備你寫一個WinForms上位機既要收串口數(shù)據(jù)又要刷新界面——但凡哪個環(huán)節(jié)是同步阻塞的整個程序就卡在那里輕則丟幀重則假死。第7章專門講并行處理恰恰就是因為網(wǎng)絡(luò)編程里最大的敵人不是帶寬而是“等”。這章內(nèi)容適合誰適合已經(jīng)開始寫C#上位機、服務(wù)端或者網(wǎng)絡(luò)通信類程序的人也適合那些會用Task但說不清async/await狀態(tài)機、遇到死鎖只能重啟程序的開發(fā)者。讀完你至少能回答三個問題什么時候用多線程什么時候用Task哪些坑是必須躲開的1. 為什么網(wǎng)絡(luò)應(yīng)用編程總繞不開“并行”場景與選型思路1.1 先搞清楚并行、并發(fā)、多線程、Task到底什么關(guān)系聊并行處理之前很多人會把幾個概念混在一起。我習(xí)慣用一個生活類比并發(fā)是“一條流水線上多個工位輪流干活”并行是“多條流水線同時開工”。多線程是實現(xiàn)手段Task是更抽象的任務(wù)描述而并行則是一種目標。你不需要一上來就在腦子里糾結(jié)這些詞的區(qū)別但要知道在C#里你大部分時間操作的是Task和Task背后的線程池而不是直接new Thread。Thread是操作系統(tǒng)層面的東西創(chuàng)建和銷毀成本都不低線程多了還會導(dǎo)致上下文切換開銷暴漲。Task是線程池的“任務(wù)單”線程池里的線程會被復(fù)用任務(wù)進去排隊、執(zhí)行、返回這比手動管理線程要穩(wěn)得多。所以2025年寫C#默認選Task只有極少數(shù)需要控制線程名稱、線程優(yōu)先級、或者做底層插件隔離的場景我才會考慮直接用Thread。還有一層關(guān)系要說明并行處理不等于異步處理。異步主要解決“等I/O時不阻塞調(diào)用方”并行主要解決“多塊計算/多個請求同時做”。網(wǎng)絡(luò)應(yīng)用編程里兩者經(jīng)常同時出現(xiàn)你用ReadAsync異步讀Socket不阻塞線程又用Task.WhenAll同時發(fā)起多個設(shè)備的采集請求并行。分開理解后面代碼才不會寫亂。1.2 網(wǎng)絡(luò)編程里并行處理的四個典型場景以我這些年寫上位機和網(wǎng)絡(luò)服務(wù)的經(jīng)驗并行處理在C#網(wǎng)絡(luò)應(yīng)用中出現(xiàn)在四類典型場景第一類多客戶端并發(fā)接入。TCP服務(wù)端要同時維持幾十、上百個連接每個連接有獨立的收發(fā)循環(huán)。這里不是“快不快”的問題而是“能不能同時服務(wù)”的問題。如果循環(huán)接受連接后同步處理每個客戶端后面來的客戶端全部排隊這是不可接受的。第二類多設(shè)備并行采集或請求。比如Modbus TCP要輪詢多個從站或者通過HTTP調(diào)用多個接口。串行輪詢一圈可能耗時好幾秒并行請求可以把總耗時壓到最慢那個設(shè)備的耗時甚至壓到一次請求的耗時。第三類長時間操作的異步化。上位機里最常見的需求點擊“讀取數(shù)據(jù)”按鈕后臺去查數(shù)據(jù)庫或者等網(wǎng)絡(luò)響應(yīng)界面不能卡住。這時候必須把耗時操作扔到后臺線程/任務(wù)里等結(jié)果回來再通過界面調(diào)度器更新UI。第四類生產(chǎn)者-消費者模式。網(wǎng)絡(luò)收包線程不斷把數(shù)據(jù)塞進隊列處理線程從隊列里取數(shù)據(jù)做解析、存儲、顯示。這項設(shè)計能解耦“接收”和“處理”的速率差異是網(wǎng)絡(luò)程序穩(wěn)定性的基石。同一段程序里這四類場景很可能同時出現(xiàn)。所以掌握并行處理不是學(xué)會某個API而是學(xué)會一套架構(gòu)思維哪些東西必須串行哪些東西可以并行哪些資源需要保護起來。1.3 方案選擇的取舍Task不是萬能的鎖更是選型是第一步。我見過很多人一看到性能問題就開線程線程不夠就再開最后鎖問題把程序搞得一團糟。其實選擇順序有講究純計算密集且可拆分用Parallel.For/Parallel.ForEach配合ParallelOptions控制并發(fā)度。I/O密集操作網(wǎng)絡(luò)讀寫、數(shù)據(jù)庫、文件用async/await配合Task.WhenAll并行發(fā)起多個I/O。需要長期后臺運行的服務(wù)循環(huán)用Task.Run配合CancellationToken或者直接BackgroundService。需要線程間共享數(shù)據(jù)先看能不能不改共享再看能不能用ConcurrentDictionary等并發(fā)集合最后才輪到lock。這里有個關(guān)鍵認知鎖是必要但危險的工具。鎖能保護數(shù)據(jù)一致性但鎖太多、持鎖時間太長并行就退化成串行鎖順序不一致則可能死鎖。我在后面會專門展開講鎖的問題。原則是能用不可變數(shù)據(jù)就不可變能用并發(fā)集合就并發(fā)集合能把鎖范圍縮小就縮小。2. Task與async/await的核心用法拆解2.1 Task基礎(chǔ)創(chuàng)建、等待、結(jié)果獲取的正確姿勢先看創(chuàng)建Task的幾種常見方式。很多人一開始會混淆Task.Run、Task.Factory.StartNew以及直接new Task再Start。實際上現(xiàn)代C#我默認推薦Task.Run它封裝了線程池調(diào)度和默認參數(shù)從.net 4.5起就是最省心的入口Taskint task Task.Run(() FetchDataFromRemote()); int result await task; Console.WriteLine(result);Task.Factory.StartNew看起來更強大但它的默認參數(shù)比如調(diào)度器、取消、狀態(tài)經(jīng)常造成隱藏問題除非你要用TaskCreationOptions.LongRunning或者自定義調(diào)度器否則不要輕易選它。至于new Task(...).Start()這種寫法基本可以忘記。說到等待和獲取結(jié)果有幾種錯誤用法我?guī)缀趺看卧u審代碼都能見到用.Result同步阻塞獲取結(jié)果——這會導(dǎo)致當(dāng)前線程被阻塞如果調(diào)用方線程是UI線程且有一個SynchronizationContext在等就可能死鎖。用.Wait()干等一個永遠不會完成的任務(wù)——比如內(nèi)部有死鎖的任務(wù)。用Thread.Sleep在異步方法里拖延——應(yīng)該用await Task.Delay。獲取結(jié)果的正確姿勢很簡單在async方法里await。如果需要等待多個任務(wù)用Task.WhenAll或者Task.WhenAny。獲取單個任務(wù)結(jié)果之前可以先判斷IsCompletedSuccessfully不過日常場景多數(shù)直接await就夠了。2.2 async/await的狀態(tài)機與“不要用.Result阻塞”這條鐵律async/await看起來是語法糖但它背后生成的是一個狀態(tài)機。await之后的部分會被編譯為狀態(tài)機的下一個狀態(tài)也就是說代碼在await處“讓出”了當(dāng)前線程等任務(wù)完成后再回到同步上下文接著跑。這個機制讓異步代碼寫起來像同步代碼卻不會浪費線程。但狀態(tài)機的存在帶來一個核心鐵律不要用.Result或.Wait()阻塞去等待異步操作。為什么這條鐵律在UI程序里特別要命因為UI線程有一個SynchronizationContext它負責(zé)把后續(xù)代碼調(diào)度回UI線程。如果你在UI線程調(diào)用.ResultUI線程就卡住了而被等待的異步操作完成后想回到UI線程續(xù)跑卻發(fā)現(xiàn)UI線程已經(jīng)被自己占著于是一個等一個死鎖就這樣產(chǎn)生了。正確的做法是“一路異步到底”。比如// 錯誤UI線程阻塞 string data client.GetStringAsync(url).Result; // 正確UI線程讓出等結(jié)果回來再繼續(xù) string data await client.GetStringAsync(url);還有一個相關(guān)技巧在類庫代碼里使用ConfigureAwait(false)。這表示后續(xù)代碼不需要回到原同步上下文可以繼續(xù)在線程池線程上執(zhí)行能減少不必要的上下文切換。但在UI代碼或者需要訪問UI控件的地方不要使用它否則后續(xù)代碼可能跑到非UI線程上訪問控件引發(fā)跨線程異常。2.3 取消機制CancellationToken是必須的嗎“取消”在網(wǎng)絡(luò)應(yīng)用里不是可選項而是必備項。你發(fā)起了10個并行請求其中一個卡住超時如果不取消整個程序就要等它用戶點了“停止采集”后臺循環(huán)任務(wù)不響應(yīng)界面就會顯得像死機一樣。CancellationTokenSource簡稱CTS就是干這個的var cts new CancellationTokenSource(); cts.CancelAfter(TimeSpan.FromSeconds(5)); // 5秒后自動取消 Task.Run(async () { while (!cts.IsCancellationRequested) { var data await ReadFromNetworkAsync(cts.Token); Process(data); } }, cts.Token);這里有幾個實操細節(jié)容易踩坑第一把CancellationToken傳進所有支持它的API比如ReadAsync、WriteAsync、Task.Delay。否則超時之后調(diào)用還在繼續(xù)。第二用cts.CancelAfter實現(xiàn)超時比手動記時間再取消要可靠得多。很多時候你不需要一個單獨的超時任務(wù)只需要在創(chuàng)建CTS時指定超時時間。第三取消后要清理資源。CancellationTokenSource實現(xiàn)了IDisposable尤其是訂閱了Register回調(diào)和定時器的時候不釋放會造成句柄泄漏。建議用using包裹或者在任務(wù)結(jié)束時調(diào)用Dispose。第四**捕獲OperationCanceledException**是常規(guī)流程但不應(yīng)該吞掉它。多數(shù)情況下你需要做日志、清理狀態(tài)再決定是繼續(xù)循環(huán)還是退出。2.4 組合任務(wù)WhenAll、WhenAny的實戰(zhàn)對比并行請求多設(shè)備時組合任務(wù)的API是核心武器。Task.WhenAll等待所有任務(wù)完成適合“需要全部結(jié)果才能繼續(xù)”的場景var tasks devices.Select(device ReadDeviceAsync(device.Address)).ToArray(); var results await Task.WhenAll(tasks);Task.WhenAny則等第一個任務(wù)完成適合“誰先到用誰”“超時競爭”之類的場景。有一個經(jīng)典組合WhenAnyTask.Delay做超時控制var fetchTask FetchDataAsync(ct); var timeoutTask Task.Delay(3000, ct); var completedTask await Task.WhenAny(fetchTask, timeoutTask); if (completedTask timeoutTask) { // 超時處理 } else { var data await fetchTask; // 注意這里要再次await才能拿到結(jié)果或異常 }這個組合的效果是請求卡住時不用傻等。我第一次寫超時邏輯時直接在請求內(nèi)部判斷返回后來發(fā)現(xiàn)網(wǎng)絡(luò)層根本不返回只能在外層用這種競爭手段兜底。還有一個容易忽略的點WhenAll如果其中某個任務(wù)拋異常它會拋出AggregateException在await時通常直接拋第一個異常。如果你需要逐條捕獲每個請求的錯誤而不是全部失敗可以給每個任務(wù)單獨加try/catch并返回一個結(jié)果對象而不是讓W(xué)henAll直接炸掉。這也是我后期設(shè)計的習(xí)慣網(wǎng)絡(luò)批量操作永遠給每個請求單獨的異常邊界。3. 網(wǎng)絡(luò)通信場景下的并行實戰(zhàn)3.1 TCP多客戶端并發(fā)每連接一個Task的完整思路寫TCP服務(wù)端時最典型的錯誤就是循環(huán)里同步處理客戶端。正確思路是AcceptAsync接受連接后為每個客戶端開啟一個獨立的任務(wù)循環(huán)主循環(huán)繼續(xù)等待新連接。核心骨架大致如下public async Task StartServerAsync(CancellationToken ct) { var listener new TcpListener(IPAddress.Any, 9000); listener.Start(); while (!ct.IsCancellationRequested) { var client await listener.AcceptTcpClientAsync(ct); _ Task.Run(() HandleClientAsync(client, ct)); } }這里有幾個細節(jié)值得注意。第一個是_ Task.Run(...)這種“fire and forget”寫法——我們要的就是主循環(huán)不等待每個客戶端結(jié)束但這樣寫意味著異常不會自然冒出來必須在HandleClientAsync內(nèi)部捕獲并記錄日志否則異常會被吞掉排查時一臉懵。第二個是**“每連接一個任務(wù)”的資源邊界**。如果連接數(shù)很多每個連接都開Task.Run并不是無限擴張。線程池會限制活動線程數(shù)任務(wù)會排隊所以連接數(shù)上千時也能撐住但數(shù)據(jù)吞吐量可能下降。更進階的方案是用Channel統(tǒng)一管理收發(fā)隊列或者用SocketAsyncEventArgs做真正的異步I/O但那需要更高階的性能優(yōu)化一般項目走到Task.Run這步已經(jīng)夠用。第三個是每個客戶端收發(fā)的循環(huán)模式用.NET的NetworkStream在客戶端線程里做await stream.ReadAsync讀取字節(jié)流后解析再寫回。需要小心的是“半包/粘包”問題——TCP是字節(jié)流沒有消息邊界你讀到的一段數(shù)據(jù)可能只是半個包。折中方案是定義消息頭比如前4個字節(jié)表示長度循環(huán)讀取直到湊滿一整個消息再解析否則就需要自己做緩沖隊列。3.2 共享數(shù)據(jù)線程安全鎖、Interlocked與并發(fā)集合怎么選并行處理網(wǎng)絡(luò)數(shù)據(jù)必然出現(xiàn)多線程同時操作某些共享數(shù)據(jù)的問題。這里我按優(yōu)先級分享我的選型方式能用局部變量就用局部變量。就算數(shù)據(jù)看起來共享也可以每人一份副本處理完再合并。這消除了最大的安全隱患。能不用鎖就不用鎖用并發(fā)集合代替。比如多客戶端上報數(shù)據(jù)主程序要維護一個“在線客戶端狀態(tài)表”可以用ConcurrentDictionaryint, ClientState它的AddOrUpdate、TryGetValue內(nèi)部已經(jīng)做了同步省去自己加鎖帶來的顆粒度把控難題。需要自己加鎖的地方通常是修改一個復(fù)雜結(jié)構(gòu)的多個字段且操作無法用單個并發(fā)集合表達時。這時用lockprivate readonly object _sync new(); public void UpdateMetrics(string key, double value) { lock (_sync) { _metrics[key] value; } }鎖的坑有幾個。鎖對象必須專用私有object就夠了最好不要鎖this或字符串否則外部代碼可能意外牽扯。被鎖代碼要短——只是修改內(nèi)存狀態(tài)不要在里面寫數(shù)據(jù)庫、發(fā)網(wǎng)絡(luò)請求否則并發(fā)直接變串行。鎖順序要一致——兩個地方各自持有鎖A再鎖B另一處鎖B再鎖A就死鎖了。Interlocked則適用于最簡單的加減、交換場景比如計數(shù)器Interlocked.Increment(ref _messageCount);它無鎖、性能高但只支持有限的原子操作不適合復(fù)雜邏輯。還有一個容易被忽略的點集合和鎖配合時遍歷也要加鎖或拿到副本。ConcurrentDictionary在遍歷時是弱一致的如果遍歷期間集合被修改可能出現(xiàn)條目不一致但不會拋出異常。如果你需要遍歷時快照可以先ToArray()再遍歷避免邊遍歷邊修改引發(fā)的競態(tài)。3.3 UI線程與后臺任務(wù)協(xié)作搞懂SynchronizationContext再寫上位機寫WinForms或WPF上位機幾乎天天碰到一個異常InvalidOperationException: 線程間操作無效。這不是“把控件訪問代碼放到后臺線程”就能解決的真正要做的是理解上下文調(diào)度。WinForms有一個WindowsFormsSynchronizationContext它把await之后的代碼調(diào)度回UI線程。所以在UI事件處理器里直接await一個網(wǎng)絡(luò)操作后續(xù)代碼會自動回到UI線程可以安全訪問控件private async void btnRead_Click(object sender, EventArgs e) { btnRead.Enabled false; try { var value await ReadMeterAsync(); txtValue.Text value.ToString(); // 安全仍在UI上下文 } finally { btnRead.Enabled true; } }這里有個原則async void只用于事件處理器并且內(nèi)部必須有完整的try/catch吞下所有異常。其他方法應(yīng)該用async Task否則異常無法被調(diào)用方觀察到。如果后臺任務(wù)不是通過await回到UI線程而是通過Task.Run發(fā)起再手動更新UI怎么辦兩種情況一是后臺任務(wù)訪問控件需要借助Invokevar ui txtLog; if (ui.InvokeRequired) { ui.BeginInvoke(new Action(() ui.AppendText(msg))); } else { ui.AppendText(msg); }二是界面刷新頻率太高導(dǎo)致卡頓——這是大家常問的“C#控件多導(dǎo)致WinForm卡”的熱點問題。我實踐中的解法是后臺線程產(chǎn)生數(shù)據(jù)后不直接逐條推送UI而是緩沖到隊列用System.Windows.Forms.Timer定期比如100~500毫秒批量刷新。這樣UI只需響應(yīng)一個批量通知后臺任務(wù)就不會因為界面刷新慢而積壓。3.4 生產(chǎn)者-消費者模式解決網(wǎng)絡(luò)數(shù)據(jù)與界面刷新的節(jié)奏沖突生產(chǎn)者-消費者模式是網(wǎng)絡(luò)程序中最重要的架構(gòu)之一。把數(shù)據(jù)接收生產(chǎn)者和業(yè)務(wù)處理消費者解耦能有效解決“網(wǎng)絡(luò)包來得太快解析和界面根本跟不上的問題”?，F(xiàn)代C#里首選System.Threading.Channels庫實現(xiàn)。它比ConcurrentQueue更好用因為它天然支持異步讀寫和完成通知var channel Channel.CreateUnboundedstring(); // 生產(chǎn)者網(wǎng)絡(luò)接收線程 while (await reader.ReadAsync(ct)) { await channel.Writer.WriteAsync(line, ct); } // 消費者業(yè)務(wù)處理線程 await foreach (var item in channel.Reader.ReadAllAsync(ct)) { ProcessItem(item); }await foreach是異步流語法配合ReadAllAsync可以像同步循環(huán)一樣消費數(shù)據(jù)但不會占住線程等待。這個模式還有幾個注意事項。第一生產(chǎn)者寫入時要處理“消費者已關(guān)閉”的情況否則WriteAsync永遠掛起。第二消費者消費速度如果跟不上UnboundedChannel會無限積壓內(nèi)存所以生產(chǎn)環(huán)境應(yīng)限制隊列容量或做丟棄/合并策略。第三處理順序很重要時需要保證單消費者或者保證分區(qū)否則數(shù)據(jù)順序會亂。上位機場景里生產(chǎn)者是串口/網(wǎng)絡(luò)接收線程消費者是數(shù)據(jù)解析和曲線繪制邏輯中間夾一個Channel界面刷新節(jié)奏就和數(shù)據(jù)接收節(jié)奏解耦了。這是我調(diào)試Modbus TCP采集程序時最常用的一套組合——波形不卡、命令不丟、超時也好定位。3.5 網(wǎng)絡(luò)批量操作的并行與限流技巧說完架構(gòu)回到一個實操高頻場景批量讀取或批量寫入。假設(shè)你寫一個Modbus TCP客戶端需要輪詢32臺設(shè)備。串行寫法是每臺依次請求假設(shè)一臺需要300毫秒一輪就接近10秒。如果改成并行發(fā)起所有請求var tasks slaves.Select(s ReadSlaveAsync(s, ct)); await Task.WhenAll(tasks);理想情況下一輪能縮短到幾百毫秒。但盲目并行也有問題第一32個請求同時發(fā)出去網(wǎng)關(guān)或設(shè)備可能承受不住第二如果設(shè)備只能串行處理請求并發(fā)反而導(dǎo)致響應(yīng)超時。工程化的解法是限制并發(fā)度?？梢杂肧emaphoreSlim簡單限流private readonly SemaphoreSlim _gate new(5); // 最多5個并發(fā) private async Task ReadSlaveWithThrottleAsync(SlaveInfo slave, CancellationToken ct) { await _gate.WaitAsync(ct); try { await ReadSlaveAsync(slave, ct); } finally { _gate.Release(); } }這樣既能并行提速又能把并發(fā)控制在設(shè)備能承受的范圍內(nèi)。我曾經(jīng)用這個方法把一輪輪詢時間從9秒壓到2秒不到設(shè)備也沒有出現(xiàn)任何超時。還有一個批量數(shù)據(jù)寫入的經(jīng)典場景SqlBulkCopy。它的特點是一次性寫大批量數(shù)據(jù)本身內(nèi)部就是大塊傳輸比逐條INSERT快幾個數(shù)量級。但它的坑在于批量寫入時鎖定表和事務(wù)日志的負擔(dān)如果此時又開啟事務(wù)或者有別人在寫同一張表可能發(fā)生鎖等待甚至超時。我的建議是SqlBulkCopy寫入時盡量避開業(yè)務(wù)高峰分批寫入比如每批5萬行且不要和業(yè)務(wù)事務(wù)在同一個連接里交織。3.6 委托與事件在并行環(huán)境下的正確用法網(wǎng)絡(luò)應(yīng)用里經(jīng)常要用到回調(diào)通知。比如收到設(shè)備斷開事件通知UI刷新列表。這里涉及C#的委托和事件。很多初學(xué)者把這兩個東西當(dāng)成“寫方法的另一種方式”但在并行編程里它們的語義差別很重要。委托本質(zhì)是一個方法類型的變量可以賦值、傳參。事件是對委托的封裝只允許/-外部不能隨意觸發(fā)。在并行環(huán)境下事件回調(diào)在哪個線程執(zhí)行是一個隱含問題public event EventHandlerDataReceivedEventArgs? DataReceived; private void OnDataReceived(DataReceivedEventArgs e) { // 事件此刻可能在線程池線程上執(zhí)行 DataReceived?.Invoke(this, e); }訂閱者如果在回調(diào)里直接更新UI就會出現(xiàn)跨線程問題。所以我的習(xí)慣是事件發(fā)布者和訂閱者各自處理線程調(diào)度問題。發(fā)布者只負責(zé)通知訂閱者在回調(diào)里用Invoke或者async void調(diào)度到UI線程再更新界面而不是要求發(fā)布者去適配每個訂閱者的線程模型。另一個細節(jié)是事件處理器拋異常會向上傳播。在并行任務(wù)里如果回調(diào)里捕獲不到異常整個任務(wù)可能直接失敗。所以在回調(diào)入口包一層try/catch是標配必要時把異常寫入日志而不是讓事件鏈斷掉。4. 常見問題與排查技巧實錄4.1 五個高頻異常與對應(yīng)解決方案我把這些年C#并行網(wǎng)絡(luò)編程中遇到最多的異常整理成一個速查表方便你對照定位異常常見原因解決方案InvalidOperationException線程間操作無效后臺線程直接訪問UI控件用Invoke/BeginInvoke調(diào)度回UI線程或讓await在UI上下文繼續(xù)TaskCanceledException任務(wù)被取消或HttpClient.Timeout觸發(fā)內(nèi)部取消捕獲該異常并做超時/取消處理確認是否傳入了CancellationTokenObjectDisposedException對象TcpClient、CancellationTokenSource等已被釋放但還在使用檢查生命周期using范圍是否過早結(jié)束取消后是否還在訪問資源AggregateExceptionTask.WhenAll或Task.Wait中多個任務(wù)出錯后匯總await時處理內(nèi)部異常給每個子任務(wù)獨立異常邊界更合適SocketException比如10054對端強制關(guān)閉連接按業(yè)務(wù)判定是正常斷開還是錯誤需要區(qū)分重連邏輯只要記住一點絕大多數(shù)異常都不是代碼設(shè)計之外的“偶發(fā)”而是代碼生命周期管理出錯的必然表現(xiàn)。排查異常時先看對象生命周周期再看線程上下文最后才懷疑網(wǎng)絡(luò)本身。4.2 死鎖與資源爭用的排查思路死鎖是最讓人頭疼的。網(wǎng)絡(luò)應(yīng)用中的死鎖通常有三種形態(tài)。第一種是同步阻塞await導(dǎo)致的上下文死鎖。UI線程.Result等一個需要回UI線程繼續(xù)的任務(wù)互相等待。排查標志是程序卡死但其他線程正常暫停后看調(diào)用棧發(fā)現(xiàn)Task.Wait等待的SynchronizationContext永遠無法完成。第二種是鎖順序不一致導(dǎo)致的死鎖。兩個線程各持一把鎖想要對方的鎖。排查標志是程序整體無響應(yīng)轉(zhuǎn)儲或者調(diào)試時能看到線程棧停留在lock進入處。解決方法是全局統(tǒng)一鎖順序或者用SemaphoreSlim配合超時加鎖避免無限等。第三種是線程池饑餓。你用了大量Task.Run而他們的代碼里又有同步阻塞比如.Result消耗完線程池所有線程后新任務(wù)永遠排不上隊。排查標志任務(wù)一直不執(zhí)行CPU不高但吞吐量為0。解決辦法是減少同步阻塞給長期阻塞的任務(wù)單獨線程或者提高線程池最小線程數(shù)。排查最實用的工具是Visual Studio的“并行堆?！贝翱诤驮\斷工具中的線程面板?？ㄋ罆r暫停程序打開線程視圖找那些狀態(tài)為“等待”或“阻塞”的線程順著調(diào)用棧就能定位到等的是哪個資源。這個習(xí)慣比讀任何日志都管用。4.3 日志與診斷工具怎么定位到具體線程網(wǎng)絡(luò)程序并行運行日志如果只記時間不記線程出了并發(fā)問題基本等于沒日志。我的日志格式一定會包含線程ID和任務(wù)IDprivate static void Log(string message, LogLevel level LogLevel.Info) { var threadId Environment.CurrentManagedThreadId; var taskId Task.CurrentId ?? -1; Console.WriteLine($[{DateTime.Now:HH:mm:ss.fff}] [T{threadId}] [Task{taskId}] {message}); }這樣在排查“消息順序錯亂”“兩線程同時寫”時一看日志就能知道誰在跑。除了日志我常用的診斷工具還有幾個dotnet-counters觀察線程池活動線程數(shù)、隊列長度判斷是否線程池饑餓。ProcDump或dotnet-dump抓內(nèi)存轉(zhuǎn)儲分析死鎖、線程棧。Visual Studio性能探查器里的“并發(fā)可視化工具”可以直觀看到各線程的活動區(qū)間。每次排查我不直接看代碼而是先看數(shù)據(jù)線程池隊列多長活動線程多少異常時間點有沒有規(guī)律跟界面上用戶操作有沒有強關(guān)聯(lián)數(shù)據(jù)定位完再翻代碼通常半小時內(nèi)能找到根因。4.4 性能調(diào)優(yōu)的幾條個人經(jīng)驗最后聊幾條我踩過坑換來的經(jīng)驗談不上標準答案但每條都很實用。第一別盲目加并行度。網(wǎng)絡(luò)請求的瓶頸可能是設(shè)備本身、網(wǎng)絡(luò)帶寬、網(wǎng)關(guān)并發(fā)上限不是你的CPU。我踩過一次坑看到32個設(shè)備串行慢改成32個任務(wù)并發(fā)結(jié)果網(wǎng)關(guān)直接拒絕了一堆請求。后來限流到5個并發(fā)既穩(wěn)又快了。并行之前先把對端能力搞清楚。第二區(qū)分“計算密集”和“I/O密集”。對計算密集的任務(wù)并行度等于CPU核心數(shù)附近最優(yōu)對I/O密集的任務(wù)并行度可以遠高于核心數(shù)因為大多時間在等網(wǎng)絡(luò)返回。如果你發(fā)現(xiàn)CPU利用率很低但程序還是很慢那就是I/O瓶頸加線程沒用只有減少等待、增加異步才能真正提速。第三善用ValueTask減少異步分配。如果一個異步方法絕大多數(shù)情況下同步完成返回ValueTask能避免堆分配。但一般業(yè)務(wù)代碼不用過度優(yōu)化這只在熱路徑高頻調(diào)用時有意義。第四UI程序和后臺服務(wù)對并行處理的要求完全相反。后臺服務(wù)追求吞吐量和穩(wěn)定性UI程序追求不卡頓和響應(yīng)性。同樣的并行代碼放在UI線程里要多考慮調(diào)度問題放在后臺服務(wù)里要多考慮限流問題。不要一套代碼兩頭套。第五測試并行代碼必須引入壓力條件。單機、單客戶端、正常網(wǎng)絡(luò)下測不出并發(fā)問題。至少要模擬多客戶端同時連接、弱網(wǎng)環(huán)境、大數(shù)據(jù)量突發(fā)這些情況才是并行代碼真正見真章的時候。我每次提交網(wǎng)絡(luò)并行相關(guān)代碼前都會跑一輪“20個客戶端同時斷開”的場景很多問題就是這么暴露的。寫到這里關(guān)于C#網(wǎng)絡(luò)應(yīng)用編程中的并行處理核心的心法其實就一句話你的代碼不是同時干很多事而是要在“該等的時候不傻等該搶的時候不打架”之間找到平衡。把這章里那些Task的組合、線程安全的邊界、消息隊列的架構(gòu)、日志定位的手段真正用起來你的網(wǎng)絡(luò)程序再遇到連接風(fēng)暴、批量輪詢、界面卡死這類問題心里就會踏實很多。我也還在不斷踩坑希望這些經(jīng)驗?zāi)軒湍闵僮邘锥螐澛贰?