并发性能优化

Go 的并发是它的招牌特性，但「能并发」不等于「并发快」。错误的并发结构会引入锁竞争、goroutine 泄漏、过度调度等问题，反而比串行更慢。本篇从 GMP 调度模型讲起，覆盖 GOMAXPROCS 调优、并发模式（Worker Pool、Pipeline、Fan-out）的并行度选择、channel 与锁的性能对比、false sharing 等高级话题。

一、goroutine 调度：GMP 模型回顾

Go 的调度器基于 G-M-P 模型：

G（Goroutine）：协程，用户态轻量线程，初始栈 2KB。
M（Machine）：操作系统线程，真正执行代码的载体。
P（Processor）：逻辑处理器，持有可运行 G 的本地队列，数量 = GOMAXPROCS。

        ┌─── P0 ───┐  ┌─── P1 ───┐  ┌─── P2 ───┐
本地队列 │ G G G G  │  │ G G G    │  │ G G G G  │
        └────┬─────┘  └────┬─────┘  └────┬─────┘
             │             │             │
             ▼             ▼             ▼
            M0            M1            M2   ← OS 线程
             │             │             │
             └──────┬──────┴──────┬──────┘
                    ▼             ▼
                内核调度      内核调度

关键机制：

work stealing：当 P 的本地队列空时，从其他 P 偷一半 G，避免空闲。
handoff：当 G 阻塞在系统调用，M 陷入内核，P 会与该 M 解绑，找新 M 继续跑其他 G。
网络轮询器：网络 I/O 不阻塞 M，由 netpoller 异步通知。

二、GOMAXPROCS 调优

1. 默认值 = CPU 核数

GOMAXPROCS 默认等于 runtime.NumCPU()，即逻辑 CPU 核数。对纯 CPU 密集型任务，这是最优值。

2. 容器环境下的陷阱

在容器（cgroup CPU quota 限制）中，runtime.NumCPU() 仍返回宿主机核数，而非容器限制。例如宿主机 32 核，容器限制 2 核，Go 默认起 32 个 P，导致：

调度开销大：32 个 P 抢 2 个核，上下文切换频繁。
GC 并行度过高：32 个 GC worker 互相抢核。
延迟抖动：P 数远超实际 CPU，goroutine 调度延迟升高。

3. CPU 限制感知：automaxprocs 库

go.uber.org/automaxprocs 自动读取 cgroup 限制并设置 GOMAXPROCS，是容器部署的标配。

package main

import (
	"fmt"
	_ "go.uber.org/automaxprocs" // 导入即生效，自动设置 GOMAXPROCS
	"runtime"
)

func main() {
	fmt.Println("GOMAXPROCS:", runtime.GOMAXPROCS(0))
	// 在 2 核限制的容器中，会输出 2 而非宿主机核数
}

如果不引入第三方库，可手动读取 cgroup：

package main

import (
	"fmt"
	"os"
	"runtime"
	"strconv"
	"strings"
)

func maxProcsFromCgroup() int {
	// cgroup v2
	data, err := os.ReadFile("/sys/fs/cgroup/cpu.max")
	if err == nil {
		fields := strings.Fields(string(data))
		if len(fields) == 2 && fields[0] != "max" {
			quota, _ := strconv.Atoi(fields[0])
			period, _ := strconv.Atoi(fields[1])
			if period > 0 {
				return quota / period
			}
		}
	}
	return runtime.NumCPU()
}

func main() {
	n := maxProcsFromCgroup()
	if n < 1 {
		n = 1
	}
	runtime.GOMAXPROCS(n)
	fmt.Println("GOMAXPROCS set to", n)
}

三、并发模式性能分析

1. Worker Pool 最优大小

Worker 数不是越多越好。对 CPU 密集型，最优 worker 数 ≈ GOMAXPROCS；对 I/O 密集型，可远大于 GOMAXPROCS。

package main

import (
	"fmt"
	"runtime"
	"sync"
	"testing"
	"time"
)

