Go語言的并發(fā)模型以其簡潔直觀著稱，但這種簡單性背后，隱藏著一個(gè)跨越五個(gè)數(shù)量級的巨大性能鴻溝。當(dāng)你的高并發(fā)服務(wù)遭遇性能瓶頸時(shí)，你是否也曾陷入“性能猜謎”的困境：是sync.Mutex太慢？是atomic操作不夠快？還是某個(gè)channel的阻塞超出了預(yù)期？我們往往依賴直覺和pprof的零散線索，卻缺乏一個(gè)系統(tǒng)性的框架來指導(dǎo)我們的判斷。

最近，我讀到一篇5年前的，名為《A Concurrency Cost Hierarchy》的C++性能分析文章，該文通過精妙的實(shí)驗(yàn)，為并發(fā)操作的性能成本劃分了六個(gè)清晰的、成本呈數(shù)量級遞增的層級。這個(gè)模型如同一份性能地圖，為我們提供了告別猜謎、走向系統(tǒng)化優(yōu)化的鑰匙。

本文將這一強(qiáng)大的“并發(fā)成本層級”模型完整地移植并適配到Go語言的語境中，通過一系列完整、可復(fù)現(xiàn)的Go基準(zhǔn)測試代碼，為你打造一份專屬Gopher的“并發(fā)成本清單”。讀完本文，你將能清晰地識別出你的代碼位于哪個(gè)性能層級，理解其背后的成本根源，并找到通往更高性能層級的明確路徑。

注：Go運(yùn)行時(shí)和調(diào)度器的精妙之處，使得簡單的按原文的模型套用變得不準(zhǔn)確，本文將以真實(shí)的Go benchmark數(shù)據(jù)為基礎(chǔ)。

基準(zhǔn)測試環(huán)境與問題設(shè)定

為了具象化地衡量不同并發(fā)策略的成本，我們將貫穿使用一個(gè)簡單而經(jīng)典的問題：在多個(gè)Goroutine之間安全地對一個(gè)64位整型計(jì)數(shù)器進(jìn)行遞增操作。

我們將所有實(shí)現(xiàn)都遵循一個(gè)通用接口，并使用Go內(nèi)置的testing包進(jìn)行基準(zhǔn)測試。這能讓我們在統(tǒng)一的環(huán)境下，對不同策略進(jìn)行公平的性能比較。

下面便是包含了通用接口的基準(zhǔn)測試代碼文件main_test.go，你可以將以下所有代碼片段整合到該文件中，然后通過go test -bench=. -benchmem命令來親自運(yùn)行和驗(yàn)證這些性能測試。

// main_test.go
package concurrency_levels

import (
"math/rand"
"runtime"
"sync"
"sync/atomic"
"testing"
)

// Counter 是我們將要實(shí)現(xiàn)的各種并發(fā)計(jì)數(shù)器的通用接口
type Counter interface {
 Inc()
 Value() int64
}

// benchmark an implementation of the Counter interface
func benchmark(b *testing.B, c Counter) {
 b.ResetTimer()
 b.RunParallel(func(pb *testing.PB) {
for pb.Next() {
   c.Inc()
  }
 })
}

// --- 在此之下，我們將逐一添加各個(gè)層級的 Counter 實(shí)現(xiàn)和 Benchmark 函數(shù) ---

注意：請將所有后續(xù)代碼片段都放在這個(gè)concurrency_levels包內(nèi))。此外，下面文中的實(shí)測數(shù)據(jù)是基于我個(gè)人的Macbook Pro(intel x86芯片)測試所得：

$go test -bench .
goos: darwin
goarch: amd64
pkg: demo
cpu: Intel(R) Core(TM) i5-8257U CPU @ 1.40GHz
BenchmarkMutexCounter-8                 21802486         53.60 ns/op
BenchmarkAtomicCounter-8                75927309         15.55 ns/op
BenchmarkCasCounter-8                   12468513         98.30 ns/op
BenchmarkYieldingTicketLockCounter-8      401073       3516 ns/op
BenchmarkBlockingTicketLockCounter-8      986607       1619 ns/op
BenchmarkSpinningTicketLockCounter-8     6712968        154.6 ns/op
BenchmarkShardedCounter-8               201299956          5.997 ns/op
BenchmarkGoroutineLocalCounter-8        1000000000          0.2608 ns/op
PASS
ok   demo 10.128s

