## Case #3: 在 ThreadPool 內部等待其他 ThreadPool 工作導致死鎖/卡住

### Problem Statement（問題陳述）
業務場景：一個 ThreadPool 任務在回呼中排入另一個 ThreadPool 任務，並同步等待其完成（例如 WaitOne 或 Task.Wait）。當工作數量大、Pool 執行緒不足時，出現卡住或死鎖狀況。
技術挑戰：避免 ThreadPool 內部同步等待 ThreadPool，造成自我阻塞。
影響範圍：吞吐量、延遲、可靠性。
複雜度評級：高

### Root Cause Analysis（根因分析）
直接原因：
1. 在 ThreadPool 執行緒上阻塞等待另一個 ThreadPool 工作。
2. MinThreads 太低，無新執行緒可執行被等待的工作。
3. 無超時/退避策略。
深層原因：
- 架構層面：工作依賴未分離，缺乏非阻塞工作流。
- 技術層面：同步等待錯誤用法。
- 流程層面：缺少死鎖檢測與案例測試。

### Solution Design（解決方案設計）
解決策略：以非阻塞續延（回呼/事件）取代同步等待；或將依賴工作移至專用執行緒；同時設定合理 MinThreads 與超時，並建立壓測與死鎖告警。

實施步驟：
1. 改為非阻塞續延
- 實作細節：以回呼或事件通知完成，不在 ThreadPool 上 WaitOne。
- 所需資源：設計工作流
- 預估時間：0.5-1 天
2. 風險緩解與監控
- 實作細節：超時、重試、死鎖警示
- 所需資源：監控/日誌
- 預估時間：0.5 天

關鍵程式碼/設定：
```csharp
// Anti-pattern
ThreadPool.QueueUserWorkItem(_ =>
{
    var evt = new ManualResetEvent(false);
    ThreadPool.QueueUserWorkItem(__ => { DoB(); evt.Set(); });
    // 阻塞等待（危險）
    evt.WaitOne(); // 可能卡死
    DoA();
});

// Non-blocking 替代：用回呼串接
ThreadPool.QueueUserWorkItem(_ =>
{
    ThreadPool.QueueUserWorkItem(__ =>
    {
        DoB();
        // 完成後再做 A
        DoA();
    });
});

## Case #4: 共享計數器競態（用 Interlocked 或 lock 修正）

### Problem Statement（問題陳述）
業務場景：用 ThreadPool 平行處理訂單計數與統計，偶發總數不一致。顯示有競態條件。
技術挑戰：消除資料競態，維護一致性且不過度犧牲效能。
影響範圍：報表正確性、財務風險、信任度。
複雜度評級：低

### Root Cause Analysis（根因分析）
直接原因：
1. 多執行緒同時寫入共享整數。
2. 缺少同步/原子操作。
3. 沒有測試競態情境。
深層原因：
- 架構層面：共享狀態過多。
- 技術層面：未使用 Interlocked/lock。
- 流程層面：缺乏壓力與並發測試。

### Solution Design（解決方案設計）
解決策略：對共享計數採用 Interlocked.Increment，或使用 lock/Monitor 保護臨界區；若讀多寫少可用 ReaderWriterLockSlim。

實施步驟：
1. 將 ++ 改為 Interlocked
- 實作細節：Interlocked.Increment(ref counter)
- 所需資源：無
- 預估時間：0.5 小時
2. 若有複合操作，用 lock 包裹
- 實作細節：鎖定一致性
- 所需資源：無
- 預估時間：0.5 小時

關鍵程式碼/設定：
```csharp
// Wrong
counter++;

// Right
Interlocked.Increment(ref counter);

// 或
lock (_sync) { counter++; Log(counter); }

## Case #5: AutoResetEvent 驅動的生產者-消費者

### Problem Statement（問題陳述）
業務場景：需將零散工作（影像任務）順序消費，避免忙等與高開銷輪詢。
技術挑戰：省資源喚醒、避免空轉、確保消費者在有工作時才運行。
影響範圍：CPU、功耗、延遲。
複雜度評級：中

