## Case #2: 避免ThreadPool飢餓：將阻塞I/O改為非同步

### Problem Statement（問題陳述）
業務場景：Web/後端服務在高峰期向外部API與資料庫發出大量同步I/O請求，使用ThreadPool排程後經常出現請求逾時與延遲飆升。
技術挑戰：同步I/O會長時間占住ThreadPool工作緒，導致飢餓與排隊；需要改造為非同步且限制併發。
影響範圍：請求延遲、錯誤率、SLA。
複雜度評級：中

### Root Cause Analysis（根因分析）
直接原因：
1. 使用同步I/O導致ThreadPool工作緒長時間阻塞。
2. MinThreads過低，無法迅速補足負載。
3. 缺乏併發節流，瞬時大量請求壓垮外部資源。

深層原因：
- 架構層面：同步呼叫串接，未將I/O非同步化。
- 技術層面：未調整ThreadPool.MinThreads、未採用SemaphoreSlim限制併發。
- 流程層面：壓測場景不含峰值/抖動型負載。

### Solution Design（解決方案設計）
解決策略：將外部I/O改為async/await，釋放工作緒；以SemaphoreSlim限制對外並發數；適度提高ThreadPool最小工作緒以縮短尖峰時冷啟成本。

實施步驟：
1. 盤點I/O路徑
- 實作細節：找出HttpClient、DB、檔案I/O同步API
- 所需資源：程式碼審視、APM
- 預估時間：0.5天

2. I/O非同步化
- 實作細節：改用HttpClient.SendAsync、Db async API
- 所需資源：HttpClientFactory、EF/Dapper async
- 預估時間：1-2天

3. 併發節流
- 實作細節：SemaphoreSlim控制對外最大並發
- 所需資源：System.Threading
- 預估時間：0.5天

4. ThreadPool微調
- 實作細節：ThreadPool.SetMinThreads(適度提升)
- 所需資源：效能監控工具
- 預估時間：0.5天

關鍵程式碼/設定：
```csharp
private static readonly SemaphoreSlim _apiGate = new(initialCount: 50, maxCount: 50);

public async Task<string> CallExternalAsync(HttpRequestMessage req, CancellationToken ct)
{
    await _apiGate.WaitAsync(ct);
    try
    {
        using var client = _httpClientFactory.CreateClient("external");
        var rsp = await client.SendAsync(req, ct); // 非同步I/O不占用ThreadPool
        rsp.EnsureSuccessStatusCode();
        return await rsp.Content.ReadAsStringAsync(ct);
    }
    finally
    {
        _apiGate.Release();
    }
}

// 開機時（謹慎）提高MinThreads以縮短尖峰期排隊
ThreadPool.GetMinThreads(out var worker, out var io);
ThreadPool.SetMinThreads(Math.Max(worker, 200), io);

## Case #4: 工作切分顆粒度調優（Chunk Size Tuning）

### Problem Statement（問題陳述）
業務場景：已將CPU密集任務分割多工，但吞吐改善有限；懷疑工作切分顆粒太細造成排程成本高或太粗導致負載不均。
技術挑戰：尋找平衡點，降低排程與同步成本，改善負載平衡。
影響範圍：吞吐量、CPU使用率、延遲。
複雜度評級：中

### Root Cause Analysis（根因分析）
直接原因：
1. 顆粒過細：排程與同步成本顯著。
2. 顆粒過粗：尾端拖累（straggler）。
3. 缺乏動態調整策略。

深層原因：
- 架構層面：無Partition策略或工作竊取。
- 技術層面：無指標驅動調參。
- 流程層面：缺少A/B基準與實驗記錄。

### Solution Design（解決方案設計）
解決策略：採用範圍切分+塊大小估計，建立基準測試，調整chunk大小至使平均CPU接近100%、尾端耗時最低；必要時加入工作隊列動態分派。

實施步驟：
1. 度量當前耗時與CPU
2. 實作可調chunk大小
3. 基於數據調參
4. 如仍不佳，改為共享ConcurrentQueue由工人迴圈拉任務

關鍵程式碼/設定：
```csharp
int chunk = 50_000; // 可調參
var tasks = new List<WaitHandle>();
for (int start = 0; start < n; start += chunk)
{
    int s = start, e = Math.Min(start + chunk, n);
    var ev = new ManualResetEvent(false);
    tasks.Add(ev);
    ThreadPool.QueueUserWorkItem(_ =>
    {
        try { ProcessRange(s, e); }
        finally { ev.Set(); }
    });
}
WaitHandle.WaitAll(tasks.ToArray()); // 注意最多64個，超過請用CountdownEvent