Level 2: 競爭下的原子操作與鎖 - 緩存一致性的代價(jià) (15ns - 100ns)

這是大多數(shù)并發(fā)程序的性能基準(zhǔn)線。其核心成本源于現(xiàn)代多核CPU的緩存一致性協(xié)議。當(dāng)多個(gè)核心試圖修改同一塊內(nèi)存時(shí)，它們必須通過總線通信，爭奪緩存行的“獨(dú)占”所有權(quán)。這個(gè)過程被稱為“緩存行彈跳”（Cache Line Bouncing），帶來了不可避免的硬件級延遲。

Go實(shí)現(xiàn)1: atomic.AddInt64 (實(shí)測: 15.55 ns/op)

// --- Level 2: Atomic ---
type AtomicCounter struct {
 counter int64
}
func (c *AtomicCounter) Inc() { atomic.AddInt64(&c.counter, 1) }
func (c *AtomicCounter) Value() int64 { return atomic.LoadInt64(&c.counter) }
func BenchmarkAtomicCounter(b *testing.B) { benchmark(b, &AtomicCounter{}) }

分析: atomic.AddInt64直接映射到CPU的原子加指令（如x86的LOCK XADD），是硬件層面最高效的競爭處理方式。15.5ns的成績展示了在高競爭下，硬件仲裁緩存行訪問的驚人速度。

Go實(shí)現(xiàn)2: sync.Mutex (實(shí)測: 53.60 ns/op)

// --- Level 2: Mutex ---
type MutexCounter struct {
 mu      sync.Mutex
 counter int64
}

func (c *MutexCounter) Inc() { c.mu.Lock(); c.counter++; c.mu.Unlock() }
func (c *MutexCounter) Value() int64 { c.mu.Lock(); defer c.mu.Unlock(); return c.counter }
func BenchmarkMutexCounter(b *testing.B) { benchmark(b, &MutexCounter{}) }

分析: Go的sync.Mutex是一個(gè)經(jīng)過高度優(yōu)化的混合鎖。在競爭激烈時(shí)，它會先進(jìn)行幾次CPU自旋，若失敗再通過調(diào)度器讓goroutine休眠。53.6ns的成本包含了自旋的CPU消耗以及可能的調(diào)度開銷，比純硬件原子操作慢，但依然高效。

Go實(shí)現(xiàn)3: CAS循環(huán) (實(shí)測: 98.30 ns/op)

// --- Level 2: CAS ---
type CasCounter struct {
 counter int64
}
func (c *CasCounter) Inc() {
for {
  old := atomic.LoadInt64(&c.counter)
if atomic.CompareAndSwapInt64(&c.counter, old, old+1) {
   return
  }
 }
}

func (c *CasCounter) Value() int64 { return atomic.LoadInt64(&c.counter) }
func BenchmarkCasCounter(b *testing.B) { benchmark(b, &CasCounter{}) }

分析: 出乎意料的是，CAS循環(huán)比sync.Mutex慢。 這是因?yàn)樵诟吒偁幭拢?/span>CompareAndSwap失敗率很高，導(dǎo)致for循環(huán)多次執(zhí)行。每次循環(huán)都包含一次Load和一次CompareAndSwap，多次的原子操作累加起來的開銷，超過了sync.Mutex內(nèi)部高效的自旋+休眠策略。這也從側(cè)面證明了Go的sync.Mutex針對高競爭場景做了非常出色的優(yōu)化。

Level 3 & 4: Scheduler深度介入 - Goroutine休眠與喚醒 (1,600ns - 3,600ns)

當(dāng)我們強(qiáng)制goroutine進(jìn)行休眠和喚醒，而不是讓sync.Mutex自行決定時(shí)，性能會迎來一個(gè)巨大的數(shù)量級下降。這里的成本來自于Go調(diào)度器執(zhí)行的復(fù)雜工作：保存goroutine狀態(tài)、將其移出運(yùn)行隊(duì)列、并在未來某個(gè)時(shí)間點(diǎn)再將其恢復(fù)。

Go實(shí)現(xiàn)1: 使用sync.Cond的阻塞鎖 (實(shí)測: 1619 ns/op)

