Golang 並發編程：緩衝與非緩衝通道

簡介

在 Go 語言的並發模型裡，channel 是協調 goroutine 之間訊息傳遞的核心工具。無論是簡單的生產者‑消費者模式，還是複雜的工作流管線，通道的行為直接影響程式的正確性與效能。

通道分為 非緩衝（unbuffered） 與 緩衝（buffered） 兩種型別。非緩衝通道在發送與接收之間形成「同步點」，必須同時存在兩端才能完成傳遞；而緩衝通道則允許在沒有即時接收者的情況下暫存一定數量的訊息，提供「非同步」的特性。

了解兩者的差異、適用時機與常見陷阱，能讓你寫出更安全、效能更佳的並發程式。本篇文章將從概念說明、實作範例、最佳實踐一路帶你深入掌握緩衝與非緩衝通道。

---

核心概念

1. 非緩衝通道（Unbuffered Channel）

• 同步語意：ch <- v 會阻塞，直到有 goroutine 執行 <-ch 接收。
• 適用情境：需要確保「發送」與「接收」同時發生，例如協調兩個任務的交叉點、保證順序性。

範例 1：基本的同步通道

package main

import (
	"fmt"
	"time"
)

func main() {
	ch := make(chan int) // 非緩衝通道

	// 消費者
	go func() {
		val := <-ch               // 等待發送者
		fmt.Println("收到:", val) // 輸出 42
	}()

	time.Sleep(time.Millisecond) // 確保 goroutine 已啟動
	ch <- 42                      // 阻塞直到消費者接收
	fmt.Println("發送完成")
}

重點：ch <- 42 會卡在這裡，直到 <-ch 讀取完畢，才會印出「發送完成」。

---

2. 緩衝通道（Buffered Channel）

• 非同步語意：make(chan T, n) 建立容量為 n 的緩衝區。只要緩衝區未滿，ch <- v 不會阻塞。
• 適用情境：需要暫存工作、減少 goroutine 間的直接依賴，例如工作池、批次處理。

範例 2：緩衝通道的基本使用

package main

import (
	"fmt"
)

func main() {
	ch := make(chan string, 3) // 緩衝容量 3

	// 連續寫入三個值，皆不會阻塞
	ch <- "A"
	ch <- "B"
	ch <- "C"
	fmt.Println("已寫入三筆資料")

	// 第四次寫入會阻塞，因為緩衝已滿
	go func() {
		ch <- "D" // 會等到有空位才繼續
		fmt.Println("D 已寫入")
	}()

	// 讀取兩筆，釋放空間
	fmt.Println(<-ch) // A
	fmt.Println(<-ch) // B
	// 此時緩衝區只剩下 C，寫入 D 的 goroutine 會解除阻塞
	fmt.Println(<-ch) // C
	fmt.Println(<-ch) // D
}

觀察：緩衝區的大小決定了「多少筆」資料可以在不需要即時接收的情況下暫存。

---

3. 緩衝與非緩衝的混合使用

在實務上，常會把 非緩衝的控制訊號 與 緩衝的工作資料 結合，達到既能同步又能提升吞吐量的效果。

範例 3：工作池 + 結束信號

package main

import (
	"fmt"
	"sync"
	"time"
)

func worker(id int, jobs <-chan int, results chan<- int, wg *sync.WaitGroup) {
	defer wg.Done()
	for job := range jobs { // 只要有工作就持續處理
		fmt.Printf("worker %d 處理工作 %d\n", id, job)
		time.Sleep(100 * time.Millisecond) // 模擬耗時
		results <- job * 2                  // 回傳結果
	}
}

func main() {
	const numWorkers = 3
	const numJobs = 10

	jobs := make(chan int, numJobs)    // 緩衝通道：一次寫入全部工作
	results := make(chan int, numJobs) // 緩衝通道：收集結果

	var wg sync.WaitGroup
	for i := 1; i <= numWorkers; i++ {
		wg.Add(1)
		go worker(i, jobs, results, &wg)
	}

	// 產生工作
	for j := 1; j <= numJobs; j++ {
		jobs <- j
	}
	close(jobs) // **非緩衝** 的 close 會讓所有 worker 知道沒有新工作

	// 等待所有 worker 結束
	wg.Wait()
	close(results) // 結束結果收集

	// 顯示結果
	for r := range results {
		fmt.Println("結果:", r)
	}
}

說明：

• jobs 為緩衝通道，一次性寫入所有工作，避免產生者被阻塞。
• close(jobs) 是 非緩衝 的同步訊號，讓所有 worker 立即知道工作已完結。
• results 也是緩衝通道，讓主程式在等待 wg.Wait() 之後仍能快速讀取剩餘結果。

---

4. 單向通道（Direction‑only Channels）