func cpuTask(n int) int {
	total := 0
	for i := 0; i < n; i++ {
		total += i * i
	}
	return total
}

func workerPool(tasks <-chan int, results chan<- int, wg *sync.WaitGroup) {
	defer wg.Done()
	for t := range tasks {
		results <- cpuTask(t)
	}
}

func runPool(numWorkers, numTasks int) {
	tasks := make(chan int, numTasks)
	results := make(chan int, numTasks)
	var wg sync.WaitGroup
	for i := 0; i < numWorkers; i++ {
		wg.Add(1)
		go workerPool(tasks, results, &wg)
	}
	for i := 0; i < numTasks; i++ {
		tasks <- 100000
	}
	close(tasks)
	wg.Wait()
	close(results)
	for range results {
	}
}

func BenchmarkPool1(b *testing.B)  { for i := 0; i < b.N; i++ { runPool(1, 100) } }
func BenchmarkPool2(b *testing.B)  { for i := 0; i < b.N; i++ { runPool(2, 100) } }
func BenchmarkPool4(b *testing.B)  { for i := 0; i < b.N; i++ { runPool(4, 100) } }
func BenchmarkPool8(b *testing.B)  { for i := 0; i < b.N; i++ { runPool(8, 100) } }
func BenchmarkPool16(b *testing.B) { for i := 0; i < b.N; i++ { runPool(16, 100) } }

func main() {
	fmt.Println("CPU cores:", runtime.NumCPU())
	time.Now() // keep time import
}

在 8 核机器上，CPU 密集任务 worker=8 时最优，worker=16 反而因调度开销变慢。I/O 任务则相反，worker 数可设为 GOMAXPROCS × (1 + I/O等待时间/CPU时间)。

2. Pipeline 各阶段并行度

Pipeline 模式中，各阶段处理速度不同，需按「最慢阶段」配比并行度，避免瓶颈。

package main

import "fmt"

// 三阶段 pipeline：读取 → 处理 → 写出
// 假设处理是瓶颈，应给它更多 worker

func stage[T any](name string, in <-chan T, out chan<- T, work func(T) T) {
	for v := range in {
		out <- work(v)
	}
}

func main() {
	read := make(chan int, 100)
	process := make(chan int, 100)
	write := make(chan int, 100)

	// 1 个 reader（I/O 快）
	go stage("read", read, process, func(v int) int { return v })

	// 4 个 processor（CPU 慢，多开）
	for i := 0; i < 4; i++ {
		go func() {
			for v := range process {
				write <- v * v
			}
		}()
	}

	// 1 个 writer
	go func() {
		for v := range write {
			fmt.Println(v)
		}
	}()

	for i := 0; i < 10; i++ {
		read <- i
	}
	close(read)
}

各阶段缓冲区大小 = 阶段并行度 × 2 左右，平滑速度波动。

3. Fan-out 数量选择

Fan-out（扇出）是把一个任务分发给多个 worker 并行处理。数量选择与 Worker Pool 类似，但更强调「分发开销 vs 并行收益」的平衡。

package main

import (
	"fmt"
	"sync"
)

func fanOut(input []int, workers int) []int {
	chunkSize := (len(input) + workers - 1) / workers
	results := make([][]int, workers)
	var wg sync.WaitGroup
	for i := 0; i < workers; i++ {
		wg.Add(1)
		go func(idx int) {
			defer wg.Done()
			start := idx * chunkSize
			end := start + chunkSize
			if end > len(input) {
				end = len(input)
			}
			r := make([]int, end-start)
			for j := start; j < end; j++ {
				r[j-start] = input[j] * input[j]
			}
			results[idx] = r
		}(i)
	}
	wg.Wait()
	var out []int
	for _, r := range results {
		out = append(out, r...)
	}
	return out
}

func main() {
	input := make([]int, 1000)
	for i := range input {
		input[i] = i
	}
	out := fanOut(input, 4)
	fmt.Println("first 5:", out[:5])
}

