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