Phase 05 — Concurrency（Day 41–50）

What：Concurrency（並發）是「同時處理多件事的結構」，指程式設計上具備可以交錯執行多個任務的能力，不代表這些任務真的在同一個時間點同時執行。Parallelism（平行）是「同時執行多件事的物理事實」，指多個任務確實在同一個時間點，分別在不同的實體運算單元（CPU core）上跑。單核 CPU 上的作業系統透過時間切片快速切換多個 Process/Thread 執行，這是 Concurrency（結構上交錯處理），但同一時刻只有一個任務真的在執行，不是 Parallelism。

Failure Modes：常見誤解是看到程式裡用了很多 Goroutine，就以為「這是平行運算，一定比較快」——如果任務是 CPU-bound 且 GOMAXPROCS被限制在 1（例如某些容器環境誤設資源限制），大量 Goroutine 只會增加排程開銷，實際吞吐量可能不升反降。另一個誤解是把「多執行緒程式」直接當作「自動安全地變快」，忽略了 Concurrency 結構一旦牽涉共享記憶體，就會引入 Day 44 才要學的 race condition 風險——Concurrency 帶來的是「結構上可以交錯」，不是「自動保證正確」。

Backend Applications：一個 Go web server 用 goroutine-per-request 模型（每個進來的 HTTP request 由一個新 Goroutine 處理）就是典型的 Concurrency 設計：多數 backend 工作是 I/O-bound（等資料庫、等下游 API、等磁碟），Goroutine 讓 server 可以在等待某個 request 的 I/O 時，切去處理另一個 request，大幅提高單機能同時服務的 request 數；而像圖片轉檔、批次資料運算這類 CPU-bound 工作，才需要認真考慮GOMAXPROCS 與實體核心數，思考的是 Parallelism 而不只是 Concurrency。

陌生題示範：情境——一台 4 核心的機器，GOMAXPROCS=4。程式 A 開 100 個 Goroutine，每個 Goroutine 只做「呼叫下游 API 並等待 200ms 回應」；程式 B 開 100 個 Goroutine，每個 Goroutine 做「對一個陣列做 100 萬次浮點數乘法」（純 CPU 運算，不等待任何 I/O）。請推導這兩個程式的總耗時分別大約是什麼量級，以及各自受什麼因素限制。推導：程式 A 是 I/O-bound，100 個 Goroutine 的等待期間彼此不佔用 CPU，Go runtime 可以讓它們的等待互相重疊，只要 4 顆核心加上 runtime 排程能撐住 100 個 Goroutine 在等待結束的瞬間各自被喚醒處理少量後續邏輯，總耗時會接近單一個 request 的等待時間（約 200ms 量級），不會是 100 × 200ms；程式 B 是 CPU-bound，100 個 Goroutine 的運算工作總量固定，只有 4 顆核心能真正同時執行，等於 100 份工作要排隊分配到 4 條執行序上，總耗時大約是「單一 Goroutine 運算時間 × 100 ÷ 4」，是實體核心數（Parallelism 的物理上限）在決定總時間，而不是 Goroutine 開得多不多。這個對照說明「Goroutine 數量」跟「實際變快的量級」中間，隔著一層「這個任務是 I/O-bound 還是 CPU-bound」的判斷。

What：Process 是作業系統分配資源（獨立的虛擬位址空間、檔案描述符表、至少一個執行緒）的基本單位。每個 Process 有自己獨立的記憶體空間——Process A 沒辦法直接讀寫 Process B 的變數，兩者的記憶體位置編號（虛擬位址）即使數字相同，也對應到硬體上完全不同的實體記憶體。

Failure Modes：常見誤解是以為「兩個 Process 執行同一份程式碼，就會共用同一份全域變數」——實際上即使是同一份可執行檔啟動的兩個 Process 實例，各自的全域變數也是分開的兩份記憶體，互不影響（例如同時開兩個瀏覽器分頁對應的獨立 renderer process，各自的 JS 全域變數不會互相看到對方）。

Backend Applications：常見的部署模式（例如用 systemd 或 Kubernetes 啟動多個相同服務的 Process/container）依賴的正是 Process 隔離——即使其中一個 instance 因為記憶體洩漏或 panic 崩潰，作業系統保證這不會直接破壞同機器上其他 Process 的記憶體，只要重啟這一個 Process 即可，這是水平擴展與容錯設計的物理前提。

What：Thread 是 Process 內部的執行單位——一個 Process 至少有一個 Thread（Main Thread），也可以建立多個 Thread。同一個 Process 底下的所有 Thread 共享同一份記憶體位址空間（同一份全域變數、heap 上配置的物件都能互相讀寫），但每個 Thread 有自己獨立的 Stack（存放函式呼叫的區域變數、返回位址）與程式計數器（記錄目前執行到哪一行指令）。

Failure Modes：常見誤解是把「Thread 比較輕量」跟「可以無限開很多個」畫上等號——每個 OS Thread 仍然要吃掉獨立的 Stack 記憶體（即使幾百 KB，開幾萬個也會累積到 GB 等級），且 OS kernel 排程大量 Thread 的 context switch 開銷會隨數量上升，這正是接下來要學的「為什麼需要 Goroutine 這種更輕量的替代方案」的動機來源。

Backend Applications：傳統（非 Go）的 thread-per-connection 伺服器模型（例如早期 Java/C 的多執行緒伺服器）就是直接用 OS Thread 服務每個連線——同時服務數千個連線意味著要維持數千個 OS Thread，Stack 記憶體與 context switch 開銷成為擴展的主要瓶頸，這正是 Goroutine 這類使用者層級輕量執行單位被設計出來的背景。

