本章目標

學完本章後，你將能夠：

1. 用 go 啟動 goroutine
2. 理解 goroutine 和一般函式呼叫的差異
3. 判斷哪些工作適合放進 goroutine
4. 為 goroutine 設計退出條件
5. 避免 goroutine leak

【觀察】go 關鍵字啟動並發工作

go 的核心規則是：在函式呼叫前加上 go，該函式會在新的 goroutine 中執行，呼叫端不會等待它完成。

1func say(message string) {
2    fmt.Println(message)
3}
4
5func main() {
6    go say("background")
7    say("foreground")
8}

這段程式啟動一個背景 goroutine 執行 say("background")，主 goroutine 會繼續執行 say("foreground")。

【判讀】goroutine 需要明確完成保證

goroutine 的生命週期規則是：程式不會因為你啟動了 goroutine 就自動等待它完成。main() 結束時，整個 process 會結束，尚未完成的 goroutine 也會停止。

因此，這段程式可能看不到背景輸出：

1func main() {
2    go fmt.Println("background")
3}

主程式太快結束時，背景 goroutine 可能還沒得到執行機會。

需要等待結果時，應該使用 channel、sync.WaitGroup 或其他同步機制。

【策略】goroutine 適合等待型或獨立型工作

goroutine 使用的核心規則是：只有當工作能和目前流程並發進行，且生命週期可被管理時，才啟動 goroutine。

適合 goroutine 的工作：

等待 I/O 的核心訊號是目前流程會花時間等外部回應，例如讀檔、呼叫 HTTP API、等待資料庫查詢或讀取 socket。這類工作放進 goroutine 後，呼叫端可以繼續處理其他事件，但仍然要用 context 或 channel 管理結果與取消。

背景 worker 的核心訊號是工作來自 queue 或 channel，而且處理時間和 request 生命週期分離。例如使用者送出匯入任務後，server 只先接受任務，後續由 worker 逐筆處理資料。這種 goroutine 通常需要明確的 job channel、錯誤回報與 shutdown 流程。

定時任務的核心訊號是行為按時間觸發，例如每分鐘清理過期 session、同步外部狀態或刷新快取。這類 goroutine 應使用 ticker 搭配 context，讓服務停止時可以一起退出。

多個獨立請求的核心訊號是多個工作彼此沒有順序依賴，例如同時查三個外部 API，最後合併結果。這類 goroutine 的重點是收集結果、限制並發數量，並在其中一個工作失敗時決定是否取消其他工作。

需要先補齊生命週期設計的情境：

• 只是想讓程式「看起來比較快」
• 沒有任何退出條件
• 呼叫端需要結果但沒有同步機制
• 多個 goroutine 會同時修改共享資料但沒有保護

【執行】用 WaitGroup 等待一組工作

sync.WaitGroup 的核心用途是等待一組 goroutine 完成。

 1func main() {
 2    var wg sync.WaitGroup
 3
 4    for i := 0; i < 3; i++ {
 5        wg.Add(1)
 6        go func(id int) {
 7            defer wg.Done()
 8            fmt.Println("worker", id)
 9        }(i)
10    }
11
12    wg.Wait()
13}

這段程式有三個關鍵：

id 作為參數傳入 goroutine，可以避免 loop 變數捕捉造成混淆。

長時間 goroutine 要能停止

長時間 goroutine 的核心規則是：迴圈中必須等待取消訊號或輸入 channel 關閉。

 1func worker(ctx context.Context, jobs <-chan Job) {
 2    for {
 3        select {
 4        case <-ctx.Done():
 5            return
 6        case job, ok := <-jobs:
 7            if !ok {
 8                return
 9            }
10            handle(job)
11        }
12    }
13}

這個 worker 不會無限卡住；上層取消 context 或關閉 jobs channel，它都會退出。

設計檢查

需要結果時要有等待機制

需要結果或完成保證時，goroutine 應搭配 channel 或 WaitGroup。go doWork() 只負責啟動工作，結果收集與完成等待需要另外設計。