// --- Level 3: Blocking Ticket Lock ---
type BlockingTicketLockCounter struct {
 mu sync.Mutex; cond *sync.Cond; ticket, turn, counter int64
}
func NewBlockingTicketLockCounter() *BlockingTicketLockCounter {
 c := &BlockingTicketLockCounter{}; c.cond = sync.NewCond(&c.mu); return c
}
func (c *BlockingTicketLockCounter) Inc() {
 c.mu.Lock()
 myTurn := c.ticket; c.ticket++
for c.turn != myTurn { c.cond.Wait() } // Goroutine休眠，等待喚醒
 c.mu.Unlock()
 atomic.AddInt64(&c.counter, 1) // 鎖外遞增
 c.mu.Lock()
 c.turn++; c.cond.Broadcast(); c.mu.Unlock()
}
func (c *BlockingTicketLockCounter) Value() int64 { c.mu.Lock(); defer c.mu.Unlock(); return c.counter }
func BenchmarkBlockingTicketLockCounter(b *testing.B) { benchmark(b, NewBlockingTicketLockCounter()) }

分析: 1619ns的成本清晰地展示了顯式cond.Wait()的代價(jià)。每個(gè)goroutine都會被park（休眠），然后被Broadcast unpark（喚醒）。這個(gè)過程比sync.Mutex的內(nèi)部調(diào)度要重得多。

Go實(shí)現(xiàn)2: 使用runtime.Gosched()的公平票據(jù)鎖 (實(shí)測: 3516 ns/op)

在深入代碼之前，我們必須理解設(shè)計(jì)這種鎖的動機(jī)。在某些并發(fā)場景中，“公平性”（Fairness）是一個(gè)重要的需求。一個(gè)公平鎖保證了等待鎖的線程（或goroutine）能按照它們請求鎖的順序來獲得鎖，從而避免“饑餓”（Starvation）——即某些線程長時(shí)間無法獲得執(zhí)行機(jī)會。

票據(jù)鎖（Ticket Lock） 是一種經(jīng)典的實(shí)現(xiàn)公平鎖的算法。它的工作方式就像在銀行排隊(duì)叫號：

1. 取號：當(dāng)一個(gè)goroutine想要獲取鎖時(shí)，它原子性地獲取一個(gè)唯一的“票號”（ticket）。
2. 等待叫號：它不斷地檢查當(dāng)前正在“服務(wù)”的號碼（turn）。
3. 輪到自己：直到當(dāng)前服務(wù)號碼與自己的票號相符，它才能進(jìn)入臨界區(qū)。
4. 服務(wù)下一位：完成工作后，它將服務(wù)號碼加一，讓下一個(gè)持有票號的goroutine進(jìn)入。

這種機(jī)制天然保證了“先到先得”的公平性。然而，關(guān)鍵在于“等待叫號”這個(gè)環(huán)節(jié)如何實(shí)現(xiàn)。YieldingTicketLockCounter選擇了一種看似“友好”的方式：在等待時(shí)調(diào)用runtime.Gosched()，主動讓出CPU給其他goroutine。我們想通過這種方式來測試：當(dāng)一個(gè)并發(fā)原語的設(shè)計(jì)強(qiáng)依賴于Go調(diào)度器的介入時(shí)，其性能成本會達(dá)到哪個(gè)數(shù)量級。

// --- Level 3: Yielding Ticket Lock ---
type YieldingTicketLockCounter struct {
 ticket, turn uint64; _ [48]byte; counter int64
}
func (c *YieldingTicketLockCounter) Inc() {
 myTurn := atomic.AddUint64(&c.ticket, 1) - 1
 for atomic.LoadUint64(&c.turn) != myTurn {
  runtime.Gosched() // 主動讓出執(zhí)行權(quán)
 }
 c.counter++; atomic.AddUint64(&c.turn, 1)
}
func (c *YieldingTicketLockCounter) Value() int64 { return c.counter }
func BenchmarkYieldingTicketLockCounter(b *testing.B) { benchmark(b, &YieldingTicketLockCounter{}) }

分析: 另一個(gè)意外發(fā)現(xiàn)：runtime.Gosched()比cond.Wait()更慢！ 這可能是因?yàn)?/span>cond.Wait()是一種目標(biāo)明確的休眠——“等待特定信號”，調(diào)度器可以高效地處理。而runtime.Gosched()則是一種更寬泛的請求——“請調(diào)度別的goroutine”，這可能導(dǎo)致了更多的調(diào)度器“抖動”和不必要的上下文切換，從而產(chǎn)生了更高的平均成本。

Go調(diào)度器能否化解Level 5災(zāi)難？