### Root Cause Analysis（根因分析）
直接原因：
1. 輪詢隊列造成 CPU 空轉。
2. 無事件通知機制。
3. 缺少安全併發隊列。
深層原因：
- 架構層面：未引入阻塞通知。
- 技術層面：未用 AutoResetEvent/Monitor.Pulse。
- 流程層面：未做低負載節能考量。

### Solution Design（解決方案設計）
解決策略：以 AutoResetEvent（或 Monitor.Wait/Pulse）實作 Producer-Consumer；生產者入列後 Set 喚醒，消費者 WaitOne 等待。

實施步驟：
1. 建立安全隊列與事件
- 實作細節：Queue<T> + lock + AutoResetEvent
- 所需資源：C# 基本類型
- 預估時間：1 小時
2. 生產/消費流程
- 實作細節：入列後 Set；消費端 WaitOne 取出
- 預估時間：1 小時

關鍵程式碼/設定：
```csharp
Queue<Job> _q = new Queue<Job>();
AutoResetEvent _evt = new AutoResetEvent(false);
object _sync = new object();

void Produce(Job j) {
    lock (_sync) { _q.Enqueue(j); }
    _evt.Set(); // 通知有工作
}

void ConsumeLoop() {
    while (true) {
        _evt.WaitOne(); // 等待通知
        Job j = null;
        lock (_sync) { if (_q.Count > 0) j = _q.Dequeue(); }
        if (j != null) Process(j);
    }
}

## Case #6: ManualResetEvent 協調多工收斂（Fan-in）

### Problem Statement（問題陳述）
業務場景：將一筆工作拆成 N 個平行子任務，需等待全部完成再合併。
技術挑戰：高效等待多個任務完成，避免大量輪詢。
影響範圍：延遲、吞吐、可維護性。
複雜度評級：中

### Root Cause Analysis（根因分析）
直接原因：
1. 使用忙等/輪詢等待完成。
2. 沒有集中收斂機制。
3. 不當使用 WaitOne 多次導致邏輯錯誤。
深層原因：
- 架構層面：缺少 fan-in 設計。
- 技術層面：不熟悉 ManualResetEvent 用法。
- 流程層面：未做正確性測試。

### Solution Design（解決方案設計）
解決策略：為每個子任務使用 ManualResetEvent，主執行緒 WaitHandle.WaitAll 等待全部完成；任務數 > 64 時改用計數器收斂。

實施步驟：
1. N 個任務 + N 個事件
- 實作細節：每個任務完成 Set 寫回
- 預估時間：1 小時
2. WaitAll 或計數器
- 實作細節：<=64 用 WaitAll；>64 用原子計數 + 單一 event
- 預估時間：1 小時

關鍵程式碼/設定：
```csharp
int n = 10;
var events = Enumerable.Range(0, n).Select(_ => new ManualResetEvent(false)).ToArray();

for (int i = 0; i < n; i++) {
    int idx = i;
    ThreadPool.QueueUserWorkItem(_ =>
    {
        DoWork(idx);
        events[idx].Set();
    });
}

WaitHandle.WaitAll(events); // 等待全部完成

## Case #7: 混合 CPU/IO 任務的併發管線化

### Problem Statement（問題陳述）
業務場景：每筆請求包含 IO 下載 + CPU 轉檔兩階段。單一併發模型造成某階段閒置、另一階段瓶頸。
技術挑戰：最大化流水線吞吐量，避免互相阻塞。
影響範圍：吞吐、資源使用率。
複雜度評級：高

### Root Cause Analysis（根因分析）
直接原因：
1. 單一併發度無法同時最適化 IO 與 CPU。
2. IO 阻塞佔滿 ThreadPool。
3. 無背壓機制，導致隊列暴增。
深層原因：
- 架構層面：缺少分段化與背壓設計。
- 技術層面：未區分 IO 與 CPU 執行緒。
- 流程層面：未建立端到端量測。