錯誤要有回報路徑

goroutine 裡的錯誤需要明確回報路徑。需要錯誤結果時，用 channel 傳回：

1errCh := make(chan error, 1)
2go func() {
3    errCh <- doWork()
4}()
5
6if err := <-errCh; err != nil {
7    return err
8}

長時間工作要有退出條件

長時間 worker 至少要監聽 context 或 channel close。永遠 for {} 會讓 goroutine 生命週期失去 owner，服務停止時也難以清理。

本章目標

學完本章後，你將能夠：

1. 建立與使用 channel
2. 看懂 channel 的方向與資料型別
3. 理解 buffered channel 的 backpressure 意義
4. 分辨 blocking send 與 non-blocking send
5. 用 channel 畫出資料流

【觀察】channel 連接送出端與接收端

channel 的核心規則是：送出端用 <- 把值放入 channel，接收端用 <- 從 channel 取出值。以下範例建立一個傳遞 string 的 channel：

1messages := make(chan string)
2
3go func() {
4    messages <- "hello"
5}()
6
7msg := <-messages
8fmt.Println(msg)

make(chan string) 建立只能傳 string 的 channel。messages <- "hello" 是送出，msg := <-messages 是接收。

【判讀】channel 是同步點，不只是佇列

unbuffered channel 的核心規則是：送出和接收必須同時準備好，資料才會通過。這表示 channel 也是同步點。

1ch := make(chan int)
2
3go func() {
4    ch <- 1 // 等到有人接收才會繼續
5}()
6
7value := <-ch
8fmt.Println(value)

buffered channel 的核心規則是：buffer 未滿時送出不會阻塞，buffer 滿時送出會阻塞。

1jobs := make(chan Job, 10)
2jobs <- Job{ID: "1"}

buffer 大小不是隨便的數字。它代表系統允許累積多少尚未處理的工作；接收端處理速度跟不上時，buffer 會逐漸填滿，最後形成 backpressure 。

【策略】用方向限制表達所有權

channel direction 的核心規則是：函式簽名應限制自己只需要的能力。Go 可以用 channel direction 表達函式只讀或只寫：

1func producer(out chan<- Job) {
2    out <- Job{ID: "1"}
3}
4
5func consumer(in <-chan Job) {
6    job := <-in
7    handle(job)
8}

chan<- Job 表示只能送出，<-chan Job 表示只能接收。這是 API 層的保護：producer 不能讀取 channel，consumer 不能寫入 channel。

【執行】non-blocking send 的取捨

non-blocking send 的核心規則是：送不出去時立即走 fallback，不等待接收端。它適合「寧可丟棄或記錄，也不要卡住呼叫端」的情境。

1select {
2case jobs <- job:
3    logger.Info("job queued", "id", job.ID)
4default:
5    logger.Warn("job queue full", "id", job.ID)
6}

這個策略的代價是資料可能被丟棄，所以必須記錄 log 或回傳明確錯誤。若資料不能丟，就不要用 default；讓送出端阻塞或回傳「系統忙碌」會更誠實。

關閉 channel

關閉 channel 的核心規則是：由送出端關閉，表示不會再有新資料。接收端可以用 range 讀到 channel 關閉：

 1func producer(out chan<- int) {
 2    defer close(out)
 3    for i := 0; i < 3; i++ {
 4        out <- i
 5    }
 6}
 7
 8func consumer(in <-chan int) {
 9    for value := range in {
10        fmt.Println(value)
11    }
12}

接收端不應關閉自己沒有所有權的 channel；否則送出端可能在送資料時遇到 panic。

本章目標

學完本章後，你將能夠：

1. 理解 select 的基本語法
2. 同時等待多個 channel
3. 用 ctx.Done() 停止事件迴圈
4. 用 ticker 建立定時工作
5. 理解 default 的 non-blocking 行為

【觀察】select 同時等待多個 channel