現(xiàn)在，我們來探討并發(fā)性能的“地獄”級別。這個(gè)級別的產(chǎn)生，源于一個(gè)在底層系統(tǒng)編程中常見，但在Go等現(xiàn)代托管語言中被刻意規(guī)避的設(shè)計(jì)模式：無限制的忙等待（Unbounded Spin-Wait）。

在C/C++等語言中，為了在極低延遲的場景下獲取鎖，開發(fā)者有時(shí)會編寫一個(gè)“自旋鎖”（Spinlock）。它不會讓線程休眠，而是在一個(gè)緊湊的循環(huán)中不斷檢查鎖的狀態(tài)，直到鎖被釋放。這種方式的理論優(yōu)勢是避免了昂貴的上下文切換，只要鎖的持有時(shí)間極短，自旋的CPU開銷就會小于一次線程休眠和喚醒的開銷。

災(zāi)難的根源：超訂（Oversubscription）

自旋鎖的致命弱點(diǎn)在于核心超訂——當(dāng)活躍的、試圖自旋的線程數(shù)量超過了物理CPU核心數(shù)時(shí)。在這種情況下，一個(gè)正在自旋的線程可能占據(jù)著一個(gè)CPU核心，而那個(gè)唯一能釋放鎖的線程卻沒有機(jī)會被調(diào)度到任何一個(gè)核心上運(yùn)行。結(jié)果就是，自旋線程白白燒掉了整個(gè)CPU時(shí)間片（通常是毫-秒-級別），而程序毫無進(jìn)展。這就是所謂的“鎖護(hù)航”（Lock Convoy）的極端形態(tài)。

我們的SpinningTicketLockCounter正是為了在Go的環(huán)境中復(fù)現(xiàn)這一經(jīng)典災(zāi)難場景。我們使用與之前相同的公平票據(jù)鎖邏輯，但將等待策略從“讓出CPU”(runtime.Gosched())改為最原始的“原地空轉(zhuǎn)”。我們想借此探索：Go的搶占式調(diào)度器，能否像安全網(wǎng)一樣，接住這個(gè)從高空墜落的性能災(zāi)難？

Go實(shí)現(xiàn): 自旋票據(jù)鎖 (實(shí)測: 154.6 ns/op，但在超訂下會凍結(jié))

// --- Level "5" Mitigated: Spinning Ticket Lock ---
type SpinningTicketLockCounter struct {
 ticket, turn uint64; _ [48]byte; counter int64
}
func (c *SpinningTicketLockCounter) Inc() {
 myTurn := atomic.AddUint64(&c.ticket, 1) - 1
for atomic.LoadUint64(&c.turn) != myTurn {
/* a pure spin-wait loop */
 }
 c.counter++; atomic.AddUint64(&c.turn, 1)
}
func (c *SpinningTicketLockCounter) Value() int64 { return c.counter }
func BenchmarkSpinningTicketLockCounter(b *testing.B) { benchmark(b, &SpinningTicketLockCounter{}) }

驚人的結(jié)果與分析:

默認(rèn)并發(fā)下 (-p=8, 8 goroutines on 4 cores): 性能為 154.6 ns/op。這遠(yuǎn)非災(zāi)難，而是回到了Level 2的范疇。原因是Go的搶占式調(diào)度器。它檢測到長時(shí)間運(yùn)行的無函數(shù)調(diào)用的緊密循環(huán)，并強(qiáng)制搶占，讓其他goroutine（包括持有鎖的那個(gè)）有機(jī)會運(yùn)行。這是Go的運(yùn)行時(shí)提供的強(qiáng)大安全網(wǎng)，將系統(tǒng)性災(zāi)難轉(zhuǎn)化為了性能問題。

但在嚴(yán)重超訂的情況下(通過b.SetParallelism(2)模擬16 goroutines on 4 cores)：

func BenchmarkSpinningTicketLockCounter(b *testing.B) {
    // 在測試中模擬超訂場景
    // 例如，在一個(gè)8核機(jī)器上，測試時(shí)設(shè)置 b.SetParallelism(2) * runtime.NumCPU()
    // 這會讓goroutine數(shù)量遠(yuǎn)超GOMAXPROCS
 b.SetParallelism(2)
    benchmark(b, &SpinningTicketLockCounter{})
}

我們的基準(zhǔn)測試結(jié)果顯示，當(dāng)b.SetParallelism(2)（在4核8線程機(jī)器上創(chuàng)建16個(gè)goroutine）時(shí)，這個(gè)測試無法完成，最終被手動中斷。這就是Level 5的真實(shí)面貌。