What：Goroutine 是 Go runtime（不是 OS kernel）自己管理的執行單位，比 OS Thread 輕量很多——初始 Stack 只有 2KB（依需要動態成長/收縮，不像 OS Thread 通常一開始就配置固定的幾百 KB 到幾 MB），而且 Goroutine 的建立、銷毀、切換都發生在使用者空間，不需要每次都陷入 kernel（進行系統呼叫），成本遠低於 OS Thread。

Failure Modes：常見誤解是以為「Goroutine 是完全免費的」——雖然比 Thread 輕量很多，但每個 Goroutine 仍然佔用真實記憶體（Stack）與排程開銷；在一個處理大量短生命週期任務的迴圈裡，不加控制地為每個任務開一個 Goroutine（沒有 worker pool 限制併發數），仍可能在極端資料量下累積出可觀的記憶體與排程壓力，這是 T-028 Patterns（Worker Pool）要解決的問題。

Backend Applications：Go 標準函式庫的 net/http 伺服器預設就是「每個進來的 request 由一個新 Goroutine 處理」——這正是善用 Goroutine 低成本的直接體現：一個能同時處理數千個並發連線的 Go 伺服器，背後可能只用了個位數到十位數的 OS Thread（由 runtime 排程器自動管理），不需要開發者手動管理 Thread Pool。

陌生題示範：情境——用 go test -bench 分別 benchmark「建立 10,000 個 OS Thread（各自執行空函式後結束）」與「建立 10,000 個 Goroutine（各自執行同一個空函式後結束，用 sync.WaitGroup 等待）」兩種寫法，你會預期兩者的總耗時與記憶體佔用差距落在什麼量級？推導：OS Thread 建立牽涉系統呼叫（陷入 kernel）、配置較大的 Stack（虛擬位址空間常見達 MB 級，雖然不會立即全部佔用實體記憶體，但仍佔用位址空間與部分實際使用的分頁），10,000 個大約會在秒級甚至更久、虛擬位址空間佔用達 GB 級；Goroutine 建立在使用者空間完成，不陷入 kernel，初始 Stack 只有 2KB，10,000 個 Goroutine 的建立與排程通常在幾十毫秒內完成、實體記憶體佔用在數十 MB 量級。這個實測差距（通常是 1–2 個數量級以上的時間差、記憶體佔用差距更大）正是 Go 語言在高並發 backend 場景被廣泛採用的核心原因之一。

What：OS Scheduler 是作業系統核心裡負責決定「下一個時間片段，CPU 要執行哪一個 Thread」的元件。現代作業系統普遍採用 Preemptive Scheduling（搶佔式排程）：Scheduler 可以在一個 Thread 還沒主動讓出 CPU 的情況下，強制中斷它、把 CPU 讓給另一個 Thread（通常依賴硬體計時器定期觸發中斷），確保沒有任何一個 Thread 能無限期霸占 CPU。

Failure Modes：一個常見的失效場景是 blocking system call 拖累整個 OS Thread——如果一個 Thread 呼叫了一個 blocking I/O（例如同步讀取一個很慢的檔案/網路連線），這個 Thread 在等待期間會被 Scheduler 標記為阻塞狀態，讓出 CPU 給別的 ready Thread；但如果程式設計是「一個 Thread 對應處理一個任務」（thread-per-task 模型），這個被阻塞的 Thread 在等待結束前完全無法處理任何其他任務——如果同時有數千個任務都各自卡在慢速 I/O 上，就需要數千個 Thread 才能讓其他任務不受影響，這正是 Day 42 Thread 建立成本問題的根源，也是 Goroutine 排程模型要解決的核心痛點。

Backend Applications：診斷「CPU 使用率不高，但系統吞吐量卻上不去」這類問題時，Context Switch 次數是常被忽略的觀察指標（Linux 上可用 vmstat 或 pidstat -w 觀察）——如果 Context Switch 次數異常高，代表系統裡有遠超過核心數的可執行單位在互搶 CPU，即使每個單位做的事都不多，切換開銷本身就可能是瓶頸，這時解法通常不是「加更多 Thread」，而是限制併發數量（例如用 Worker Pool，T-028 展開）。

陌生題示範：情境——一台 8 核心的機器，跑一個 thread-per-connection 的伺服器，目前同時有 5,000 個連線、也就是 5,000 個 OS Thread 都處於 ready 狀態等著被排到 CPU 上執行一小段運算。請推導：把連線數從 5,000 降到 500（例如透過連線池限制併發數），對整體吞吐量的影響會是什麼方向，並說出理論根據。推導：8 顆核心同一時刻最多只能真正執行 8 個 Thread，其餘 Thread 不論是 5,000 個還是 500 個，都要排隊等待 Scheduler 分配 CPU 時間片——但 Thread 數量越多，Scheduler 需要維護的 ready 清單越大、每次決定「下一個換誰」的排程開銷也越高，且每次切換都要付出前面 Mechanism 段落描述的固定成本（存/取暫存器等）；當 Thread 數量從 5,000 降到 500，雖然仍遠超過 8 顆核心，但 Scheduler 需要處理的排程決策複雜度會下降，理論上能把更高比例的 CPU 時間花在「執行真正的工作」而不是「決定接下來執行誰」，整體吞吐量預期會提升——這正是為什麼即使 CPU 核心數不變，限制併發數量（例如用連線池、Worker Pool，T-028 展開）本身就能改善吞吐量，而不是直觀以為「連線數變少＝能同時服務的客戶變少＝更差」。

What：Go runtime 內建一個使用者層級的排程器，把數量可能遠超過 CPU 核心數的 Goroutine（M 個），排程到數量有限、通常對應 CPU 核心數的 OS Thread（N 個）上執行——這稱為 M:N 排程模型，相對於「一個任務對應一個 OS Thread」的 1:1 模型。（Go 排程器內部如何用 G/M/P 三種結構具體實作這個排程、Goroutine 之間如何被搬移，屬於 T-028「Go 排程深入」的範圍，今天只建立「為什麼需要 M:N、它解決了 Topic 1 的什麼問題」這個概念層級的理解。）