select 的核心規則是：多個 case 中哪個 channel 先 ready，就執行哪個 case。以下範例同時等待 job 和取消訊號：

 1func worker(ctx context.Context, jobs <-chan Job) {
 2    for {
 3        select {
 4        case <-ctx.Done():
 5            return
 6        case job := <-jobs:
 7            handle(job)
 8        }
 9    }
10}

這個 worker 不需要先固定等待 jobs，也不需要用輪詢檢查 context。select 會同時等待兩者。

【判讀】select loop 是長期 goroutine 的生命週期中心

長期 goroutine 的核心規則是：事件迴圈必須同時處理工作來源與退出訊號。只讀工作 channel 而不讀 ctx.Done()，goroutine 可能無法按上層要求停止。

 1func worker(ctx context.Context, jobs <-chan Job) {
 2    for {
 3        select {
 4        case <-ctx.Done():
 5            return
 6        case job, ok := <-jobs:
 7            if !ok {
 8                return
 9            }
10            handle(job)
11        }
12    }
13}

ok == false 表示 channel 已關閉。這讓 worker 在「上層取消」和「工作來源結束」兩種情境都能退出。

【策略】ticker case 要有 Stop

ticker 的核心規則是：建立 ticker 後要呼叫 Stop()，避免不再使用時仍保留 runtime 資源。

 1func cleanupLoop(ctx context.Context) {
 2    ticker := time.NewTicker(time.Minute)
 3    defer ticker.Stop()
 4
 5    for {
 6        select {
 7        case <-ctx.Done():
 8            return
 9        case <-ticker.C:
10            cleanup()
11        }
12    }
13}

這種模式常用於定期清理、同步、掃描或報表輸出。

【執行】default 建立 non-blocking select

default 的核心規則是：沒有任何 channel ready 時，立即執行 default。這會讓 select 不阻塞。

1select {
2case jobs <- job:
3    return nil
4default:
5    return ErrQueueFull
6}

這段程式嘗試把 job 放進 channel；如果 channel 不能立即接收，就回傳 ErrQueueFull。這適合保護呼叫端不要被背景佇列卡住。

不適合用 default 的情境是你其實需要等待結果：

1select {
2case result := <-results:
3    return result
4default:
5    return Result{} // 可能過早返回
6}

若結果是必要的，應該等待或設定 timeout，而不是直接 default。

timeout pattern

timeout 的核心規則是：需要等待但不能無限等待時，用 time.After 或 context timeout。

1select {
2case result := <-results:
3    return result, nil
4case <-time.After(2 * time.Second):
5    return Result{}, errors.New("timeout")
6}

在較大的系統中，通常更偏好 context.WithTimeout，讓 timeout 可以沿呼叫鏈傳遞。

本章目標

學完本章後，你將能夠：

1. 理解 data race 的風險
2. 區分 Mutex 與 RWMutex
3. 用 RLock / RUnlock 保護讀取
4. 用 Lock / Unlock 保護寫入
5. 避免回傳內部 map 或 slice 破壞鎖邊界

【觀察】共享 map 不能被多個 goroutine 無保護地讀寫

共享狀態的核心規則是：只要多個 goroutine 可能同時讀寫同一份資料，就必須用同步機制保護。以下程式同時讀寫 map，存在 data race：

 1type UserRepository struct {
 2    users map[string]User
 3}
 4
 5func (r *UserRepository) Set(id string, user User) {
 6    r.users[id] = user
 7}
 8
 9func (r *UserRepository) Get(id string) (User, bool) {
10    user, ok := r.users[id]
11    return user, ok
12}

如果 Set 和 Get 從不同 goroutine 同時執行，map 可能被同時讀寫。Go 的 map 不保證這種情境安全。

【判讀】RWMutex 區分讀取與寫入

