go调度器通过work-stealing实现负载均衡：当p本地队列为空且全局队列、netpoll均无任务时，按伪随机顺序最多尝试4轮窃取，每次从目标p队列尾部偷取一半（≤256个）g，依赖原子操作保障无锁安全。
Go 本身不提供协程池级的负载均衡算法，所谓“协程池负载均衡”本质是任务分发策略 + 工作窃取（work-stealing）或加权调度逻辑，不是语言特性，得自己编码控制。
为什么不能直接用 runtime.GOMAXPROCS 或 sync.Pool 实现负载均衡
很多人误以为调大 GOMAXPROCS 就能“自动均衡”，其实它只控制 OS 线程数上限，不干预 goroutine 调度顺序；sync.Pool 是对象复用工具，和任务分发完全无关。真实瓶颈常在：任务队列阻塞、worker 空闲但队列有积压、CPU 密集型任务饿死 I/O 型 worker。
- goroutine 调度器不感知任务耗时，长任务会卡住整个 P 的本地运行队列
- 所有 worker 共享一个无界
chan时，写入竞争激烈，len(chan)不可靠，无法反映真实积压 - 用
select非阻塞读取多个任务 channel 容易漏任务，尤其在高吞吐下
work-stealing 在 Go 中的实际落地难点
标准库没内置 work-stealing 支持，必须手动为每个 worker 维护私有队列，并暴露“偷任务”接口。关键点不在算法本身，而在避免锁争用和虚假唤醒。
- 每个 worker 用
chan做本地队列，但长度要设小（如 64），否则偷取时遍历太慢 - 偷任务不能直接从其他 worker 的
chan读——Go channel 不支持 peek 或批量 drain - 推荐改用
sync.Pool+slice模拟双端队列，偷取时用atomic.LoadUint64检查对方队列长度，再通过sync.Mutex临界区移动尾部 1–2 个任务 - 别在偷取失败时立即 sleep，应退避后重试，否则低负载下大量空转
加权轮询分发任务时，weight 字段该存什么
权重不是静态配置值，必须动态反馈运行时状态。硬编码 CPU 核心数或内存大小，在容器化环境里毫无意义。
- 可用指标：worker 最近 10 秒平均处理延迟（
time.Since(start)）、当前本地队列长度、GC pause 时间占比 - 更新频率不宜过高（如每 500ms 更新一次），避免抖动；也不宜过低（如 30s），否则跟不上突发流量
- 权重归一化很重要：直接用 raw 延迟值做除法会导致数值溢出，建议用滑动窗口计算倒数均值，再线性映射到 1–10 区间
- 示例逻辑：
func (w *Worker) updateWeight() { w.mu.Lock() defer w.mu.Unlock() if w.latencyWindow.Len() == 0 { w.weight = 5 // default return } avgLatency := w.latencyWindow.Avg() w.weight = int(10.0 / (1.0 + avgLatency.Seconds())) // capped at 1–10 }
关闭协程池时，context.WithTimeout 为什么必须传给每个 worker
不传 context，worker 可能在处理最后一个任务时卡死（比如下游 HTTP 调用超时未设），导致 WaitGroup 永不返回，整个 shutdown hang 住。
- 每个 worker 启动时接收
ctx context.Context，并在循环内检查ctx.Err() != nil - 任务 channel 读取必须用
select { case job := ，不能只靠 <code>close(jobs) - 如果任务本身含子 goroutine（如启动定时器、发起异步回调），需额外用
ctx控制其生命周期，否则仍会泄漏 - 别在 worker 里用
http.DefaultClient，它不响应 context 取消；必须用&http.Client{Timeout: 3*time.Second}或封装带 cancel 的 transport
真正难的不是实现某个算法，而是让权重可观察、任务积压可量化、worker 状态可诊断。线上出问题时，没人关心你用了轮询还是最小连接，只看你能不能快速回答：“哪个 worker 队列最长？延迟突增是从哪条 trace 开始的？”
