go 的 select 不保证公平性，因伪随机遍历和持续就绪 channel 导致某些 case 长期饿死；解决方法是用轮询封装替代直接 select，通过独立 goroutine + 调度器实现主动公平。

Go 的 select 本身不保证公平性，多个就绪的 case 可能被反复选中，而其他 case 长期得不到执行——这不是 bug，是设计使然。解决饥饿，关键不是“让 select 变公平”，而是重构调度逻辑，避开对 select 均匀性的依赖。

为什么 select 会饿死某些 case？

Go 运行时在 select 中遍历 case 时采用伪随机顺序（实际是轮询索引 + 随机偏移），但一旦某个 channel 持续就绪（比如缓冲通道未清空、或写端不断发数据），它就大概率每次都被选中。没有“老化计数”或“上次执行时间”机制，也没有优先级权重。

• 常见错误现象：select 里混用无缓冲通道和带缓冲通道，后者几乎永远胜出
• 使用场景：消息分发器、多路健康检查、混合读写操作的代理层
• 性能影响：看似吞吐高，实则部分业务路径延迟飙升，监控上表现为 P99 毛刺持续存在

用缓冲通道 + 轮询代替纯 select

把“谁先就绪谁上”改成“轮流点名”，主动控制公平性。核心是把每个通道封装成独立 goroutine + 缓冲队列，再由一个调度 goroutine 定期轮询它们。

使用Go语言搭建家庭相册系统-相关课件

使用Go语言搭建家庭相册系统-相关课件

下载

• 不要直接在 select 中监听原始 channel，而是监听每个封装后的 chan struct{} 通知信号
• 每个封装 goroutine 负责从真实 channel 收/发一次，然后发信号给调度器：“我处理完了，轮到别人了”
• 示例片段：

  for range []int{0, 1, 2} { // 固定顺序轮询
      select {
      case msg := 

加权轮询与 context 超时兜底

纯轮询太机械；真实业务中，有些通道确实该多分资源（如用户请求通道），有些可降级（如日志上报）。这时需要加权，且必须配超时——否则某个慢通道卡住，整个轮询就阻塞。

• 权重不写死在代码里，建议用配置驱动，例如：weightMap = map[string]int{"user": 3, "metrics": 1, "debug": 0}
• 每个 channel 操作必须带 context.WithTimeout(ctx, 100*time.Millisecond)，防止单次阻塞拖垮整轮
• 容易踩的坑：忘记重置 timer、在 for-select 循环里重复创建 context、超时后没清空 channel 缓冲区导致后续误触发

goroutine 泄漏比饥饿更隐蔽

很多所谓“饥饿”，其实是 goroutine 卡死没退出，导致新任务进不来。尤其当用 select + default 做非阻塞尝试时，若没配合 context.Done() 检查，就会无限空转。

• 典型泄漏模式：

  go func() {
      for {
          select {
          case 

• 正确做法：所有长期运行的 goroutine 必须监听 ctx.Done()，哪怕只是做 case
• 调试时优先跑 go tool trace 看 Goroutine 数量趋势，再查 pprof/goroutine stack，别一上来就调 select 逻辑