RWMutex 的核心規則是：讀取使用 RLock，寫入使用 Lock；多個讀取可並行，寫入會排他。

 1type UserRepository struct {
 2    users map[string]User
 3    mu    sync.RWMutex
 4}
 5
 6func (r *UserRepository) Set(id string, user User) {
 7    r.mu.Lock()
 8    defer r.mu.Unlock()
 9    r.users[id] = user
10}
11
12func (r *UserRepository) Get(id string) (User, bool) {
13    r.mu.RLock()
14    defer r.mu.RUnlock()
15    user, ok := r.users[id]
16    return user, ok
17}

Set 修改 map，所以用 Lock。Get 只讀 map，所以用 RLock。

【策略】鎖保護的是資料不變式

鎖範圍的核心規則是：鎖要包住所有需要一致觀察或一致修改的資料。鎖的邊界應涵蓋完整不變式，慢速 I/O、網路呼叫與和共享資料無關的計算則應放在鎖外。

例如，這個更新同時修改兩個欄位，兩個欄位要在同一把鎖內更新：

1func (r *UserRepository) Add(user User) {
2    r.mu.Lock()
3    defer r.mu.Unlock()
4
5    r.users[user.ID] = user
6    r.count++
7}

如果 users 和 count 分開鎖，讀者可能看到 map 已更新但 count 還沒更新的中間狀態。

【執行】回傳資料時要保留 copy boundary

鎖邊界的核心規則是：鎖只能保護鎖內操作；回傳內部 map 會讓呼叫者在鎖外修改資料，破壞 repository 對狀態的控制權。

不安全做法：

1func (r *UserRepository) Users() map[string]User {
2    r.mu.RLock()
3    defer r.mu.RUnlock()
4    return r.users
5}

安全做法是回傳複製：

 1func (r *UserRepository) Users() map[string]User {
 2    r.mu.RLock()
 3    defer r.mu.RUnlock()
 4
 5    result := make(map[string]User, len(r.users))
 6    for id, user := range r.users {
 7        result[id] = user
 8    }
 9    return result
10}

呼叫者拿到的是複本，不能繞過 UserRepository 修改內部狀態。

Mutex 還是 RWMutex？

選擇鎖的核心規則是：讀多寫少且讀操作可並行時用 RWMutex；不確定時先用 Mutex，設計更簡單。

sync.Mutex 的核心優勢是簡單。若狀態很小、讀寫都很快，或讀寫比例尚未明確，先使用 Mutex 通常更容易維護。它讓每次存取都走同一條鎖路徑，讀者也比較容易確認資料何時被保護。

sync.RWMutex 的核心優勢是讀多寫少時可以讓多個讀取並行。它適合像 in-memory cache、狀態查詢 repository 或連線註冊表這類讀取頻繁的資料結構。使用它時，寫入仍然要用 Lock，因為 RLock 只適合保護純讀取。

鎖選擇的判斷重點是資料不變式與讀寫比例。若讀取本身會組裝複雜資料、需要複製大型 map，或很快就會呼叫外部 I/O，RWMutex 帶來的並行讀取收益可能被複雜度抵消。

替代方案：什麼時候不用 RWMutex

RWMutex 不是共享狀態保護的唯一選擇。三類替代方案各有適用條件：

判別準則：

• 保護多欄位不變式（如 users + count 同步）→ RWMutex 或 Mutex
• 保護單一純量且操作可表達為 atomic op（CAS、increment）→ sync/atomic
• 保護大量獨立 key 且無跨 key 不變式 → sync.Map
• 狀態可由單一 owner 持有、外部用訊息驅動 → channel-based、見 4.2 / 4.5 backpressure

選錯方案的代價：用 sync/atomic 保護需要不變式的多欄位 → silent atomicity violation；用 sync.Map 期待 range 一致性 → 拿到 inconsistent snapshot；用 channel 處理需要嚴格 ordering 的 fan-in → 順序錯亂。

RWMutex 不解的問題

RWMutex 解的是 data race（多 goroutine 同時讀寫同一份資料的 visible race）。下列問題不在 RWMutex 防護範圍、必須由其他機制處理：