Mechanism（概念層級）：當一個 Goroutine 執行到會阻塞的操作（例如等待 Channel、等待網路 I/O），Go runtime 的排程器會偵測到這個 Goroutine 目前無法繼續執行，把它移出目前佔用的 OS Thread，換上另一個 ready 的 Goroutine 繼續用這個 OS Thread 執行——原本卡住的 Goroutine 不會浪費掉整個 OS Thread（不像 Topic 1 的 thread-per-task 模型），OS Thread 本身可以持續保持忙碌、服務其他 Goroutine。對於真正的 blocking system call（Go runtime 無法用非阻塞方式接管的少數情況），runtime 有機制偵測到某個 OS Thread 被卡住太久，額外啟用一個新的 OS Thread 頂替，讓其他 Goroutine 不被這一個卡住的系統呼叫拖累——這保證了即使某個 Goroutine 卡在系統呼叫，其他 Goroutine 仍能被排到別的 OS Thread 繼續跑。

Failure Modes：一個常見誤解是以為「Goroutine 排程完全免除了 Context Switch 成本」——使用者層級的 Goroutine 切換確實比 OS 層級便宜很多，但不是零成本，仍然涉及保存/還原少量狀態；如果程式建立了數百萬個同時等待、彼此又互相依賴喚醒的 Goroutine，排程器需要管理的資料結構規模上升，排程本身的開銷仍會累積成可觀測的成本，「Goroutine 很輕量」不等於「無限多個 Goroutine 沒有代價」。

Backend Applications：Go 程式可以用 runtime.GOMAXPROCS(n)設定同時能真正並行執行 Goroutine 的 OS Thread（對應 CPU 核心）數量上限——這個設定值決定的是 Parallelism 的物理上限，跟你開了多少個 Goroutine（Concurrency 的結構）是兩件獨立的事；診斷 Go 服務效能問題時，GOMAXPROCS 設定是否符合容器實際可用的 CPU 核心數（容器化環境常見的坑：容器限制了 CPU quota，但 Go runtime 預設抓的是宿主機的核心數）是常被忽略、卻直接影響 Parallelism 上限的設定。

陌生題示範：情境——一個 Go 服務同時處理 5,000 個並發連線，其中一個連線觸發了一段呼叫 cgo（呼叫 C 函式庫）的邏輯，這段 C 函式庫內部執行一次會阻塞 3 秒的同步系統呼叫，且 Go runtime 沒有辦法用非阻塞方式接管這類 cgo 呼叫。請推導這 3 秒內，其他 4,999 個連線的 Goroutine 是否會被拖累、為什麼。推導：依今天 Mechanism 段落，Go runtime 偵測到某個 OS Thread 被這個 cgo 呼叫卡住超過門檻時，會額外啟用一個新的 OS Thread，讓排程器可以把其他 ready 的 Goroutine 搬到新的 OS Thread 上繼續執行，因此其他 4,999 個連線的 Goroutine理論上不會因為這一個卡住 3 秒的 cgo 呼叫而整體停擺——但代價是短時間內 OS Thread 數量會多出至少 1 個（額外開的那個），如果同時有大量這類 blocking cgo 呼叫同時發生，OS Thread 數量可能會不受控制地上升，重新引入 Topic 1 描述的 Thread 建立/Context Switch 成本問題，這是為什麼「盡量避免在 Goroutine 裡呼叫會長時間阻塞的 cgo/系統呼叫」是 Go 服務效能調校中常見的建議。

What：Race Condition（競爭條件）是指兩個以上的執行單位（Thread/Goroutine）同時存取同一塊共享記憶體，且至少一個是寫入操作，而最終結果依賴於這些存取實際發生的時間順序——如果程式的正確性會因為執行順序不同而變出不同結果，就代表這段程式存在 race condition。

Trade-off / Failure Modes：Race condition 的可怕之處在於它不保證每次都出錯——上面的交錯情境需要排程器剛好在特定時間點切換，在 Goroutine 數量少、運算量小的情況下可能很少發生，讓開發者誤以為程式沒問題，卻在高併發、高負載的生產環境下才大量出現不一致的結果，這正是 race condition 難以用一般測試流程抓到的原因。Go 工具鏈內建-race flag（go run -race main.go、go test -race），會在執行期間插入額外的偵測邏輯，追蹤每一次記憶體存取是否可能與其他 Goroutine 的存取產生未同步的交錯，一旦偵測到就會印出明確的 race 報告（包含發生 race 的程式碼行號與涉及的 Goroutine），是排查/預防 race condition 最直接有效的工具，應該養成在測試流程中固定加上-race 的習慣。

Backend Applications：一個常見的生產事故模式是「多個 request 的 Goroutine 同時對記憶體內的計數器（例如簡易版的 rate limiter 計數、暫存的統計數字）做遞增，沒有加鎖，導致計數不準確」——這正是本 Phase 驗收目標（concurrency-safe rate limiter）要解決的核心問題：一個 rate limiter 如果內部計數器有 race，會讓限流失準（可能允許超過設定上限的請求通過，或反過來誤擋合法請求）。