為了避免誤用，Go 允許在函式參數上限制「只能寫」或「只能讀」：

func sendOnly(ch chan<- int) { ch <- 1 }
func recvOnly(ch <-chan int) int { return <-ch }

這在 非緩衝 與 緩衝 通道皆適用，能在編譯期捕捉錯誤。

---

5. 何時選擇緩衝？何時選擇非緩衝？

條件	建議使用	原因
必須保證發送與接收同時發生（例如同步 barrier）	非緩衝	阻塞保證兩端同步
需要暫存突發大量資料，避免產生者被阻塞	緩衝	緩衝區提供彈性
工作量不均，某些 goroutine 可能較慢	緩衝	減少慢者拖慢整體
訊號傳遞（如 quit、done）	非緩衝	確保訊號即時被接收

---

常見陷阱與最佳實踐

1. 緩衝區大小不當

• 過小：仍會頻繁阻塞，失去緩衝的好處。
• 過大：佔用過多記憶體，且可能掩蓋程式的瓶頸，難以偵測背壓（back‑pressure）問題。

最佳實踐：根據預估的峰值流量與系統記憶體限制，先以 小於 100 為起點，透過測試與監控逐步調整。

2. 忘記 close 緩衝通道

對於 非緩衝 通道，close 常用於告知接收端結束；但對 緩衝 通道若在寫入者仍可能寫入時就關閉，會造成 panic。

做法：在關閉前確保所有寫入者已結束（例如使用 sync.WaitGroup），或將「結束訊號」改為單獨的非緩衝通道。

3. 讀取空緩衝通道會阻塞

如果接收端在沒有資料的情況下直接 <-ch，會永久阻塞，除非使用 select 搭配 default 或 time.After。

select {
case v := <-ch:
    fmt.Println("收到:", v)
default:
    fmt.Println("暫時沒有資料")
}

4. 單向通道的誤用

把 chan<- T（只能寫）傳給需要讀取的函式，會在編譯期失敗。這其實是好事，只要在 API 設計時明確使用單向通道，就能避免意外的讀寫混用。

5. 競爭條件與資料遺失

在多個寫入者同時向 非緩衝 通道寫入時，如果沒有適當的同步機制，可能會出現「寫入失敗」的 panic（因為通道已關閉）。使用 sync.Once 或在關閉前先檢查 closed 狀態，可降低風險。

---

實際應用場景

1. 日誌聚合系統

• 緩衝通道：各個服務的 goroutine 將日誌訊息寫入緩衝通道，避免因磁碟 I/O 的慢速寫入而阻塞業務流程。
• 非緩衝通道：聚合器在寫入磁碟前，使用非緩衝通道傳遞「寫入完成」訊號，確保資料一致性。

2. Web Server 的請求限流

• 使用 緩衝通道 作為「令牌桶」：通道容量代表同時允許的最大請求數。每收到一個請求，就嘗試從通道取出一個令牌（非阻塞），若取不到則直接回應 429。

var limiter = make(chan struct{}, 100) // 最多 100 個同時請求

func handler(w http.ResponseWriter, r *http.Request) {
    select {
    case limiter <- struct{}{}: // 取得令牌
        defer func() { <-limiter }() // 完成後釋放
        // 處理請求
        fmt.Fprintln(w, "OK")
    default:
        http.Error(w, "Too Many Requests", http.StatusTooManyRequests)
    }
}

3. 資料管線（Pipeline）

在多階段資料處理時，緩衝通道 能讓前一階段持續產生資料，即使下一階段暫時忙碌；而 非緩衝通道 則用於傳遞「結束」或「錯誤」訊號，確保管線能正確關閉。

4. 分布式工作隊列

• 緩衝通道：在本機維持待執行的工作列表，快速分派給多個 worker。
• 非緩衝通道：當外部系統（如 Kafka）收到「任務完成」訊號時，立即通知調度器，避免重複排程。

---

總結

• 非緩衝通道 提供 同步 的訊息傳遞，適合需要即時配合的情境。
• 緩衝通道 則是 非同步 的緩衝層，能提升系統吞吐量與彈性，但必須謹慎設定容量與關閉時機。
• 在實務開發中，常見的做法是 混合使用：用緩衝通道暫存大量工作，用非緩衝通道傳遞控制訊號（如結束、錯誤）。
• 避免常見陷阱（緩衝過大/過小、未妥善關閉、阻塞讀取）並遵循最佳實踐（使用 select、sync.WaitGroup、單向通道），即可寫出 安全、可維護且效能良好 的 Go 並發程式。

掌握了緩衝與非緩衝通道的特性後，你就能在不同的應用場景中選擇最適合的工具，讓程式的併發行為更加可預測，也更容易除錯與優化。祝你在 Go 的並發世界裡玩得開心、寫得順手！