## Case #5: 多工作項完成同步：CountdownEvent/Barrier

### Problem Statement（問題陳述）
業務場景：需要等所有ThreadPool工作完成再合併結果/回報狀態，過去用Thread.Sleep輪詢不可靠。
技術挑戰：可靠且低成本的完成同步。
影響範圍：正確性、資源釋放、延遲。
複雜度評級：低

### Root Cause Analysis（根因分析）
直接原因：
1. 使用Sleep/輪詢，耗時且不準。
2. WaitAll超過64個handle失效。
3. 沒有結束信號機制。

深層原因：
- 架構層面：未抽象出完成同步元件。
- 技術層面：對同步原語理解不足。
- 流程層面：缺少並發測試。

### Solution Design（解決方案設計）
解決策略：以CountdownEvent在提交工作前設定計數，工作完成Signal，主控Wait；多階段可用Barrier。

實施步驟：初始化、提交、Signal、Wait、合併

關鍵程式碼/設定：
```csharp
using var cde = new CountdownEvent(workerCount);
for (int i = 0; i < workerCount; i++)
{
    ThreadPool.QueueUserWorkItem(_ =>
    {
        try { DoWork(i); }
        finally { cde.Signal(); }
    });
}
cde.Wait(); // 所有完成

## Case #6: 背景工作例外處理與回報

### Problem Statement（問題陳述）
業務場景：ThreadPool背景任務偶發失敗但無記錄，造成資料不一致與難以除錯。
技術挑戰：在多工作項中捕捉例外、集中回報、不中斷其他工作。
影響範圍：資料正確性、維運成本。
複雜度評級：低-中

### Root Cause Analysis（根因分析）
直接原因：
1. 背景委派未包try/catch。
2. 無集中記錄/回報機制。
3. 任務彼此影響。

深層原因：
- 架構層面：缺少錯誤管道。
- 技術層面：未善用Concurrent集合/通道。
- 流程層面：缺少失敗演練。

### Solution Design（解決方案設計）
解決策略：每項工作try/catch，將例外放入ConcurrentQueue或Channel，主流程統一記錄/警示；必要時重試。

實施步驟：建立error sink、包裹工作、主控彙總

關鍵程式碼/設定：
```csharp
var errors = new System.Collections.Concurrent.ConcurrentQueue<Exception>();
using var cde = new CountdownEvent(n);

for (int i = 0; i < n; i++)
{
    int id = i;
    ThreadPool.QueueUserWorkItem(_ =>
    {
        try { DoFragileWork(id); }
        catch (Exception ex) { errors.Enqueue(ex); }
        finally { cde.Signal(); }
    });
}
cde.Wait();
foreach (var ex in errors) _logger.LogError(ex, "Work failed");

## Case #7: ThreadPool MinThreads 調校與尖峰應對

### Problem Statement（問題陳述）
業務場景：尖峰突刺流量導致初期延遲飆升，懷疑ThreadPool冷啟與MinThreads偏低。
技術挑戰：適度調整MinThreads以縮短尖峰時的擴張時間，避免無限制放大造成切換成本。
影響範圍：P95延遲、可擴展性。
複雜度評級：中

### Root Cause Analysis（根因分析）
直接原因：
1. MinThreads太低，尖峰期新請求排隊。
2. 任務多為短工作，擴張不及。

深層原因：
- 架構層面：尖峰未被吸震。
- 技術層面：不理解ThreadPool成長機制。
- 流程層面：壓測不足。

### Solution Design（解決方案設計）
解決策略：基於壓測提升MinThreads到可接受延遲下限；配合隊列/節流吸震；監看CPU切換。

實施步驟：壓測、調整、監控