任务过小（如 input 只有 10 个元素）时 fan-out 收益为负——分发与合并的开销超过并行收益。经验：单任务执行时间 > 1μs 且总数 > 1000 时，fan-out 才有意义。

四、Channel 性能

1. 有缓冲 vs 无缓冲性能对比

无缓冲：发送和接收同步，强耦合，但有额外同步开销。
有缓冲：发送和接收解耦，缓冲区内不阻塞，吞吐更高。

package main

import (
	"sync"
	"testing"
)

func benchUnbuffered(b *testing.B, n int) {
	ch := make(chan int)
	var wg sync.WaitGroup
	wg.Add(1)
	go func() {
		defer wg.Done()
		for i := 0; i < n; i++ {
			<-ch
		}
	}()
	b.ResetTimer()
	for i := 0; i < n; i++ {
		ch <- i
	}
	b.StopTimer()
	wg.Wait()
}

func benchBuffered(b *testing.B, n, buf int) {
	ch := make(chan int, buf)
	var wg sync.WaitGroup
	wg.Add(1)
	go func() {
		defer wg.Done()
		for i := 0; i < n; i++ {
			<-ch
		}
	}()
	b.ResetTimer()
	for i := 0; i < n; i++ {
		ch <- i
	}
	b.StopTimer()
	wg.Wait()
}

func BenchmarkUnbuffered(b *testing.B) { benchUnbuffered(b, b.N) }
func BenchmarkBuf1(b *testing.B)       { benchBuffered(b, b.N, 1) }
func BenchmarkBuf16(b *testing.B)      { benchBuffered(b, b.N, 16) }
func BenchmarkBuf256(b *testing.B)     { benchBuffered(b, b.N, 256) }

无缓冲最慢（每次发送都要唤醒接收方），缓冲 256 通常最快。但缓冲不是越大越好——过大的缓冲隐藏了背压问题，可能堆积大量数据。

2. 缓冲区大小对性能的影响

缓冲区大小的选择原则：

生产 > 消费：缓冲填满后仍会阻塞，大缓冲只是延缓问题。
生产 ≈ 消费：小缓冲（1-4）即可平滑波动。
突发流量：缓冲设为「一次突发的量」，避免丢任务。

package main

import (
	"fmt"
	"time"
)

func main() {
	// 模拟突发：1 秒内产生 1000 任务，消费速度 100/秒
	// 缓冲需 ≥ 900 才能不阻塞生产者（1秒内积压 900）
	// 实际应配合背压机制，而非无限大缓冲
	ch := make(chan int, 1000)
	go func() {
		for i := 0; i < 1000; i++ {
			ch <- i
		}
	}()
	go func() {
		for v := range ch {
			fmt.Println(v)
			time.Sleep(10 * time.Millisecond)
		}
	}()
	time.Sleep(15 * time.Second)
}

3. 批量处理减少 channel 通信

每次 channel 收发都有调度开销。批量发送/接收能摊薄这个开销。

package main

import (
	"sync"
	"testing"
)

func singleSend(b *testing.B, n int) {
	ch := make(chan int, n)
	var wg sync.WaitGroup
	wg.Add(1)
	go func() {
		defer wg.Done()
		for i := 0; i < n; i++ {
			<-ch
		}
	}()
	b.ResetTimer()
	for i := 0; i < n; i++ {
		ch <- i
	}
	b.StopTimer()
	wg.Wait()
}

func batchSend(b *testing.B, n, batchSize int) {
	ch := make(chan []int, n/batchSize+1)
	var wg sync.WaitGroup
	wg.Add(1)
	go func() {
		defer wg.Done()
		for range ch {
		}
	}()
	b.ResetTimer()
	for i := 0; i < n; i += batchSize {
		end := i + batchSize
		if end > n {
			end = n
		}
		ch <- make([]int, end-i)
	}
	b.StopTimer()
	wg.Wait()
}

