17370845950

进阶关键在于“何时不该用”和“问题定位”：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)
      }
  }()

• 任务 channel 必须带超时或上下文：select { case jobs
• 结果收集推荐用 sync.WaitGroup + chan 组合，避免 for i := 0; i 因顺序依赖导致卡死
• 真正需要动态扩缩容？别手写，用 golang.org/x/sync/errgroup 或 semaphore 库更稳妥

真正的进阶，是从“写得出来”走向“压得住、停得稳、查得清”。runtime/pprof、go tool trace、go tool pprof -http 这三个命令，比任何文档都更能暴露你并发模型的真实缺陷。