關鍵程式碼/設定：
```csharp
ThreadPool.GetMinThreads(out var w, out var io);
ThreadPool.SetMinThreads(Math.Max(w, 200), io); // 值需經壓測校準

## Case #8: 生產線（Pipeline）模式：BlockingCollection 三階段處理

### Problem Statement（問題陳述）
業務場景：檔案處理需經「讀取->轉換->寫出」三階段，串行處理效能低且無法平衡I/O與CPU。
技術挑戰：建立多階段併行管線、控制緩衝與關閉流程。
影響範圍：吞吐、記憶體、可維運性。
複雜度評級：中-高

### Root Cause Analysis（根因分析）
直接原因：
1. 串行流程瓶頸明顯。
2. 無緩衝導致I/O/CPU互相等待。
3. 無關閉協定，易死鎖或漏處理。

深層原因：
- 架構層面：未管線化。
- 技術層面：未使用BlockingCollection/TPL Dataflow。
- 流程層面：缺少取消與關閉設計。

### Solution Design（解決方案設計）
解決策略：以兩個BlockingCollection連接三階段，設定有限容量做backpressure；各階段多工處理；正確CompleteAdding與消費結束。

實施步驟：定義兩個buffer、啟動三階段工作、處理完成與關閉

關鍵程式碼/設定：
```csharp
var readToTransform = new BlockingCollection<string>(boundedCapacity: 100);
var transformToWrite = new BlockingCollection<byte[]>(boundedCapacity: 100);
var cts = new CancellationTokenSource();

// 讀取
Task.Run(() =>
{
    try
    {
        foreach (var path in Directory.EnumerateFiles("in"))
            readToTransform.Add(path, cts.Token);
    }
    finally { readToTransform.CompleteAdding(); }
});

// 轉換
for (int i = 0; i < Environment.ProcessorCount; i++)
{
    Task.Run(() =>
    {
        foreach (var path in readToTransform.GetConsumingEnumerable(cts.Token))
        {
            var bytes = File.ReadAllBytes(path); // demo：實務可用Async
            var output = Transform(bytes);
            transformToWrite.Add(output, cts.Token);
        }
    });
}

// 寫出
Task.Run(() =>
{
    try
    {
        int idx = 0;
        foreach (var data in transformToWrite.GetConsumingEnumerable(cts.Token))
            File.WriteAllBytes($"out/{idx++}.bin", data);
    }
    finally { transformToWrite.CompleteAdding(); }
});

## Case #9: Backpressure 與記憶體控制（有界緩衝）

### Problem Statement（問題陳述）
業務場景：生產線第一階段速度太快，導致後段尚未消化前記憶體暴增甚至OOM。
技術挑戰：引入背壓，控制上游速度。
影響範圍：穩定性、成本。
複雜度評級：中

### Root Cause Analysis（根因分析）
直接原因：
1. 無界隊列導致無限制累積。
2. 無消費速率監控。

深層原因：
- 架構層面：無背壓設計。
- 技術層面：未使用bounded BlockingCollection/Channel。
- 流程層面：無容量基準。

### Solution Design（解決方案設計）
解決策略：所有中間隊列改為有界；Add/WriteAsync在滿時阻塞或等待；監測隊列長度自動調整。

實施步驟：改bounded、加監控、壓測調參

關鍵程式碼/設定：
```csharp
var queue = new BlockingCollection<WorkItem>(boundedCapacity: 1000);
// Add會在滿時阻塞 => 自然背壓

## Case #10: ASP.NET 以 SemaphoreSlim 限制外部資源併發

### Problem Statement（問題陳述）
業務場景：對第三方支付/簡訊API併發超過配額即返回429/失敗。
技術挑戰：在多進程/多執行緒請求下限制同時呼叫數。
影響範圍：成功率、成本。
複雜度評級：中

### Root Cause Analysis（根因分析）
直接原因：
1. 無併發閥門。
2. 重試無節制造成壅塞。

深層原因：
- 架構層面：集中共用閥門缺失。
- 技術層面：未使用SemaphoreSlim與async。
- 流程層面：配額管理缺失。

### Solution Design（解決方案設計）
解決策略：以應用層全域SemaphoreSlim管理對外同時執行，搭配重試與退避；若多實例，需分散式鎖或令牌桶。

實施步驟：建立閥門、包裝API客戶端、觀測與警示

關鍵程式碼/設定：
```csharp
public class RateLimitedClient
{
    private static readonly SemaphoreSlim Gate = new(initialCount: 10, maxCount: 10);
    private readonly HttpClient _client;
    public RateLimitedClient(HttpClient client) => _client = client;