func BenchmarkSingle(b *testing.B) { singleSend(b, b.N) }
func BenchmarkBatch10(b *testing.B) { batchSend(b, b.N, 10) }
func BenchmarkBatch100(b *testing.B) { batchSend(b, b.N, 100) }

批量通常快 3-10 倍，但增加延迟（需凑满一批）。适合吞吐优先、延迟不敏感的场景。

五、锁优化

1. sync.Mutex vs sync.RWMutex 性能对比

RWMutex 在「读多写少」时优于 Mutex，但读少写多时反而更慢（RWMutex 维护读者计数有开销）。

package main

import (
	"sync"
	"testing"
)

type SafeMap struct {
	mu sync.Mutex
	m  map[int]int
}

type SafeMapRW struct {
	mu sync.RWMutex
	m  map[int]int
}

func (s *SafeMap) Get(k int) int {
	s.mu.Lock()
	defer s.mu.Unlock()
	return s.m[k]
}

func (s *SafeMapRW) Get(k int) int {
	s.mu.RLock()
	defer s.mu.RUnlock()
	return s.m[k]
}

var keys = func() []int {
	ks := make([]int, 1000)
	for i := range ks {
		ks[i] = i
	}
	return ks
}()

func BenchmarkMutex(b *testing.B) {
	s := &SafeMap{m: make(map[int]int)}
	for _, k := range keys {
		s.m[k] = k
	}
	b.ResetTimer()
	b.RunParallel(func(pb *testing.PB) {
		i := 0
		for pb.Next() {
			_ = s.Get(keys[i%len(keys)])
			i++
		}
	})
}

func BenchmarkRWMutex(b *testing.B) {
	s := &SafeMapRW{m: make(map[int]int)}
	for _, k := range keys {
		s.m[k] = k
	}
	b.ResetTimer()
	b.RunParallel(func(pb *testing.PB) {
		i := 0
		for pb.Next() {
			_ = s.Get(keys[i%len(keys)])
			i++
		}
	})
}

读多写少时 RWMutex 快 2-5 倍；写多时 Mutex 更快。先 benchmark 再选择。

2. 减小临界区

临界区越小，锁持有时间越短，并发度越高。把与锁无关的操作移出临界区。

package main

import (
	"sync"
	"testing"
)

type Cache struct {
	mu    sync.Mutex
	store map[string]string
}

// Bad: 整个处理在锁内
func (c *Cache) ProcessBad(key string) string {
	c.mu.Lock()
	defer c.mu.Unlock()
	v := c.store[key]
	// 重量级处理在锁内，拖慢其他访问者
	result := heavyProcess(v)
	c.store[key] = result
	return result
}

// Good: 只在访问 map 时持锁
func (c *Cache) ProcessGood(key string) string {
	c.mu.Lock()
	v := c.store[key]
	c.mu.Unlock()
	// 重量级处理在锁外
	result := heavyProcess(v)
	c.mu.Lock()
	c.store[key] = result
	c.mu.Unlock()
	return result
}

func heavyProcess(s string) string {
	out := make([]byte, len(s))
	for i := range s {
		out[i] = s[i] + 1
	}
	return string(out)
}

3. 分段锁

对大 map，单把锁是瓶颈。分段锁（sharded map）把数据分散到 N 个分片，每个分片一把锁，并行度提升 N 倍。

package main

import (
	"hash/fnv"
	"sync"
	"testing"
)

type Shard struct {
	mu sync.Mutex
	m  map[string]int
}

type ShardedMap struct {
	shards []*Shard
	n      int
}

func NewShardedMap(n int) *ShardedMap {
	sm := &ShardedMap{shards: make([]*Shard, n), n: n}
	for i := range sm.shards {
		sm.shards[i] = &Shard{m: make(map[string]int)}
	}
	return sm
}

func (sm *ShardedMap) shard(key string) *Shard {
	h := fnv.New32a()
	h.Write([]byte(key))
	return sm.shards[h.Sum32()%uint32(sm.n)]
}