陌生題示範：情境——一段程式碼開 1,000 個 Goroutine，每個都對同一個全域整數變數執行一次遞增，主 Goroutine 用 sync.WaitGroup等待全部完成後印出這個變數的值。請推導這個程式執行多次，印出的值是否每次都是 1,000，並指出 shared state、race 發生的位置、critical section 分別是什麼。推導：這個全域變數是被 1,000 個 Goroutine 共同讀寫的 shared state；race 發生在任兩個 Goroutine 的遞增操作被排程器交錯執行、其中一個的寫回覆蓋了另一個尚未寫回的中間結果時；critical section 是「讀取 → 加一 → 寫回」這三步驟合起來的區間。由於排程順序在每次執行時可能不同，這個程式印出的最終值不保證每次都是 1,000，通常會是一個小於等於 1,000、且每次執行可能不同的數字（遺失的次數取決於實際發生交錯的頻率，機器負載、GOMAXPROCS 設定都會影響），這正是 Day 42 結尾預告的答案：全域變數版本的 100,000 個 Goroutine 遞增練習，最終值幾乎必然小於 100,000。

What：Mutex（Mutual Exclusion，互斥鎖）是一種同步機制，保證同一時間最多只有一個 Goroutine 能夠進入被它保護的 Critical Section；其他想進入的 Goroutine 會被阻塞（blocked），排隊等待目前持有鎖的 Goroutine 釋放鎖之後，才能有一個等待中的 Goroutine 被喚醒、取得鎖繼續執行。Go 的 sync.Mutex 提供 Lock() 與Unlock() 兩個方法。

Failure Modes：最常見的錯誤是 Lock() 之後某個路徑（例如提早return 或 panic）忘記呼叫對應的 Unlock()，導致這個鎖永遠不會被釋放，後續任何想取得這個鎖的 Goroutine 都會永久阻塞——Go 的慣用寫法是 mu.Lock() 後緊接著 defer mu.Unlock()，用 defer 保證不管函式從哪個路徑返回都一定會執行 Unlock()。另一個常見錯誤是「鎖的粒度不一致」——例如兩個不同函式都存取同一個共享變數，卻只有其中一個函式有 Lock() 保護，另一個直接讀寫，Mutex 的保護是針對「所有存取路徑都要一致地上鎖」才有效，漏掉任何一個路徑，race 依然存在。

Backend Applications：一個記憶體內的 rate limiter（例如固定視窗計數器）如果要在多個 Goroutine 同時處理的請求之間共享同一份計數狀態，計數的遞增與判斷是否超過門檻這段邏輯，必須用 Mutex（或接下來要學的 Atomic）保護，否則在高併發下會像 Topic 1 陌生題一樣遺失遞增次數，讓限流的門檻形同虛設。

陌生題示範：情境——把 Topic 1 陌生題的 1,000 個 Goroutine 遞增練習，改成用 sync.Mutex 保護（mu.Lock() → 遞增 → mu.Unlock()），但其中不小心漏寫了一個地方：主 Goroutine 在所有子 Goroutine 都Wait() 完之後，沒有加鎖就直接讀取並印出這個變數的值。請推導：這個「讀取」動作本身有沒有 race 風險，並說明為什麼。推導：雖然所有會寫入這個變數的 1,000 個 Goroutine 都已經透過 sync.WaitGroup確認執行完畢（意味著它們的寫入與 Unlock() 都已經發生，不會再有新的寫入），此時主 Goroutine 的讀取確實不會跟任何「正在進行中」的寫入交錯——但這個安全性是建立在「WaitGroup.Wait() 保證所有寫入者都已經完成」這個額外的同步保證之上，而不是 Mutex 本身給的保證；如果今天的情境改成「還有背景 Goroutine 持續在遞增、主 Goroutine 隨時可能穿插著讀取」，同一個不加鎖的讀取就會直接構成 race（讀取也是一種記憶體存取，Mutex 的保護必須涵蓋所有存取路徑，包含只讀的路徑，見本節 Failure Modes）。這說明「目前這次沒事」不等於「這個寫法安全」——安全性取決於是否有其他機制（例如 WaitGroup）保證了讀寫不會交錯，不能只看單次執行結果反推程式碼正確。

What：sync.RWMutex 是 Mutex 的一種變形，區分兩種鎖：Lock()/Unlock()（寫鎖，Write Lock）維持跟一般 Mutex 一樣「同一時間最多一個 Goroutine」的互斥語意；RLock()/RUnlock()（讀鎖，Read Lock）允許多個 Goroutine 同時持有讀鎖並行讀取，只要沒有任何 Goroutine 持有寫鎖。當有 Goroutine 持有寫鎖時，任何想取得讀鎖或寫鎖的 Goroutine 都要等待。

Failure Modes：常見誤解是以為 RWMutex 能讓「讀取者」跟「寫入者」同時進行——實際上寫鎖依然是完全互斥的，只要有一個 Goroutine 持有寫鎖，包含讀鎖在內的所有其他請求都要等待；另一個常見問題是「寫鎖飢餓」（write starvation）——如果讀取請求非常頻繁、幾乎不間斷，等待寫鎖的 Goroutine 可能長時間排不到機會（Go 的 sync.RWMutex會在有寫鎖等待時，阻止新的讀鎖繼續插隊，緩解但不完全消除這個問題）。

What：sync/atomic 套件提供一組原子操作（例如atomic.AddInt64、atomic.LoadInt64、atomic.CompareAndSwapInt64），直接由 CPU 硬體層級保證「讀取-修改-寫回」這類操作作為單一、不可被其他執行單位插入的整體完成，不需要像 Mutex 一樣透過「阻塞其他 Goroutine」來達成互斥。

Failure Modes：常見誤解是把 Atomic 當成萬用的無鎖方案，試圖用多個獨立的 Atomic 操作拼湊出一個本質上需要整體一致性的複合邏輯（例如分別對兩個 Atomic 變數做更新，期待兩者看起來像是同時發生）——每個 Atomic 操作本身是原子的，但兩個獨立的 Atomic 操作之間仍然可能被其他 Goroutine 插入執行，整體上不構成一個大的 Critical Section，這種情況必須用 Mutex 把兩個變數的更新包在同一個鎖之內，才能保證一致性。

