背景

這篇文章源自 GitHub 專案 go-concurrent-map-bench，作者針對 Go 語言中多種主流的並行雜湊表（Concurrent Hash Map）實作進行了詳盡的基準測試。測試對象涵蓋了 Go 1.24 標準庫中全新改版的 sync.Map，以及 xsync、cornelk/hashmap、haxmap 與傳統的分片式實作 orcaman/concurrent-map，旨在探討不同演算法在不同核心數與讀寫負載下的效能表現。

社群觀點

在技術社群的討論中，Go 1.24 對於標準庫 sync.Map 的重大更新成為了焦點。過去 sync.Map 常因其在寫入密集型場景下的效能瓶頸而受人詬病，但新版本改採 HashTrieMap 架構，透過 16 路分支的雜湊樹狀結構與細粒度的節點鎖，顯著提升了寫入效能。許多開發者認為，隨著標準庫實作的演進，第三方函式庫的生存空間正受到擠壓，因為對於大多數應用場景而言，標準庫提供的穩定性與「足夠好」的效能通常是首選。

然而，針對極致效能的需求，xsync.Map 的表現依然引起了高度關注。該實作利用了快取行大小的桶結構，並結合 SWAR（單指令多數據並行處理）技術進行快速鍵過濾，這種硬體友好的設計使其在高度競爭的環境下展現出優於標準庫的擴展性。特別是在讀取完全無鎖且寫入僅鎖定單一桶的機制下，xsync 在高 GOMAXPROCS 設定下的吞吐量優勢非常明顯。

關於鎖的設計哲學，社群中存在兩種截然不同的觀點。一派支持如 cornelk/hashmap 與 haxmap 所採用的完全無鎖（Lock-free）方案，這類方案基於原子操作（CAS）與排序鏈表，理論上能避免鎖競爭帶來的上下文切換開銷。但基準測試結果卻顯示，這類實作在處理大規模數據集時效能下降嚴重，甚至出現顯著的效能退化。這引發了開發者的反思：完全無鎖並不等同於高效能，複雜的 CAS 循環在高度競爭下可能反而不如精簡的細粒度鎖（Fine-grained locking）。

另一方面，傳統的分片式設計如 orcaman/concurrent-map 雖然在架構上顯得較為陳舊，僅是簡單地將多個標準 Map 組合並加上讀寫鎖，但其在記憶體分配率上的表現卻出奇地優異。由於其內部直接使用 Go 原生 Map，在覆寫既有鍵值時幾乎不產生額外的記憶體分配。這點醒了許多開發者，在追求複雜演算法之餘，簡單的分片機制在特定負載下依然具有極高的實用價值，特別是當系統瓶頸在於記憶體壓力而非 CPU 週期時。

最後，關於測試方法論的討論也相當熱烈。作者在測試中加入了預熱（Warm-up）與非預熱的對比，揭示了許多實作在動態擴容階段的效能波動。例如某些函式庫依賴背景協程進行非同步擴容，這雖然能平滑寫入延遲，但在極端高負載下可能導致記憶體失控。社群普遍認同，選擇並行雜湊表時不能僅看 ops/s 的平均值，必須綜合考慮擴容機制、記憶體分配成本以及在不同核心數下的線性擴展能力。