func (sm *ShardedMap) Set(key string, v int) {
	s := sm.shard(key)
	s.mu.Lock()
	s.m[key] = v
	s.mu.Unlock()
}

func (sm *ShardedMap) Get(key string) int {
	s := sm.shard(key)
	s.mu.Lock()
	defer s.mu.Unlock()
	return s.m[key]
}

func BenchmarkSingleLock(b *testing.B) {
	var mu sync.Mutex
	m := make(map[string]int)
	b.RunParallel(func(pb *testing.PB) {
		i := 0
		for pb.Next() {
			mu.Lock()
			m["key"] = i
			mu.Unlock()
			i++
		}
	})
}

func BenchmarkSharded(b *testing.B) {
	sm := NewShardedMap(32)
	b.RunParallel(func(pb *testing.PB) {
		i := 0
		for pb.Next() {
			sm.Set("key", i)
			i++
		}
	})
}

分段数通常取 16/32/64，与 GOMAXPROCS 同数量级。

4. sync.Map vs map+Mutex

sync.Map 适合「读多写少且 key 集合稳定」的场景，内部用 read/dirty 双 map 优化读路径。写多或 key 频繁变更时不如 map+Mutex。

package main

import (
	"sync"
	"testing"
)

func BenchmarkMapMutex(b *testing.B) {
	var mu sync.Mutex
	m := make(map[int]int)
	b.RunParallel(func(pb *testing.PB) {
		for pb.Next() {
			mu.Lock()
			m[1] = 1
			_ = m[1]
			mu.Unlock()
		}
	})
}

func BenchmarkSyncMap(b *testing.B) {
	var m sync.Map
	b.RunParallel(func(pb *testing.PB) {
		for pb.Next() {
			m.Store(1, 1)
			_, _ = m.Load(1)
		}
	})
}

读远多于写时 sync.Map 优势明显；写多时 map+Mutex 更快。

5. atomic vs Mutex

对单个数值的并发读写，sync/atomic 比 Mutex 快 5-10 倍，因为是无锁的 CPU 指令。

package main

import (
	"sync"
	"sync/atomic"
	"testing"
)

func BenchmarkMutexCounter(b *testing.B) {
	var mu sync.Mutex
	var n int
	b.RunParallel(func(pb *testing.PB) {
		for pb.Next() {
			mu.Lock()
			n++
			mu.Unlock()
		}
	})
}

func BenchmarkAtomicCounter(b *testing.B) {
	var n int64
	b.RunParallel(func(pb *testing.PB) {
		for pb.Next() {
			atomic.AddInt64(&n, 1)
		}
	})
}

规则：单变量并发更新用 atomic，临界区或多变量用 Mutex。

False sharing（伪共享）：多个 goroutine 写不同变量，但变量在同一缓存行（通常 64 字节），导致 CPU 缓存频繁失效。

package main

import (
	"sync"
	"testing"
)

type Counters struct {
	a int64 // 8 bytes
	b int64 // 8 bytes
	// a 和 b 可能在同一缓存行，并发写 a 和 b 会触发 false sharing
}

func BenchmarkFalseSharing(b *testing.B) {
	c := &Counters{}
	var wg sync.WaitGroup
	wg.Add(2)
	b.ResetTimer()
	go func() {
		defer wg.Done()
		for i := 0; i < b.N; i++ {
			c.a++
		}
	}()
	go func() {
		defer wg.Done()
		for i := 0; i < b.N; i++ {
			c.b++
		}
	}()
	wg.Wait()
}

// 用 padding 隔离到不同缓存行
type CountersPadded struct {
	a int64
	_ [56]byte // 填充到 64 字节缓存行
	b int64
}