### Solution Design（解決方案設計）
解決策略：拆為兩段管線（IO、CPU），各自配置併發度與隊列；使用 AutoResetEvent 或 Monitor 控制生產與消費；對 IO 段導入非同步 I/O 或專用執行緒，CPU 段以 ThreadPool 處理。

實施步驟：
1. 建立兩段隊列與事件
- 實作細節：IO -> 中介隊列 -> CPU
- 預估時間：1-2 天
2. 併發度與背壓
- 實作細節：以 Semaphore/容量上限控制進出
- 預估時間：1 天

關鍵程式碼/設定：
```csharp
// 簡化示例：IO 下載完成後入列 CPU 階段
void IoStage(Uri u) {
    var data = Download(u); // 建議改 async I/O
    lock (_midSync) _midQ.Enqueue(data);
    _midEvt.Set();
}

void CpuStageLoop() {
    while (true) {
        _midEvt.WaitOne();
        byte[] data = null;
        lock (_midSync) if (_midQ.Count > 0) data = _midQ.Dequeue();
        if (data != null) ThreadPool.QueueUserWorkItem(_ => Encode(data));
    }
}

## Case #8: ThreadPool 回呼未捕捉例外導致程序終止/工作丟失

### Problem Statement（問題陳述）
業務場景：偶發性程式崩潰或任務悄然失敗未記錄。ThreadPool 回呼拋出未處理例外時，.NET 版本不同策略不同，可能終止進程或靜默失敗。
技術挑戰：確保所有回呼都有可靠的例外攔截與記錄。
影響範圍：可靠性、可觀測性。
複雜度評級：低

### Root Cause Analysis（根因分析）
直接原因：
1. 回呼中未 try/catch。
2. 未設全域例外處理/日誌。
3. 測試未覆蓋例外路徑。
深層原因：
- 架構層面：缺少觀測性規範。
- 技術層面：忽略 ThreadPool 例外行為差異。
- 流程層面：無錯誤注入測試。

### Solution Design（解決方案設計）
解決策略：所有 ThreadPool 回呼以 try/catch 包裹，集中上報；設置 AppDomain.UnhandledException 與 TaskScheduler.UnobservedTaskException（若使用 Task）捕捉。

實施步驟：
1. 回呼包裹
- 實作細節：統一封裝 Wrapper 執行回呼
- 預估時間：0.5 天
2. 全域攔截+告警
- 實作細節：記錄與告警通道
- 預估時間：0.5 天

關鍵程式碼/設定：
```csharp
void SafeQueue(Action a) {
    ThreadPool.QueueUserWorkItem(_ =>
    {
        try { a(); }
        catch (Exception ex) { Log(ex); Alert(ex); }
    });
}

## Case #9: 無界工作佇列導致記憶體飆升與延遲堆積

### Problem Statement（問題陳述）
業務場景：入口將請求直接入列（List/Queue），峰值時佇列快速膨脹，最終 OOM 或延遲爆表。
技術挑戰：引入背壓/限速，避免無界成長。
影響範圍：穩定性、成本、SLA。
複雜度評級：中

### Root Cause Analysis（根因分析）
直接原因：
1. 無界佇列。
2. 生產速度遠大於消費速度。
3. 無丟棄策略。
深層原因：
- 架構層面：缺背壓設計。
- 技術層面：缺少容量控制。
- 流程層面：無容量壓測。

### Solution Design（解決方案設計）
解決策略：將佇列改為有界，配合 Semaphore/旗標控制入列；超過上限時阻塞、丟棄或降級；暴露佇列長度指標。

實施步驟：
1. 有界佇列
- 實作細節：容量上限 + 入列前檢查
- 預估時間：1 天
2. 策略與監控
- 實作細節：阻塞/丟棄/降級策略
- 預估時間：0.5 天