系統(tǒng)并未技術(shù)性死鎖，而是陷入了“活鎖”（Livelock）。過多的goroutine在瘋狂自旋，耗盡了所有CPU時(shí)間片。Go的搶占式調(diào)度器雖然在努力工作，但在如此極端的競爭下，它無法保證能在有效的時(shí)間內(nèi)將CPU資源分配給那個(gè)唯一能“解鎖”并推動系統(tǒng)前進(jìn)的goroutine。整個(gè)系統(tǒng)看起來就像凍結(jié)了一樣，雖然CPU在100%運(yùn)轉(zhuǎn)，但有效工作吞吐量趨近于零。

這證明了Go的運(yùn)行時(shí)安全網(wǎng)并非萬能。它能緩解一般情況下的忙等待，但無法抵御設(shè)計(jì)上就存在嚴(yán)重缺陷的、大規(guī)模的CPU資源濫用。

從災(zāi)難到高成本：runtime.Gosched()的“救贖” (實(shí)測: 5048 ns/op)

那么，如何從Level 5的災(zāi)難中“生還”？答案是：將非協(xié)作的忙等待，變?yōu)?/span>協(xié)作式等待，即在自旋循環(huán)中加入runtime.Gosched()。

// --- Level 3+: Cooperative High-Cost Wait ---
type CooperativeSpinningTicketLockCounter struct {
 ticket  uint64
 turn    uint64
 _       [48]byte
 counter int64
}

func (c *CooperativeSpinningTicketLockCounter) Inc() {
 myTurn := atomic.AddUint64(&c.ticket, 1) - 1
for atomic.LoadUint64(&c.turn) != myTurn {
// 通過主動讓出，將非協(xié)作的自旋變成了協(xié)作式的等待。
  runtime.Gosched()
 }
 c.counter++
 atomic.AddUint64(&c.turn, 1)
}

func (c *CooperativeSpinningTicketLockCounter) Value() int64 {
return c.counter
}

func BenchmarkCooperativeSpinningTicketLockCounter(b *testing.B) {
 b.SetParallelism(2)
 benchmark(b, &CooperativeSpinningTicketLockCounter{})
}

性能分析與討論：

基準(zhǔn)測試結(jié)果為5048 ns/op：

$go test -bench='^BenchmarkCooperativeSpinningTicketLockCounter$' -benchmem 
goos: darwin
goarch: amd64
pkg: demo
cpu: Intel(R) Core(TM) i5-8257U CPU @ 1.40GHz
BenchmarkCooperativeSpinningTicketLockCounter-8      328173       5048 ns/op        0 B/op        0 allocs/op
PASS
ok   demo 1.701s

程序不再凍結(jié)，但性能成本極高，甚至高于我們之前測試的BlockingTicketLockCounter和YieldingTicketLockCounter。

runtime.Gosched()在這里扮演了救世主的角色。它將一個(gè)可能導(dǎo)致系統(tǒng)停滯的活鎖問題，轉(zhuǎn)化成了一個(gè)單純的、可預(yù)測的性能問題。每個(gè)等待的goroutine不再霸占CPU，而是禮貌地告訴調(diào)度器：“我還在等，但你可以先運(yùn)行別的任務(wù)。” 這保證了持有鎖的goroutine最終能獲得執(zhí)行機(jī)會。

然而，這份“保證”的代價(jià)是高昂的。每次Gosched()調(diào)用都可能是一次昂貴的調(diào)度事件。在超訂的高競爭場景下，每個(gè)Inc()操作都可能觸發(fā)多次Gosched()，累加起來的成本甚至超過了sync.Cond的顯式休眠/喚醒。

因此，這個(gè)測試結(jié)果為我們的成本層級清單增加了一個(gè)重要的層次：它處于Level 3和Level 4之間，可以看作是一個(gè)“高成本的Level 3”。它展示了通過主動協(xié)作避免系統(tǒng)性崩潰，但為此付出了巨大的性能開銷。

Level 1: 無競爭原子操作 - 設(shè)計(jì)的力量 (~6 ns)

性能優(yōu)化的關(guān)鍵轉(zhuǎn)折點(diǎn)在于從“處理競爭”轉(zhuǎn)向“避免競爭”。Level 1的核心思想是通過設(shè)計(jì)，將對單個(gè)共享資源的競爭分散到多個(gè)資源上，使得每次操作都接近于無競爭狀態(tài)。