判讀訊號：

• go test -race pass、production 仍偶發資料異常 → 可能 atomicity violation 或 ordering bug、不是 data race
• 多核 CPU 加倍但 throughput 不增 → lock contention dominate、考慮 shard
• p99 latency 在高 concurrency 下爆炸 → reader 排隊或 starvation、查 lock 等待 metric
• shutdown 時 goroutine 不退 → reader hold RLock + 未 check ctx、補 context 檢查

Context dependence：scale 改變策略

RWMutex 的有效性會隨 deployment 條件變化：

• Map 大小：copy 成本隨 entries 線性增長、1k entries 廉價、1M entries 每次 copy 都是 GC pressure 來源；大 map 改 sync.Map 或 sharded
• 讀寫比例：90% 讀以下、RWMutex 收益不顯著、Mutex 簡單；讀寫接近時 RWMutex 的內部 atomic 操作成本可能反而比 Mutex 慢
• Goroutine 數量：少（< 10）時 contention 微、多（> 1000）時 RWMutex 不適合、要 shard 或換 lock-free 結構
• 持鎖時間：鎖內 microsecond 級 OK、毫秒級會堆隊；鎖內絕不做 I/O / 網路呼叫

選擇 RWMutex 前先問四件事

RWMutex 只解 data race subset——不解 deadlock / starvation / atomicity violation / context cancellation / 多核 contention scaling。狀態可表達為 atomic op、單 owner channel、或大量獨立 key 時、sync/atomic / channel-based / sync.Map 通常更合適。選擇前先問：「不變式跨幾個欄位？讀寫比例？goroutine 數量？持鎖時間？」

本章目標

學完本章後，你將能夠：

1. 理解 bounded concurrency 的用途
2. 用 semaphore 或 worker pool 限制同時工作數
3. 看懂 backpressure 為什麼能保護下游
4. 在併發流程中保留 cancellation 與 timeout
5. 辨認什麼時候該拒絕新工作

【觀察】高併發需要容量邊界

goroutine 很便宜，但每個工作仍會消耗下游連線、記憶體、排隊時間與錯誤處理能力。當所有工作都直接丟進 go func()，被放大的通常是：

• 連線數
• 記憶體
• 排隊延遲
• 下游壓力
• 故障面積

高併發設計的第一原則是「可控」。系統需要知道同時有多少工作在跑、多少工作在排隊、滿載時如何回應。

【判讀】bounded concurrency 是基本保護

bounded concurrency 的核心規則是：同一時間只允許有限數量的工作進行。這可以用 worker pool、semaphore 或排隊系統達成。

 1sem := make(chan struct{}, 16)
 2
 3for _, job := range jobs {
 4    sem <- struct{}{}
 5
 6    go func(job Job) {
 7        defer func() { <-sem }()
 8        process(job)
 9    }(job)
10}

這段程式限制同時只有 16 個工作在執行。當工作量暴增時，新的工作會自然排隊，而不是把整台機器一次推爆。

【策略】backpressure 保護的是下游

backpressure 的核心規則是：當系統處理不過來時，不要無限累積工作。這可以表現成：

• channel 滿了就阻塞
• queue 有上限
• goroutine pool 有上限
• 佇列滿時直接拒絕請求

例如 WebSocket、event consumer 或 background worker 如果沒有 backpressure ，輸入端一快，下游就會被放大成連鎖問題。

1select {
2case jobs <- job:
3    // accepted
4default:
5    return ErrQueueFull
6}

這種寫法的重點是明確表達滿載策略：系統在某些壓力下會拒絕新工作，因為保護整體健康比接住所有請求更重要。

【執行】cancellation 與 timeout 不能少

bounded concurrency 只控制數量，不能解決卡死工作。每個工作都應該保留取消訊號與 timeout，否則即使數量受限，資源也會被慢工作一直占著。

1ctx, cancel := context.WithTimeout(parent, 3*time.Second)
2defer cancel()
3
4if err := doWork(ctx, job); err != nil {
5    return err
6}

