Java 并发队列深度解析：SynchronousQueue vs LinkedBlockingQueue vs ArrayBlockingQueue 選型指南

Java 并发队列深度解析：SynchronousQueue vs LinkedBlockingQueue vs ArrayBlockingQueue 選型指南

java.util.concurrent 包提供了多種阻塞隊列，其中最核心的三種——SynchronousQueue、LinkedBlockingQueue、ArrayBlockingQueue——各有獨特的內存模型、鎖策略、適用場景。本文從源碼級原理剖析三者差異，給出生產環境選型建議。

核心對比表

1. SynchronousQueue：不存儲元素的「直接移交」隊列

• 本質：無緩衝，`put(e)` 必須等待 `take()`，反之亦然。size() 永遠返回 0，peek() 永遠返回 null。
• 兩種模式：
  • 公平模式（`new SynchronousQueue(true)`）：公平鎖 + FIFO 隊列，先來先服務，適合要求公平的場景。
  • 非公平模式（默認）：非公平鎖 + LIFO 棧，性能更高但可能導致「餓死」（某些線程長期獲取不到數據）。
• 核心用途：Executors.newCachedThreadPool() 內部使用，任務直接移交給工作線程，無隊列積壓，線程空閒 60s 自動回收。

2. LinkedBlockingQueue：高吞吐的「雙鎖鏈表」隊列

• 無界默認：不指定容量則為 Integer.MAX_VALUE，生產者極快、消費者極慢時極易 OOM！生產環境強制指定容量：`new LinkedBlockingQueue<>(10000)`。
• 雙鎖設計：putLock 控制入隊，takeLock 控制出隊，生產與消費真正并行，吞吐極高。
• GC 壓力：每次入隊 `new Node(e)`，高頻長時間運行產生大量短命對象，增加 Young GC 頻率。

3. ArrayBlockingQueue：固定容量的「單鎖環形數組」隊列

• 有界強制：構造函數必須指定容量，天然背壓，保護下游。
• 單鎖：ReentrantLock 同步 put/take，生產消費串行，高并發下鎖競爭成為瓶頸。Doug Lea 認為操作輕量，引入雙鎖收益不抵復雜度。
• 零 GC 分配：數組固定，入隊僅賦值，長時間高頻運行 GC 最友好。
• 公平性可選：`new ArrayBlockingQueue<>(cap, true)` 使用公平鎖，吞吐下降但避免餓死。

選型決策樹

1. 需不需要緩衝？
   • 不需要（直接移交、線程池提交） → SynchronousQueue
   • 需要 → 看下一條
2. 是否需要有界防 OOM？
   • 是 → 看下一條
   • 否（極少見，需極大緩衝） → LinkedBlockingQueue(指定大容量)
3. 極致高并發吞吐、GC 敏感、固定緩存 → ArrayBlockingQueue
4. 極致高并發吞吐、允許適度 GC、動態緩存 → LinkedBlockingQueue(指定容量)

生產級最佳實踐

• 線程池任務隊列：固定線程池用 ArrayBlockingQueue（有界防 OOM），縮容線程池用 SynchronousQueue（無緩衝直接移交）。
• 異步日誌/事件總線：LinkedBlockingQueue（高吞吐、指定容量、異步消費）。
• 內存受限嵌入式/高頻交易：ArrayBlockingQueue（零分配、確定性延遲）。
• 監控指標：持續關注 queue.size() / capacity 使用率，設置告警閾值（如 80%）。

總結

三大隊列各有千秋：SynchronousQueue 傳遞、LinkedBlockingQueue 吞吐、ArrayBlockingQueue 確定性。理解底層鎖策略、內存模型、GC 行為，結合業務並發模式、內存預算、延遲要求，才能做出最優選型。切記：無界隊列生產環境禁用！