關鍵程式碼/設定：
```csharp
const int MaxQueue = 1000;
Queue<Job> _q = new Queue<Job>();
object _sync = new object();

bool TryEnqueue(Job j) {
    lock (_sync) {
        if (_q.Count >= MaxQueue) return false; // 丟棄或降級
        _q.Enqueue(j);
        return true;
    }
}

## Case #10: WaitHandle.WaitAll 的 64 限制繞過

### Problem Statement（問題陳述）
業務場景：一次啟動上百個子任務並等待全部完成。直接使用 WaitAll 觸發「最多 64 個 Handle」限制。
技術挑戰：在大量任務情況下安全收斂。
影響範圍：可伸縮性、正確性。
複雜度評級：中

### Root Cause Analysis（根因分析）
直接原因：
1. WaitAll 限制 64 個 Handle。
2. 每任務一個 ManualResetEvent。
3. 缺乏替代收斂機制。
深層原因：
- 架構層面：未考量海量任務的收斂設計。
- 技術層面：不了解 API 限制。
- 流程層面：缺測試大 N。

### Solution Design（解決方案設計）
解決策略：使用原子計數 + 單一 ManualResetEvent 作為「自製 CountdownEvent」；子任務完成時遞減，為 0 時 Set 喚醒。

實施步驟：
1. 實作計數收斂
- 實作細節：Interlocked.Decrement 與 ManualResetEvent
- 預估時間：1 小時
2. 大 N 壓測
- 實作細節：驗證正確性與性能
- 預估時間：1 小時

關鍵程式碼/設定：
```csharp
int remaining = n;
ManualResetEvent done = new ManualResetEvent(false);

for (int i = 0; i < n; i++) {
    ThreadPool.QueueUserWorkItem(_ =>
    {
        DoWork();
        if (Interlocked.Decrement(ref remaining) == 0)
            done.Set();
    });
}

done.WaitOne(); // 等全部完成

## Case #11: 多執行緒寫檔競爭與序列化寫入

### Problem Statement（問題陳述）
業務場景：多個 ThreadPool 任務同時寫入同一日誌檔，產生交錯與 IO 例外。
技術挑戰：在高併發下確保檔案寫入有序與可靠。
影響範圍：可觀測性、資料完整性。
複雜度評級：中

### Root Cause Analysis（根因分析）
直接原因：
1. 同一檔案的並行寫入。
2. 缺少寫入序列化。
3. 無重試/緩衝。
深層原因：
- 架構層面：無專用寫入器。
- 技術層面：檔案鎖與緩衝策略不足。
- 流程層面：缺少壓測與故障注入。

### Solution Design（解決方案設計）
解決策略：導入單 Writer 執行緒與寫入佇列；工作入列，Writer 線程序列化寫入；必要時批次寫入提升效能。

實施步驟：
1. 建寫入佇列
- 實作細節：Queue<string> + AutoResetEvent
- 預估時間：1 天
2. Writer 線程
- 實作細節：專線 loop 處理，批次 flush
- 預估時間：0.5 天

關鍵程式碼/設定：
```csharp
Queue<string> _logQ = new Queue<string>();
AutoResetEvent _logEvt = new AutoResetEvent(false);
object _logSync = new object();

void Log(string line) {
    lock (_logSync) _logQ.Enqueue(line);
    _logEvt.Set();
}

void WriterLoop() {
    using (var sw = new StreamWriter("app.log", true)) {
        while (true) {
            _logEvt.WaitOne();
            List<string> batch = new List<string>();
            lock (_logSync) while (_logQ.Count > 0) batch.Add(_logQ.Dequeue());
            foreach (var l in batch) sw.WriteLine(l);
            sw.Flush();
        }
    }
}

## Case #12: 背景工作卡住主執行緒（UI）之解法

### Problem Statement（問題陳述）
業務場景：桌面應用（WinForms/WPF）在主執行緒進行重任務，UI 停滯。需要將重任務改到背景執行並回拋 UI 更新。
技術挑戰：正確跨執行緒更新 UI。
影響範圍：使用者體驗、可用性。
複雜度評級：中

### Root Cause Analysis（根因分析）
直接原因：
1. 重任務在 UI 執行緒執行。
2. 跨執行緒直接更新 UI 控制項。
3. 無回拋機制。
深層原因：
- 架構層面：UI 與工作未解耦。
- 技術層面：未使用 SynchronizationContext/Invoke。
- 流程層面：缺少 UI 響應性測試。

### Solution Design（解決方案設計）
解決策略：將工作丟至 ThreadPool，完成後透過 SynchronizationContext.Post 或 Control.Invoke 回拋 UI 更新。

實施步驟：
1. 背景執行
- 實作細節：QueueUserWorkItem 執行
- 預估時間：0.5 天
2. 回拋 UI
- 實作細節：WindowsFormsSynchronizationContext 或 Dispatcher
- 預估時間：0.5 天

關鍵程式碼/設定：
```csharp
var ctx = SynchronizationContext.Current; // UI thread context