    public async Task<HttpResponseMessage> SendAsync(HttpRequestMessage req, CancellationToken ct)
    {
        await Gate.WaitAsync(ct);
        try
        {
            return await _client.SendAsync(req, ct);
        }
        finally { Gate.Release(); }
    }
}

## Case #11: 防止Cache Stampede（驚群）— 單次生成、多方等結果

### Problem Statement（問題陳述）
業務場景：熱門頁面快取到期瞬間大量請求同時觸發昂貴生成導致雪崩。
技術挑戰：確保同一鍵僅有一次生成，其他請求等待結果。
影響範圍：延遲、穩定性。
複雜度評級：中

### Root Cause Analysis（根因分析）
直接原因：
1. 快取穿透至昂貴後端。
2. 缺乏單次生成鎖。

深層原因：
- 架構層面：快取策略缺乏抖動與互斥。
- 技術層面：未使用Lazy/鎖機制。
- 流程層面：到期集中效應未壓測。

### Solution Design（解決方案設計）
解決策略：組合MemoryCache + Lazy<Task<T>>或SemaphoreSlim；第一個請求負責生成，其餘await相同Task。

實施步驟：建立GetOrCreateAsync、雙重檢查、清理失敗

關鍵程式碼/設定：
```csharp
private static readonly MemoryCache _cache = MemoryCache.Default;
private static readonly SemaphoreSlim _mutex = new(1, 1);

public async Task<T> GetOrCreateAsync<T>(string key, Func<Task<T>> factory, TimeSpan ttl)
{
    if (_cache.Get(key) is Task<T> cached) return await cached;

    await _mutex.WaitAsync();
    try
    {
        if (_cache.Get(key) is Task<T> again) return await again;

        var task = factory();
        _cache.Set(key, task, new CacheItemPolicy { AbsoluteExpiration = DateTimeOffset.Now.Add(ttl) });

        try { return await task; }
        catch
        {
            _cache.Remove(key); // 失敗時移除以便重試
            throw;
        }
    }
    finally { _mutex.Release(); }
}

## Case #12: 每Session請求序列化，避免併發更新衝突

### Problem Statement（問題陳述）
業務場景：購物車/個人設定因同一使用者同時發多請求而出現狀態競爭。
技術挑戰：在不影響不同使用者的情況下，對同Session序列化處理。
影響範圍：資料一致性、使用者體驗。
複雜度評級：中

### Root Cause Analysis（根因分析）
直接原因：
1. 同一Session的寫操作無同步。
2. Session provider或設計未強制互斥。

深層原因：
- 架構層面：缺失每使用者鎖。
- 技術層面：IHttpModule事件點選擇不當。
- 流程層面：未設計序列化策略。

### Solution Design（解決方案設計）
解決策略：建立IHttpModule或Middleware，按SessionId取得SemaphoreSlim，請求開始Wait、結束Release；讀多寫少可改RWLock。

實施步驟：建立鎖字典、生命週期掛點、清理策略

關鍵程式碼/設定（IIS/傳統ASP.NET示意）：
```csharp
public class SessionSerializeModule : IHttpModule
{
    private static readonly ConcurrentDictionary<string, SemaphoreSlim> Locks = new();

    public void Init(HttpApplication context)
    {
        context.PostAcquireRequestState += async (sender, e) =>
        {
            var app = (HttpApplication)sender;
            string sid = app.Context.Session?.SessionID;
            if (sid == null) return;

            var sem = Locks.GetOrAdd(sid, _ => new SemaphoreSlim(1, 1));
            await sem.WaitAsync();

            app.EndRequest += (s2, e2) =>
            {
                sem.Release();
            };
        };
    }

    public void Dispose() { }
}

## Case #13: 多實例環境下的單例任務：SQL 分散式鎖（sp_getapplock）