Backend Applications：Rate Limiter 內部的請求計數器、簡單的請求數/錯誤數統計指標（metrics），是 Atomic 最典型的應用場景——只需要保護單一數值的遞增/讀取，用 Atomic 比 Mutex 更輕量，是本 Phase 驗收目標（concurrency-safe rate limiter）實作時的自然選擇之一。

What：Channel 是 Go 語言內建的型別化管道，讓一個 Goroutine 可以透過 ch <- value 把值送進 Channel，另一個 Goroutine 透過value := <-ch 把值取出來——本質上是一個由 Go runtime 內部保護（自帶同步機制，使用者不需要另外加 Mutex）的執行緒安全佇列。Channel 分兩種：Unbuffered Channel（make(chan T)，容量為 0）與 Buffered Channel（make(chan T, n)，容量為 n）。

Mechanism（阻塞語意）：Unbuffered Channel 的發送（ch <-value）會阻塞，直到剛好有另一個 Goroutine 執行對應的接收（<-ch）——兩邊必須配對同時就緒，這個配對發生的瞬間，Go runtime 保證發送方在這之前寫入的所有記憶體操作，對接收方在這之後執行的程式碼都可見（這個「傳遞即同步點」的保證稱為 happens-before 關係，是 Channel 能取代 Mutex 的底層原因：傳遞本身就隱含了一次同步）。Buffered Channel（容量 n）的發送只有在緩衝區已滿（已經有 n 個值還沒被取走）時才會阻塞；接收只有在緩衝區為空時才會阻塞——緩衝區未滿/非空時，發送/接收可以立即完成，不需要另一端剛好同時就緒。

Failure Modes（Deadlock 預告）：如果對一個 Unbuffered Channel 執行 ch <- value，但整個程式裡沒有任何其他 Goroutine 會執行對應的 <-ch，這次發送會永遠阻塞下去；如果這是主 Goroutine（main 函式）唯一在做的事，且沒有其他 Goroutine 能繼續推進程式狀態，Go runtime 會偵測到所有 Goroutine 都處於等待狀態、沒有任何一個能被喚醒，直接讓程式以 fatal error: all goroutines are asleep - deadlock! 崩潰——這是本 Phase 對 Deadlock 概念的第一次具體示範（完整的 Deadlock 成因分類、如何預防，留給 T-028 Day 46 系統性展開，今天只示範這一種最簡單、最常見的成因：Channel 的發送/接收沒有配對到）。

Backend Applications：Worker Pool 模式（T-028 Patterns 會系統展開）的核心就是用一個 Channel 當作任務佇列——多個「生產者」Goroutine 把任務送進 Channel，固定數量的「worker」Goroutine 從同一個 Channel 取出任務執行；Channel 的緩衝容量與 worker 數量的搭配，直接決定了這個系統在任務量暴增時是「讓任務排隊等待」還是「阻塞上游生產速度」，是設計高吞吐 backend pipeline 時的核心考量。

陌生題示範：情境——一個 unbuffered channel，主 Goroutine 依序執行兩次發送（ch <- 1 接著 ch <- 2），且完全沒有啟動任何其他 Goroutine 去接收。請推導這段程式的執行結果，並指出這符合今天七問裡的哪一項。推導：第一次發送執行時，因為是 unbuffered channel，需要另一個 Goroutine 同時執行接收才能完成配對——但程式裡沒有任何其他 Goroutine 存在（也沒有人會去接收），這次發送會永遠阻塞；主 Goroutine 是程式裡唯一的執行單位，一旦它永久阻塞，Go runtime 偵測到沒有任何 Goroutine 處於可繼續執行的狀態，會直接觸發fatal error: all goroutines are asleep - deadlock! 並終止程式——連第二次發送都不會被執行到。這對應七問裡的 Can it deadlock?：答案是會，而且不需要兩個互相競爭的鎖就能發生——只要有一端的 Channel 操作永遠等不到配對的另一端，就是最簡單的一種 deadlock。

練習（收斂本週練習，為 T-028 的完整 rate limiter 驗收鋪路）：實作一個簡化版的並發安全計數式 rate limiter 雛型——用一個 buffered channel（容量等於允許的請求上限）模擬固定數量的 token，每次請求先嘗試從 channel 取一個 token（用 select 搭配 default 分支做非阻塞嘗試）才允許通過，否則視為被限流拒絕；額外開一個背景 Goroutine，每隔固定時間把 token 補回 channel（模擬時間視窗重置）。用至少 50 個併發 Goroutine 模擬請求，記錄通過與被拒絕的請求數，並用 go run -race 確認沒有 race。（完整、正式的 rate limiter 實作與四個驗收問題回答，屬於 Phase 05 整體驗收，由 T-028 Day 50 收尾時完成；今天的雛型是建立 Channel 作為同步工具的直接應用經驗。）

What：Deadlock（死結）是兩個（或以上）執行單位各自持有至少一項資源、同時在等待對方持有的另一項資源，形成循環等待，導致沒有任何一方能繼續往下執行。與 Phase 04 Day 40 教過的 transaction 死結是同一個現象在不同資源型態上的重現：那裡是兩個 transaction 交叉鎖兩個帳戶列，這裡是兩個 Goroutine 交叉鎖兩個 sync.Mutex。

Failure Modes：Go runtime 的死結偵測只在「整個程式裡所有 Goroutine 都不可能再被喚醒」時才會觸發 fatal error；如果程式裡還有其他 Goroutine 仍在正常運行（例如一個背景心跳 Goroutine），即使兩個 Goroutine 彼此死結，runtime 不會偵測到、也不會報錯，程式只會看起來「部分功能卡住但整體沒崩潰」，比直接 fatal error 更難排查——這是許多線上死結問題排查困難的根本原因，通常需要靠kill -QUIT（dump 所有 Goroutine 堆疊）或 go tool pprof 的 goroutine profile 人工比對哪些 Goroutine 卡在 Lock() 上。