Go實(shí)現(xiàn)：分片計(jì)數(shù)器 (Sharded Counter)

// --- Level 1: Uncontended Atomics (Sharded) ---
const numShards = 256
type ShardedCounter struct {
 shards [numShards]struct{ counter int64; _ [56]byte }
}
func (c *ShardedCounter) Inc() {
 idx := rand.Intn(numShards) // 隨機(jī)選擇一個(gè)分片
 atomic.AddInt64(&c.shards[idx].counter, 1)
}
func (c *ShardedCounter) Value() int64 {
var total int64
for i := 0; i < numShards; i++ {
  total += atomic.LoadInt64(&c.shards[i].counter)
 }
return total
}
func BenchmarkShardedCounter(b *testing.B) { benchmark(b, &ShardedCounter{}) }

性能分析與討論: 5.997 ns/op！性能實(shí)現(xiàn)了數(shù)量級的飛躍。通過將寫操作分散到256個(gè)獨(dú)立的、被緩存行填充（padding）保護(hù)的計(jì)數(shù)器上，我們幾乎完全消除了緩存行彈跳。Inc()的成本急劇下降到接近單次無競爭原子操作的硬件極限。代價(jià)是Value()操作變慢了，且內(nèi)存占用激增。這是一個(gè)典型的空間換時(shí)間、讀性能換寫性能的權(quán)衡。

Level 0: “香草(Vanilla)”操作 - 并發(fā)的終極圣杯 (~0.26 ns)

性能的頂峰是Level 0，其特點(diǎn)是在熱路徑上完全不使用任何原子指令或鎖，只使用普通的加載和存儲指令（vanilla instructions）。

Go實(shí)現(xiàn)：Goroutine局部計(jì)數(shù)

我們通過將狀態(tài)綁定到goroutine自己的棧上，來徹底消除共享。

// --- Level 0: Vanilla Operations (Goroutine-Local) ---
func BenchmarkGoroutineLocalCounter(b *testing.B) {
var totalCounter int64
 b.ResetTimer()
 b.RunParallel(func(pb *testing.PB) {
var localCounter int64// 每個(gè)goroutine的棧上局部變量
for pb.Next() {
   localCounter++ // 在局部變量上操作，無任何同步！
  }
// 在每個(gè)goroutine結(jié)束時(shí)，將局部結(jié)果原子性地加到總數(shù)上
  atomic.AddInt64(&totalCounter, localCounter)
 })
}

性能分析與討論: 0.2608 ns/op！這個(gè)數(shù)字幾乎是CPU執(zhí)行一條簡單指令的速度。在RunParallel的循環(huán)體中，localCounter++操作完全在CPU的寄存器和L1緩存中進(jìn)行，沒有任何跨核通信的開銷。所有的同步成本（僅一次atomic.AddInt64）都被移到了每個(gè)goroutine生命周期結(jié)束時(shí)的冷路徑上。這種模式的本質(zhì)是通過算法和數(shù)據(jù)結(jié)構(gòu)的重新設(shè)計(jì)，從根本上消除共享。

結(jié)論：你的Go并發(fā)操作成本清單

基于真實(shí)的Go benchmark，我們得到了這份為Gopher量身定制的并發(fā)成本清單：

有了這份清單，我們可以：

1. 系統(tǒng)性地診斷：對照清單，分析你的熱點(diǎn)代碼究竟落在了哪個(gè)成本等級。
2. 明確優(yōu)化方向：最大的性能提升來自于從高成本層級向低成本層級的“降級”。
3. 優(yōu)先重構(gòu)算法：通往性能之巔（Level 1和Level 0）的道路，往往不是替換更快的鎖，而是從根本上重新設(shè)計(jì)數(shù)據(jù)流和算法。

Go的運(yùn)行時(shí)為我們抹平了一些最危險(xiǎn)的底層陷阱，但也讓性能分析變得更加微妙。這份清單，希望能成為你手中那張清晰的地圖，讓你在Go的并發(fā)世界中，告別猜謎，精準(zhǔn)導(dǎo)航

參考資料：https://travisdowns.github.io/blog/2020/07/06/concurrency-costs.html

本文涉及的示例源碼可以在這里下載 - https://github.com/bigwhite/experiments/tree/master/concurrency-costs