Golang并发编程如何进阶_Go语言高级并发路线_技术教程

进阶关键在于“何时不该用”和“问题定位”：goroutine泄漏因未关闭channel或缺退出机制；缓冲大小需权衡背压与性能；共享状态高频场景仍需锁或原子操作；Worker Pool须结合context与限流。

goroutine 和 channel 入门容易，但真正进阶的关键不在“会不会用”，而在“什么时候不该用”和“出问题时怎么定位”。

goroutine 泄漏：最隐蔽的内存杀手

现象：程序长期运行后 RSS 内存持续上涨，pprof 显示大量 goroutine 处于 chan receive 或 select 阻塞态，且数量不随任务结束而下降。

根本原因：未关闭的 channel + 无退出机制的循环 goroutine（比如 for range ch 永不退出）

典型错误写法：

go func() {
    for v := range ch { // ch 永不 close → goroutine 永不退出
        process(v)
    }
}()

修复方式：必须配对使用 context.Context 控制生命周期，或显式 close(ch) 后再 range
生产建议：所有长期运行的 goroutine 都应接受 ctx context.Context 参数，并在 select 中监听 ctx.Done()

channel 缓冲大小：不是越大越好，也不是越小越安全

缓冲通道不是“保险丝”，而是性能与可靠性的权衡点。

make(chan int, 0)（无缓冲）：强制同步，适合信号通知、屏障同步，但若收发端逻辑错位（如 sender 先发、receiver 没启），直接死锁
make(chan int, N)（有缓冲）：N 不是凭经验拍的——它应 ≈ 单位时间内峰值写入量 × 最大容忍延迟（单位：消息数）。例如每秒 100 条日志，允许最多积压 2 秒，则 cap=200
过大的缓冲（如 10000）会掩盖背压问题，让下游崩溃前先吃光内存；过小则频繁阻塞，吞吐骤降
实测提示：用 runtime.ReadMemStats 对比不同 cap 下的 Mallocs 和 PauseNs，比理论推导更可靠

共享状态：别迷信 “通过通信共享内存”，该加锁还得加

Go 的信条 “Do not communicate by sharing memory; instead, share memory by communicating” 是指导原则，不是教条。真实业务里，高频读+低频写、聚合统计、配置热更新等场景，channel 反而成为瓶颈。

高频计数器：用 sync/atomic 比走 channel 快 40 倍以上，且无调度开销
```
var counter int64
atomic.AddInt64(&counter, 1) // 安全、无锁、单指令
```
读多写少配置：优先用 sync.RWMutex，而非为每次读都塞一个 channel 请求
切忌把 channel 当“万能胶水”：比如用 chan struct{} 实现简单开关，远不如 atomic.Bool 或 sync.Once 直观高效

Worker Pool 模式：控制并发度 ≠ 简单限制 goroutine 数量

只用 for i := 0; i 是伪控制——它没解决任务分发公平性、panic 恢复、结果收集超时、worker 异常退出等问题。

必须带 recover：否则一个 panic 会让整个 pool 崩溃

go func() {
    defer func() {
        if r := recover(); r != nil {
            log.Printf("worker panic: %v", r)
        }
    }()
    for job := range jobs {
        handle(job)
    }
}()