淺談 .NET 多執行緒與平行運算（十四）：平行運算前言與 ASP.NET 避坑指南

.NET 4.0 引入平行運算庫 (TPL, PLINQ)，封裝多執行緒複雜度，讓開發者輕鬆將迴圈平行化。但「易用」不等於「無副作用」，特別是 ASP.NET 應用，盲目套用可能導致效能下降甚至癱瘓。本文深度剖析平行運算適用場景與風險。

平行運算本質

將單一任務拆解為多個子任務，分配至多核心同時執行。.NET 4.0 前需手動分割資料、管理執行緒、同步結果；TPL 提供 Parallel.For、Parallel.ForEach、Task 等高階抽象，簡化開發。

為何 ASP.NET 需特別小心？

1. Web 本身已是多執行緒環境

IIS 執行緒池同時處理多個請求，每個請求一條執行緒。單一請求若再開啟平行執行緒，會與其他請求爭奪 CPU 核心，導致上下文切換暴增、吞吐量下降。

2. 缺乏多執行緒經驗的開發者易誤用

Web 開發者鮮少接觸底層執行緒同步，TPL 簡單語法（如 Parallel.ForEach(list, item => { ... })）極易誤以為是「免費加速」，忽略共享狀態、鎖競爭、非執行緒安全元件等陷阱。

六大潛在風險

1. 共享記憶體競爭：多執行緒同時累加計數器、修改集合，導致資料不一致。
2. 執行緒建立開銷：短小任務啟動百條執行緒，總耗時可能超過循序執行。
3. 框架元件非執行緒安全或內部鎖定：調用 .NET 類庫/第三方元件若內部有鎖，平行調用無法提升效能，甚至死鎖。
4. UI 執行緒存取：WinForms/WPF 需透過 Dispatcher/Invoke 回主執行緒更新 UI，Web 無此機制。
5. 死鎖與活鎖：多重鎖順序不一致、等待條件未滿足。
6. 除錯困難與平台差異：平行程式非確定性執行順序，重現 Bug 極難；單核機器無加速效果。

何時適合在 ASP.NET 使用平行運算？

• 獨立、CPU 密集、無共享狀態、耗時較長的純計算任務（如影像處理、大量加密運算）。
• 背景工作服務、Windows Service、Console App 等非請求回應模型。
• 搭配 Task.Run 卸載至背景執行緒池，但需控制併發度（MaxDegreeOfParallelism）。

最佳實踐建議

1. 優先考慮非同步 I/O (async/await) 而非平行運算，釋放執行緒處理更多請求。
2. 若必須平行化，嚴格限制 ParallelOptions.MaxDegreeOfParallelism（如 Environment.ProcessorCount / 2）。
3. 使用 ConcurrentBag、ConcurrentDictionary 等無鎖集合避免手動鎖定。
4. 完整壓力測試，監控 CPU、執行緒數、佇列長度、回應時間。

平行運算是利器，亦是雙面刃。ASP.NET 開發者應建立「非同步優先、平行謹慎」的架構思維。