這樣可以讓每一筆工作都有自己的時間邊界，避免整體系統因單一慢點而拖垮。

【判讀】拒絕工作也是容量策略

拒絕新工作是保護容量邊界的一種策略。當以下條件成立時，拒絕通常比勉強接受更合理：

• queue 已滿
• 下游連線池耗盡
• timeout 已明顯增加
• 系統已進入明顯積壓

這時候回傳 429、503 或 domain-level rejection，往往比讓請求默默堆積更健康。

本章目標

學完本章後，你將能夠：

1. 分辨 process、thread 與 goroutine 的角色
2. 理解 Go 並發與平行執行不是同一件事
3. 看懂為什麼 I/O 型服務特別適合 Go
4. 判斷什麼時候應該限制並發數
5. 了解 Redis 與 SQL 在高併發下為什麼要加邊界

【觀察】goroutine 由 Go runtime 管理

goroutine 是 Go runtime 管理的輕量工作單位，OS thread 則是作業系統實際排程的執行緒。你通常不會直接手動管理 goroutine 對應到哪一條 thread；Go runtime 會負責把很多 goroutine 排程到較少的 OS thread 上。

這表示兩件事：

• 啟動 goroutine 的成本比建立 thread 低得多。
• goroutine 很便宜，不代表下游資源也很便宜。

【判讀】並發和平行是不同層次

並發的核心意義是「很多工作在時間上交疊」，平行的核心意義是「真的同時在多個核心上跑」。Go 可以讓你很容易建立並發工作，但是否能同時跑在多核心上，還要看 runtime 排程、CPU 數量與工作型態。

對服務開發來說，這個差異很重要：

• I/O-bound 工作通常最適合並發化，因為大部分時間都在等網路、磁碟或外部服務。
• CPU-bound 工作不會因為你加很多 goroutine 就自動變快，反而可能因為排程與同步成本變複雜。

【策略】高併發的真正重點是限制下游

Go 的 goroutine 很容易開，但 Redis、SQL、HTTP API、檔案描述元與記憶體 buffer 都有容量上限。高併發設計的核心是替外部資源設邊界，讓 goroutine 數量、下游連線與排隊時間都保持可預期。

常見邊界包括：

• worker pool 限制同時處理的工作量
• semaphore 或 rate limit 限制入口速率
• timeout / deadline 避免單一請求卡太久
• queue 或 buffer 對短暫尖峰提供緩衝
• backpressure 讓上游看到真實壓力

【應用】Redis 與 SQL 都是 I/O 邊界

Redis 與 SQL 在 Go 裡通常都被當成 I/O 操作來看待：goroutine 負責並發發出請求，但真正的瓶頸通常在網路延遲、連線數、鎖競爭、索引、熱點 key 或 transaction 範圍。

這也是為什麼後面的資料存取章節會反覆強調：

• client 或 sql.DB 要共用，不要每個 request 都 new
• 每個操作都應該帶 context
• 讀取可以大量並發，但要有連線池和 timeout
• 寫入可以並發，但要注意衝突、重試與交易邊界
• 當下游開始飽和時，要有明確的拒絕、排隊或降級策略

【延伸】runtime 細節不必現在全背

本章先建立 runtime 閱讀模型：goroutine 很輕，thread 有成本，下游資源有上限，並發要設邊界。runtime 的完整內部實作可以留到 profiling 與效能診斷階段再深入。

更進一步的診斷與觀察，會在後面的 runtime profiling 與 goroutine leak 章節再補。

本章先處理

這一章先把 Go 的並發模型講清楚；真正落到資料庫與快取時，可以再看：

• Backend：資料庫與持久化：看 SQL、transaction、connection pool 與 schema 邊界如何承接服務壓力。
• Backend：快取與 Redis：看 Redis client、TTL、eviction、presence store 與 hot key 如何承接服務壓力。
• bounded worker pool：把並發數收斂成可控容量。