Backend Applications：Phase 04 Day 40 的轉帳死結案例——兩個 transaction 交叉鎖兩個帳戶列形成的死結，跟今天兩個 Goroutine 交叉鎖兩個 mutex 是同一個 Circular Wait 現象，只是資源換成 DB row lock；Day 40 當時給的修法（統一先鎖 id 較小的帳戶）與今天的修法（統一鎖的取得順序）是同一個原則的兩次應用。在 backend 系統裡，需要同時持有多個內部鎖的場景（例如一個連線池同時管理多個資源池）必須建立並遵守全域一致的鎖排序規則，否則規模變大後幾乎必然會在某個新加的路徑上意外形成 circular wait。

陌生題示範：情境——一個簡化版的「三個哲學家用餐」：3 個 Goroutine（P0/P1/P2）圍成一圈，每個都需要同時拿到左右兩支叉子（用 3 個 *sync.Mutex 表示，fork[i] 與 fork[(i+1)%3]）才能「吃飯」，每個 Pi 都先 Lock(fork[i]) 再 Lock(fork[(i+1)%3])。請推導這個設計是否會 Deadlock，並給出修正。推導：P0 先鎖fork[0] 再要 fork[1]；P1 先鎖 fork[1] 再要 fork[2]；P2 先鎖fork[2] 再要 fork[0]——若三者幾乎同時各自成功鎖住自己的第一支叉子，P0 等 P1 放 fork[1]、P1 等 P2 放 fork[2]、P2 等 P0 放fork[0]，形成三方循環等待，四個 Coffman 條件全部成立，會 Deadlock。修正：比照 Day 40 與本節 Mechanism 段落的作法，打破 Circular Wait——讓其中一個（例如編號最大的 P2）反過來先鎖fork[(i+1)%3] 再鎖 fork[i]，即 P2 變成先鎖 fork[0] 再鎖fork[2]；這樣 P2 會先跟 P0 競爭 fork[0]，不會出現「所有人都先鎖自己那一支、再等下一個人放手」的對稱結構，循環等待的條件被打破，其中一方會先贏得 fork[0] 並順利吃到飯。

What：Livelock 是執行單位彼此都沒有被阻塞（仍在持續執行、消耗 CPU），但因為彼此的行為持續互相干擾，導致誰都無法真正完成工作、系統整體沒有任何進展——與 Deadlock 的差別在於：Deadlock 是「卡住不動」，Livelock 是「一直在動但原地打轉」。

Failure Modes：Livelock 比 Deadlock 更難被發現，因為 CPU 使用率、Goroutine 數量、log 都顯示「系統在動」，容易被誤判成「只是比較慢」而非真正卡死；診斷時的關鍵信號是「重試次數/失敗次數持續飆升，但成功次數長期不動」，而不是單純看 CPU 或 Goroutine 數量。

Backend Applications：分散式系統裡常見的 Livelock 變體是「兩個節點互相謙讓導致誰都不當 leader」（例如兩邊都主動退出 leader 選舉以避免衝突，退出後發現對方也退出了，又同時重新參選）——這跟今天兩個 Goroutine 互相謙讓釋放鎖是同一種模式在不同規模上的重現，通常靠加入隨機化的重試延遲或明確的優先權規則打破對稱性來解決。

What：Starvation（飢餓）是某個特定執行單位長期（理論上可能永遠）無法取得它需要的資源，即使資源本身並沒有被永久占用、系統整體也在持續運作——重點在「長期偏袒某一方、另一方持續被排擠」，不像 Deadlock/Livelock 是「全部卡住/全部空轉」。

Failure Modes：常見誤判是把「平均延遲正常」當成「沒有 Starvation 的證據」——Starvation 通常只影響一小部分請求（被持續排擠的那些），平均值會被大多數正常請求拉低，必須看 p99/p999 這類尾端分位數或「最長等待時間」才容易發現某些請求被系統性地餓死。

Backend Applications：請求優先權隊列設計不當（例如永遠優先處理「新進」請求）是 backend 系統裡 Starvation 最常見的來源之一——一個大量湧入的高優先權請求流，可能讓低優先權請求永遠排不到，設計時通常需要加入「等待時間加權」（等越久優先權越高，即 aging 機制）來保證有限時間內一定會被服務，這跟 Go Mutex 內建的 starvation mode 是同一個思路的不同實作層級。

What：Go runtime 排程器內部用三種結構具體實作 M:N 排程：G（Goroutine 的縮寫，代表一個 Goroutine 本身，包含它的執行堆疊、程式計數器、狀態等）；M（Machine，代表一個真正的 OS Thread，是唯一能實際執行機器指令的東西）；P（Processor，代表「允許執行 Go 程式碼的排程上下文」，數量由 GOMAXPROCS 決定，每個 P 維護一個本地 Run Queue）。一個 M 必須先「綁定」一個 P 才能從 P 的本地 Run Queue 取出 G 來執行——這個「必須持有 P 才能跑 Go 程式碼」的設計是理解 G/M/P 模型的關鍵：Go 程式碼的並行度上限不是取決於有幾個 M，而是取決於 GOMAXPROCS 設定的 P 的數量。

Failure Modes：如果 GOMAXPROCS 在容器化環境裡被設成宿主機的完整核心數，而容器實際的 CPU quota 遠低於此（常見的 Kubernetes CPU limit 場景），會有遠多於實際可並行執行數量的 P 在競爭實際上更少的 CPU 時間，導致大量 CPU throttling——這是 Day 43 Backend Applications 提過的坑，這裡可以更精確解釋成因：P 的數量本身不受 CPU quota 限制，只有 GOMAXPROCS 這個數字決定要建立幾個 P，如果沒有額外套件（例如 automaxprocs）根據容器實際 CPU quota 調整GOMAXPROCS，就會一直建立過多 P，讓排程器誤以為有更多可用的並行資源。