ThreadPool.QueueUserWorkItem(_ =>
{
    var result = DoHeavyWork();
    ctx.Post(__ => { UpdateUI(result); }, null);
});

## Case #13: 調整 ThreadPool Min/Max 改善冷啟與尖峰

### Problem Statement（問題陳述）
業務場景：服務在尖峰突增負載時，首波延遲明顯升高。懷疑與 ThreadPool 初始執行緒數不足、擴張速度有關。
技術挑戰：在不過度浪費資源下，改善冷啟延遲與尖峰吞吐。
影響範圍：延遲、SLA。
複雜度評級：中

### Root Cause Analysis（根因分析）
直接原因：
1. MinThreads 太低。
2. 工作爆發時擴張遲滯。
3. 缺乏壓測與基準。
深層原因：
- 架構層面：未做容量規劃。
- 技術層面：對 ThreadPool 擴張策略不熟。
- 流程層面：無定期調參流程。

### Solution Design（解決方案設計）
解決策略：以壓測找出合適 MinThreads；必要時調整 MaxThreads；觀測 CPU 使用率與延遲平衡點；加入啟動預熱策略。

實施步驟：
1. 建立壓測
- 實作細節：固定 RPS、爆發式負載測試
- 預估時間：1 天
2. 調參與預熱
- 實作細節：SetMinThreads、預先排入暖身工作
- 預估時間：0.5 天

關鍵程式碼/設定：
```csharp
int workers, iocp;
ThreadPool.GetMinThreads(out workers, out iocp);
ThreadPool.SetMinThreads(Environment.ProcessorCount * 2, iocp);

// 可選：預熱
for (int i = 0; i < Environment.ProcessorCount; i++)
    ThreadPool.QueueUserWorkItem(_ => SpinWait.SpinUntil(() => false, 10));

## Case #14: 可取消工作：旗標 + ManualResetEvent

### Problem Statement（問題陳述）
業務場景：長任務需支援取消。既有設計缺少取消通道，無法快速停止。
技術挑戰：提供安全的合作式取消，避免資源洩漏。
影響範圍：使用者體驗、資源使用。
複雜度評級：中

### Root Cause Analysis（根因分析）
直接原因：
1. 無取消旗標/事件。
2. 阻塞等待不可中斷。
3. 清理流程缺失。
深層原因：
- 架構層面：無取消管道設計。
- 技術層面：未使用可中斷等待。
- 流程層面：未定義釋放規範。

### Solution Design（解決方案設計）
解決策略：以 volatile 旗標代表「請求取消」，搭配 ManualResetEvent 作為取消信號；工作點週期性檢查旗標與 WaitHandle，確保可中斷點清理後退出。

實施步驟：
1. 加入取消旗標與事件
- 實作細節：volatile bool; ManualResetEvent cancelEvt
- 預估時間：0.5 天
2. 任務中檢查可中斷點
- 實作細節：長迴圈、等待處使用 WaitHandle.WaitAny
- 預估時間：0.5 天

關鍵程式碼/設定：
```csharp
volatile bool _cancel;
ManualResetEvent _cancelEvt = new ManualResetEvent(false);

void RequestCancel() { _cancel = true; _cancelEvt.Set(); }

void Work() {
    while (!_cancel) {
        // 可中斷等待：工作事件或取消事件
        int signaled = WaitHandle.WaitAny(new WaitHandle[] { _workEvt, _cancelEvt });
        if (signaled == 1) break; // 取消
        DoUnitOfWork();
    }
    Cleanup();
}