func BenchmarkNoFalseSharing(b *testing.B) {
	c := &CountersPadded{}
	var wg sync.WaitGroup
	wg.Add(2)
	b.ResetTimer()
	go func() {
		defer wg.Done()
		for i := 0; i < b.N; i++ {
			c.a++
		}
	}()
	go func() {
		defer wg.Done()
		for i := 0; i < b.N; i++ {
			c.b++
		}
	}()
	wg.Wait()
}

padding 版本通常快 2-3 倍。Go 标准库的 sync.Pool、sync.Mutex 内部就用了 padding。但日常业务代码不必过度优化，只在 profile 发现缓存行争用时才处理。

七、完整示例：并发数据处理优化

需求：对 100 万个整数求平方和，对比串行、朴素并发、优化并发三版。

1. 串行版

package main

import "testing"

func sumSquaresSerial(nums []int) int {
	total := 0
	for _, n := range nums {
		total += n * n
	}
	return total
}

func BenchmarkSerial(b *testing.B) {
	nums := make([]int, 1000000)
	for i := range nums {
		nums[i] = i
	}
	b.ResetTimer()
	for i := 0; i < b.N; i++ {
		_ = sumSquaresSerial(nums)
	}
}

2. 朴素并发版（用 Mutex 累加，有锁竞争）

package main

import (
	"sync"
	"testing"
)

func sumSquaresNaive(nums []int) int {
	var mu sync.Mutex
	total := 0
	var wg sync.WaitGroup
	workers := 8
	chunk := len(nums) / workers
	for w := 0; w < workers; w++ {
		wg.Add(1)
		go func(start int) {
			defer wg.Done()
			end := start + chunk
			localSum := 0
			for i := start; i < end; i++ {
				localSum += nums[i] * nums[i]
			}
			mu.Lock()
			total += localSum
			mu.Unlock()
		}(w * chunk)
	}
	wg.Wait()
	return total
}

func BenchmarkNaive(b *testing.B) {
	nums := make([]int, 1000000)
	for i := range nums {
		nums[i] = i
	}
	b.ResetTimer()
	for i := 0; i < b.N; i++ {
		_ = sumSquaresNaive(nums)
	}
}

package main

import (
	"sync"
	"testing"
)

func sumSquaresOptimized(nums []int) int64 {
	workers := 8
	partials := make([]int64, workers) // 每个 worker 独立槽位，避免 false sharing
	chunk := len(nums) / workers
	var wg sync.WaitGroup
	for w := 0; w < workers; w++ {
		wg.Add(1)
		go func(idx, start int) {
			defer wg.Done()
			var localSum int64
			end := start + chunk
			for i := start; i < end; i++ {
				localSum += int64(nums[i]) * int64(nums[i])
			}
			partials[idx] = localSum // 无锁写自己的槽位
		}(w, w*chunk)
	}
	wg.Wait()
	var total int64
	for _, p := range partials {
		total += p
	}
	return total
}

func BenchmarkOptimized(b *testing.B) {
	nums := make([]int, 1000000)
	for i := range nums {
		nums[i] = i
	}
	b.ResetTimer()
	for i := 0; i < b.N; i++ {
		_ = sumSquaresOptimized(nums)
	}
}

4. 对比结果

bash

go test -bench=. -benchmem
# BenchmarkSerial-8      20   52000000 ns/op    0 B/op   0 allocs/op
# BenchmarkNaive-8        8  120000000 ns/op  800 B/op   2 allocs/op   ← 锁竞争拖慢
# BenchmarkOptimized-8   60   18000000 ns/op  128 B/op   1 allocs/op   ← 真并行

朴素并发版因锁竞争反而比串行慢！优化版用「每个 worker 独立槽位 + 末尾合并」消除锁，比串行快约 3 倍，接近 8 核理论上限。

八、小结