Backend Applications：診斷 Go 服務的排程問題時，GODEBUG=schedtrace=1000 環境變數可以讓 runtime 每 1 秒印出一次排程器內部統計（包含目前的 G/M/P 數量、每個 P 的 Run Queue 長度），runtime/pprof 的 goroutine profile 可以列出目前所有 G 各自卡在哪一行程式碼——兩者是排查「服務為什麼變慢、是不是 Goroutine 洩漏或排程失衡」最直接的工具，比單純看 CPU 使用率更能定位問題根源。

陌生題示範：情境——一個 Go 服務用 runtime.LockOSThread()把某個 G 永久綁定到它當下正在執行的 M 上（這個 M 不會再被拿去執行其他 G），這個 G 接著執行一段長達 10 秒、不涉及任何系統呼叫的純 CPU 迴圈。請推導：(1) 這 10 秒內，原本這個 M 綁定的 P 會發生什麼事；(2) 其他 Goroutine 是否會被拖累。推導：LockOSThread() 保證這個 G 只能在這個特定 M 上執行，但不影響 P 的可用性——G 執行純 CPU 運算時不會主動讓出，Go 排程器只能在有限的「安全點」（例如函式呼叫邊界、GC 相關的搶占點）才能介入搶占；假設這段純 CPU 迴圈內部完全沒有函式呼叫，在 Go 1.14 之前的協作式排程下這個 G 會一直占用它的 P 直到迴圈結束，P 上原本排隊的其他 G 會被卡住不能執行；但 Go 1.14 引入了非同步搶占（基於訊號，可以在幾乎任意指令邊界強制中斷執行超過 10ms 的 G），所以現代 Go 版本下，即使是純 CPU 死迴圈也會在約 10ms 內被強制搶占，把 P 讓給其他排隊的 G——但注意LockOSThread 綁定的 M 本身仍然專屬這個 G，不會被拿去執行別人：搶占後這個 G 會被暫停、P 會先服務其他 G，等排程器認為公平時才把這個 G 重新排回去繼續跑（繼續綁在同一個 M 上）。

What：context.Context 是 Go 標準函式庫提供的一個介面，用來在一串有父子關係的 Goroutine 之間傳遞「取消信號」、「截止時間」、以及少量的請求範圍資料。最常用的建構方式是 context.WithCancel(parent)（回傳一個可以手動呼叫取消的 cancel 函式）、context.WithTimeout(parent, d)（時間到自動取消）、context.WithDeadline(parent, t)（指定絕對時間點自動取消）——三者都回傳一個衍生自 parent 的新 Context，一旦 parent 被取消，衍生出來的所有子 Context 都會跟著被取消（取消信號沿著樹狀結構往下傳播，不能反向）。

Failure Modes：最常見的 Goroutine 洩漏成因就是「啟動了一個 Goroutine 做長時間工作，卻沒有讓它監聽任何取消信號」——即使外層請求早已經結束、沒有人再關心這個 Goroutine 的結果，它仍然會繼續占用記憶體與排程資源直到自然跑完（如果它在等一個永遠不會有人送值的 channel，甚至會永遠卡住，成為永久洩漏）；另一個常見錯誤是把context.Background()（永不取消的根 Context）到處亂用，取代了原本該往下傳遞的、真正會被取消的請求 Context，導致取消信號在某一層被「斷開」，看起來支援取消實際上完全沒用。

Backend Applications：HTTP Server 框架（例如 net/http）會自動幫每個 http.Request 建立一個 Context，客戶端斷線或 handler 回傳後會自動取消這個 Context——在 handler 內部呼叫下游服務、查詢資料庫時，把 r.Context() 一路往下傳，是讓整條呼叫鏈能對客戶端斷線快速反應、及早釋放資源（不做無意義的運算）最直接的做法。

What：Worker Pool 是「固定數量的 Goroutine（worker）從同一個任務 channel 持續取出任務執行」的結構——生產者只需要把任務丟進 channel，不需要關心由哪個 worker、什麼時候處理，channel 本身（Day 45 教過的「傳遞即所有權轉移」）保證每個任務只會被其中一個 worker 拿走。

Mechanism（簡述，明日展開）：建立一個 chan Task，啟動 N 個 worker Goroutine，每個都執行 for task := range taskCh {process(task) }（Day 45 range channel 語法：channel 被關閉且清空後，range 迴圈自動結束）；生產者把任務送進 taskCh，全部送完後關閉 channel，所有 worker 會在處理完剩餘任務後自然結束。

Backend Applications：資料庫連線池、圖片處理服務的並發上限控制，都是 Worker Pool 的實際應用——資料庫連線數量本身有限（下游資源上限），把「同時執行的查詢數量」用固定數量的 worker 鎖死在連線數以內，是避免打爆下游最直接的做法。

What：在 Day 47 簡述的基礎上，補上「如何收集每個任務的處理結果、如何處理某個任務失敗」這兩個實務上一定會遇到的問題。

Failure Modes：上述「多個 worker 各自 close 同一個結果 channel」的 panic；另一個常見錯誤是任務處理失敗時直接 return 而不把錯誤寫進結果，導致消費端誤以為該任務成功、少了一筆結果又不知道發生了什麼。

Backend Applications：批次處理任務（例如「重新計算 N 個使用者的統計報表」）的常見做法。

What：Fan-out 是把同一個輸入 channel 交給多個 Goroutine 同時讀取、平行處理（「扇出」到多個 worker）；Fan-in 是反過來，把多個 channel 的輸出匯合進同一個 channel（「扇入」成單一資料流）。兩者常常成對出現：先 Fan-out 平行處理，再 Fan-in 把結果收攏。