## Case #15: 效能量測與 A/B 比較方法學（Before/After）

### Problem Statement（問題陳述）
業務場景：文章提及使用 ThreadPool 前後的效能差異。為了在專案中科學驗證，需要標準化量測方法與指標。
技術挑戰：可重複、可比較、可觀測的測試設計。
影響範圍：決策品質、資源配置。
複雜度評級：中

### Root Cause Analysis（根因分析）
直接原因：
1. 測試無一致基準。
2. 指標未定義。
3. 環境變異未控制。
深層原因：
- 架構層面：缺少性能工程流程。
- 技術層面：工具與腳本缺失。
- 流程層面：未納入 CI 性能關卡。

### Solution Design（解決方案設計）
解決策略：建立 A/B 測試框架，以固定工作集、固定 RPS/資料集；收集吞吐、P95/P99、CPU/Memory、上下文切換、ThreadPool 佔用；多輪測試取中位數，產出報告。

實施步驟：
1. 建基準測試
- 實作細節：Stopwatch、固定資料、暖機
- 預估時間：0.5-1 天
2. 指標收集與報告
- 實作細節：dotnet-counters/PerfView、CSV 輸出
- 預估時間：0.5 天

關鍵程式碼/設定：
```csharp
var sw = Stopwatch.StartNew();
int n = 10000;
var tasks = new ManualResetEvent[n];
// 量測 your pipeline（略）
sw.Stop();
Console.WriteLine($"Elapsed: {sw.ElapsedMilliseconds} ms");

## Case #16: 簡易 ThreadPool 實作（Queue + AutoResetEvent）

### Problem Statement（問題陳述）
業務場景：文章鏈接介紹 ThreadPool 實作與 AutoResetEvent/ManualResetEvent。為教學，手寫一個簡化版 ThreadPool 以理解運作。
技術挑戰：安全併發隊列、工作喚醒、關閉/釋放。
影響範圍：理解內部原理，提升診斷能力。
複雜度評級：高

### Root Cause Analysis（根因分析）
直接原因：
1. 不清楚工作如何被派發與喚醒。
2. 不熟悉事件的差異。
3. 無法釐清飢餓/死鎖根因。
深層原因：
- 架構層面：缺少對併發排程的心智模型。
- 技術層面：WaitHandle 與同步原語不熟。
- 流程層面：缺演練/實作機會。

### Solution Design（解決方案設計）
解決策略：以 Queue<Action> 作工作佇列，AutoResetEvent 作喚醒信號，一組 Worker 執行緒循環取工；提供 Enqueue、Start、Stop；支援關閉時排空與 Join。

實施步驟：
1. 佇列與喚醒
- 實作細節：lock + Queue + AutoResetEvent
- 預估時間：1 天
2. Worker 與關閉
- 實作細節：背景執行緒循環 + 關閉旗標
- 預估時間：1 天

關鍵程式碼/設定：
```csharp
class SimpleThreadPool : IDisposable {
    readonly Queue<Action> _q = new Queue<Action>();
    readonly AutoResetEvent _evt = new AutoResetEvent(false);
    readonly List<Thread> _workers = new List<Thread>();
    volatile bool _running = true;
    readonly object _sync = new object();

    public SimpleThreadPool(int workerCount) {
        for (int i=0; i<workerCount; i++) {
            var th = new Thread(Worker) { IsBackground = true };
            _workers.Add(th); th.Start();
        }
    }

    void Worker() {
        while (_running) {
            Action job = null;
            lock (_sync) if (_q.Count > 0) job = _q.Dequeue();
            if (job != null) { try { job(); } catch (Exception ex) { Log(ex); } }
            else _evt.WaitOne(); // 無工作則等待
        }
    }

    public void Enqueue(Action a) { lock (_sync) _q.Enqueue(a); _evt.Set(); }

    public void Dispose() {
        _running = false;
        _evt.Set(); // 喚醒退出
        foreach (var th in _workers) th.Join();
        _evt.Dispose();
    }
}