### Problem Statement（問題陳述）
業務場景：Web Farm多實例同時啟動排程，造成重複發信/重複結算。
技術挑戰：需確保同一時間只有一個節點執行特定任務。
影響範圍：資源浪費、重複計費/通知。
複雜度評級：中

### Root Cause Analysis（根因分析）
直接原因：
1. 缺乏跨節點鎖。
2. 以本機鎖誤判為獨占。

深層原因：
- 架構層面：多實例協調缺失。
- 技術層面：未使用分散式鎖。
- 流程層面：部署拓撲變更未同步設計。

### Solution Design（解決方案設計）
解決策略：使用SQL Server sp_getapplock or Redis分散式鎖，取得鎖才執行；失敗則跳過或延後。

實施步驟：封裝鎖Helper、在任務入口嘗試取得、處理失敗策略

關鍵程式碼/設定（SQL applock）：
```csharp
public async Task<bool> TryAcquireLockAsync(SqlConnection conn, string name, TimeSpan timeout)
{
    using var cmd = new SqlCommand("sp_getapplock", conn) { CommandType = CommandType.StoredProcedure };
    cmd.Parameters.AddWithValue("@Resource", name);
    cmd.Parameters.AddWithValue("@LockMode", "Exclusive");
    cmd.Parameters.AddWithValue("@LockOwner", "Session");
    cmd.Parameters.AddWithValue("@LockTimeout", (int)timeout.TotalMilliseconds);
    var ret = await cmd.ExecuteScalarAsync();
    // 返回值>=0即成功
    return Convert.ToInt32(ret) >= 0;
}

## Case #14: 具備取消與優雅關閉的多工作流程

### Problem Statement（問題陳述）
業務場景：服務關閉或熱部署時，正在執行的ThreadPool工作需可取消並釋放資源，避免資料損壞。
技術挑戰：將CancellationToken貫穿各層，正確處理OperationCanceledException。
影響範圍：資料一致性、可維運性。
複雜度評級：中

### Root Cause Analysis（根因分析）
直接原因：
1. 未傳遞取消Token。
2. 結束條件與資源釋放缺失。

深層原因：
- 架構層面：未設計關閉協定。
- 技術層面：對取消例外處理不熟。
- 流程層面：無關閉演練。

### Solution Design（解決方案設計）
解決策略：建立集中CancellationTokenSource，注入到各工作；使用GetConsumingEnumerable(ct)天然支持取消；在finally釋放資源。

實施步驟：建立cts、注入與監聽、測試關閉

關鍵程式碼/設定：
```csharp
var cts = new CancellationTokenSource();
// 註冊主機關閉
life.ApplicationStopping.Register(() => cts.Cancel());

ThreadPool.QueueUserWorkItem(_ =>
{
    try
    {
        while (!cts.Token.IsCancellationRequested)
        {
            DoUnitOfWork(cts.Token);
        }
    }
    catch (OperationCanceledException) { /* 正常取消 */ }
    finally { Cleanup(); }
});

## Case #15: 建立可重現的效能基準與指標儀表板

### Problem Statement（問題陳述）
業務場景：並行化後缺乏一致的度量，無法驗證優化是否有效。
技術挑戰：建立可重現的Benchmark、收集CPU/吞吐/延遲指標。
影響範圍：決策品質、優化效率。
複雜度評級：低-中

### Root Cause Analysis（根因分析）
直接原因：
1. 無基準測試。
2. 指標零散或缺失。

深層原因：
- 架構層面：未納入性能守門流程。
- 技術層面：不熟dotnet-counters/Stopwatch。
- 流程層面：無回歸檢查。

### Solution Design（解決方案設計）
解決策略：建立簡單基準驅動程式，記錄平均/中位/P95，使用dotnet-counters觀察ThreadPool與CPU，形成儀表板。

實施步驟：撰寫基準程式、收集與解析指標、版本比對

關鍵程式碼/設定：
```csharp
var sw = Stopwatch.StartNew();
int ops = 0;
Parallel.For(0, 1_000_000, i => Interlocked.Increment(ref ops));
sw.Stop();
Console.WriteLine($"Ops: {ops}, Elapsed: {sw.ElapsedMilliseconds} ms");
// dotnet-counters monitor System.Runtime --process-id <pid>