Failure Modes：Fan-in 合併 Goroutine 如果忘記用 WaitGroup 等所有來源關閉就直接關閉共享輸出 channel，會導致還在傳值的來源 Goroutine 對已關閉的 channel 送值而 panic（send on closed channel）。

Backend Applications：需要同時查詢多個下游服務再合併結果的場景（例如一次讀取使用者的訂單、庫存、推薦三個微服務的資料再組成一個回應）——Fan-out 同時發起三個請求，Fan-in 等三者都回來後合併，比依序呼叫（一個個等）快得多，是 Day 47 Backend Applications 提到「平行發起多個下游呼叫」的具體實作方式。

What：Pipeline 是把一連串處理步驟各自放進一個 Goroutine，前一階段的輸出 channel 當作下一階段的輸入 channel 串接起來，資料像流水線一樣依序流過每個階段——每個階段可以是 1 個或多個（Fan-out）Goroutine。

Failure Modes：如果某個階段忘記在處理完所有輸入後關閉自己的輸出 channel，下一階段的 range 會永遠等待、永遠不會自然結束（也不會立刻 panic，是一種「看起來還在跑、實際上已經不會再有新資料」的隱性卡住，跟 Livelock 的「忙碌」不同，更接近部分 Deadlock：這個階段之後的所有 Goroutine 都在等一個不會來的關閉信號）。

Backend Applications：日誌處理管線（讀取原始 log → 解析 →過濾 → 寫入資料庫）是 Pipeline 的典型應用，每個階段職責單一，方便針對瓶頸階段單獨調整並發數。

What：Semaphore（信號量）是限制「同時能有多少個執行單位在做某件事」的通用機制，用 Go 實作最簡單的方式是一個容量為 N 的 buffered channel：進入受限區域前先送一個值進 channel（若已滿則阻塞等待），離開時再從 channel 取走一個值釋放名額。

Failure Modes：忘記在操作完成後釋放名額（<-sem 漏寫，尤其是在有 error 提前 return 的路徑上忘了釋放）會造成名額持續減少，最終所有 Goroutine 都卡在等待取得名額，且沒有任何名額會再被釋放——這是一種因為忘記清理資源而製造出來的類 Deadlock 情境，用defer func(){ <-sem }() 在拿到名額後立刻註冊可以避免這個問題。

Backend Applications：對有並發限制的第三方 API、或需要限制同時開啟的檔案數/DB 連線數的場景，Semaphore 是最輕量的解法。

Rate Limiting 在整個課程第 2 次出現——Phase 01 Day 9（Reliability 層級）只教了「為什麼需要限流、超過限制要回 429 + Retry-After」的概念層級，沒有涉及任何演算法或並發實作細節；今天要補上那裡刻意留白的部分：單機上如何用 Mutex/Atomic 正確、安全地實作一個真正會被多個 Goroutine 同時呼叫的限流器（多節點共享限流狀態的更深層問題，留給 Phase 07 Day 61–70 的 System Design 再處理¹）。

What：Token Bucket 是最常見的限流演算法——維護一個容量固定（例如 100）的「桶」，桶裡裝著 token，每次請求要通過必須先拿到一個 token（拿不到就拒絕），桶裡的 token 會以固定速率（例如每秒補 10 個）持續補充、補滿就停止（不會超過桶的容量）。這個設計允許短時間的突發流量（只要桶裡還有累積的 token，可以瞬間用掉一大批），同時長期平均速率被補充速率限制住。

Failure Modes：如果補充 token 的背景 Goroutine 因為某種原因（例如 panic 後沒有 recover、或者被外部 cancel 但沒有正確處理）意外停止，桶的 token 會被持續消耗到 0 之後就再也不會恢復，之後所有請求都會被誤判為超過限制——這是 Rate Limiter 實作裡「背景補充機制本身的健康度」必須被監控的原因，通常需要額外的機制偵測這個背景 Goroutine 是否還活著（例如定期心跳）。

Backend Applications：API Gateway、單一服務實例內部對下游資源的自我保護，都會用到這種單機版 Rate Limiter；當服務水平擴展成多個實例時，各自維護獨立的單機限流器會導致「總限流量 = 單機限制 × 實例數」而非預期的全局限制，這正是 Phase 07 會處理的「多節點如何共享同一份限流狀態」的問題（今天先把單機版做對、做安全，是那個更難問題的必要前置）。

陌生題示範：情境——如果把上面 Mechanism 改成先做 if atomic.LoadInt64(&tokens) > 0 { atomic.AddInt64(&tokens, -1);allow() }（先 Load 檢查，檢查通過了才 Add 扣減，兩個操作分開），而不是先 AddInt64(-1)、結果 < 0 才加回去，請推導這段程式碼在高並發下是否仍然正確。推導：Load 與 AddInt64 是兩個各自獨立的原子操作，但兩者之間沒有被包成一個整體的 critical section——1,000 個 Goroutine 同時執行到 Load 時，可能全部都讀到「目前還有 1 個 token」（因為沒有人真的扣減，Load 不會改變狀態），全部都判斷通過檢查、全部都接著執行 AddInt64(-1)，導致 token 數被扣成負值、且遠超過 1 個請求被放行，這正是 Day 44 Atomic Failure Modes 描述的「多個獨立 Atomic 操作拼湊複合邏輯，中間會被其他 Goroutine 插入」的具體重現（Check-Then-Act 的經典 race pattern，跟 Day 44 Topic 1 counter race condition 的本質完全相同，只是這次錯誤地以為用了 Atomic 就天然安全）。正確做法就是 Mechanism 段落描述的「先扣、扣完發現不夠再補回去」（順序反過來），讓扣減這個動作本身就是檢查是否成功的依據，不需要額外的 Load 步驟介入。