GOMAXPROCS 要匹配实际 CPU：容器环境用 automaxprocs，否则 P 数虚高拖累调度。
Worker 数按负载类型定：CPU 密集 ≈ GOMAXPROCS，I/O 密集可数倍之。
Pipeline 按瓶颈阶段加权：慢阶段多 worker，快阶段少 worker，缓冲区平滑波动。
Fan-out 需任务足够大：单任务 < 1μs 或总数 < 1000 时，并行收益为负。
有缓冲 channel 吞吐更高：但缓冲不是越大越好，注意背压。
批量通信摊薄调度开销：适合吞吐优先场景。
锁选择看读写比：读多写少 RWMutex，写多 Mutex，单变量 atomic。
减小临界区：把无关操作移出锁，是零成本优化。
分段锁突破单锁瓶颈：大 map 用 16/32 分片，并行度数量级提升。
false sharing 用 padding 隔离：profile 发现缓存行争用才处理。
朴素并发可能比串行慢：锁竞争是性能杀手，优先无锁结构（局部累加 + 合并）。

下一篇我们进入 I/O 与网络优化，讲解 netpoller、HTTP/DB 连接池、文件 I/O、JSON 与序列化优化。

入门篇

进阶篇

资深篇

并发性能优化

一、goroutine 调度：GMP 模型回顾

二、GOMAXPROCS 调优

1. 默认值 = CPU 核数

2. 容器环境下的陷阱

3. CPU 限制感知：automaxprocs 库

三、并发模式性能分析

1. Worker Pool 最优大小

2. Pipeline 各阶段并行度

3. Fan-out 数量选择

四、Channel 性能

1. 有缓冲 vs 无缓冲性能对比

2. 缓冲区大小对性能的影响

3. 批量处理减少 channel 通信

五、锁优化

1. sync.Mutex vs sync.RWMutex 性能对比

2. 减小临界区

3. 分段锁

4. sync.Map vs map+Mutex

5. atomic vs Mutex

七、完整示例：并发数据处理优化

1. 串行版

2. 朴素并发版（用 Mutex 累加，有锁竞争）

4. 对比结果

八、小结

并发性能优化 ​

一、goroutine 调度：GMP 模型回顾 ​

二、GOMAXPROCS 调优 ​

1. 默认值 = CPU 核数 ​

2. 容器环境下的陷阱 ​

3. CPU 限制感知：automaxprocs 库 ​

三、并发模式性能分析 ​

1. Worker Pool 最优大小 ​

2. Pipeline 各阶段并行度 ​

3. Fan-out 数量选择 ​

四、Channel 性能 ​

1. 有缓冲 vs 无缓冲性能对比 ​

2. 缓冲区大小对性能的影响 ​

3. 批量处理减少 channel 通信 ​

五、锁优化 ​

1. sync.Mutex vs sync.RWMutex 性能对比 ​

2. 减小临界区 ​

3. 分段锁 ​

4. sync.Map vs map+Mutex ​

5. atomic vs Mutex ​

六、false sharing 问题 ​

七、完整示例：并发数据处理优化 ​

1. 串行版 ​

2. 朴素并发版（用 Mutex 累加，有锁竞争） ​

3. 优化版（局部累加 + 无锁合并，避免 false sharing） ​

4. 对比结果 ​

八、小结 ​

并发性能优化

一、goroutine 调度：GMP 模型回顾

二、GOMAXPROCS 调优

1. 默认值 = CPU 核数

2. 容器环境下的陷阱

3. CPU 限制感知：automaxprocs 库

三、并发模式性能分析

1. Worker Pool 最优大小

2. Pipeline 各阶段并行度

3. Fan-out 数量选择

四、Channel 性能

1. 有缓冲 vs 无缓冲性能对比

2. 缓冲区大小对性能的影响

3. 批量处理减少 channel 通信

五、锁优化

1. sync.Mutex vs sync.RWMutex 性能对比

2. 减小临界区

3. 分段锁

4. sync.Map vs map+Mutex

5. atomic vs Mutex

六、false sharing 问题

七、完整示例：并发数据处理优化

1. 串行版

2. 朴素并发版（用 Mutex 累加，有锁竞争）

3. 优化版（局部累加 + 无锁合并，避免 false sharing）

4. 对比结果

八、小结