GOMAXPROCS设过高反而更慢，因容器中runtime.NumCPU()返回宿主机核数而非实际vCPU配额，导致P过多争抢有限CPU资源，加剧调度开销、netpoller延迟和goroutine阻塞；I/O密集型服务建议设为vCPU配额值或其2倍（≤16），过小则netpoller轮询不及时，过大引发P锁竞争与work stealing失效。
高负载下goroutine不是越多越好，调度器反而会因P竞争、M阻塞和队列失衡拖慢整体吞吐。
为什么GOMAXPROCS设太高反而更慢
默认runtime.GOMAXPROCS(0)返回的是宿主机CPU核心数，但在Docker或K8s里它不反映你实际能用的CPU配额。设成32却只分配了2核，会导致P过多、全局队列争抢加剧、netpoller响应延迟升高——表现就是HTTP请求偶发超时、连接堆积。
- 容器中必须显式设置：
runtime.GOMAXPROCS(2)（对应--cpus=2） - I/O密集型服务可放宽到
*2（如4），但超过16基本无收益，且P锁竞争上升 - 过小（如
1）会让netpoller无法及时轮询就绪fd，尤其在高并发长连接场景下
goroutine堆积的真正元凶：阻塞系统调用
大量goroutine卡在read、write、accept或cgo调用上时，M会被挂起，而P需要等待新M接管——此时若M已达上限（默认10000），新goroutine只能排队等P空闲，造成“看起来没干活但CPU打满”的假象。
- 查当前线程数：
cat /proc/<pid>/status | grep Threads，持续高于50+要警惕 - 避免在goroutine里直接调用阻塞式C函数；改用非阻塞IO或多路复用（如
net.Conn.SetReadDeadline） - HTTP客户端必须带超时：
&http.Client{Timeout: 5 * time.Second}，否则一个慢后端就能拖垮整组worker
别盲目启goroutine：http.HandlerFunc已是goroutine
net/http服务器对每个请求已自动启动一个goroutine。再在handler里写go func() { ... }()，只是徒增调度登记开销和栈内存（每个初始2KB），尤其当闭包捕获*http.Request这类大对象时，栈无法收缩，内存常驻。
立即学习“go语言免费学习笔记（深入）”；
- 真要异步处理后台任务（如日志上报、埋点），用固定size的worker pool，比如
semaphore.NewWeighted(5)或带缓冲channel - 闭包捕获循环变量必须传参：
for _, u := range users { go func(user User) { log.Println(user.Name) }(u) } - 高频短命goroutine（如每请求启10个）比业务逻辑本身更耗资源：创建+GC元信息+调度队列登记，合计开销远超2KB栈
work stealing失效时的信号与对策
当某个P本地队列长期为空，而其他P队列积压严重，说明work stealing没生效——常见于P数量过多、任务分布不均，或大量goroutine集中在少数几个P上执行长时间CPU计算。
- 典型现象：
go tool trace里看到大量G在“Runnable”状态但迟迟不进入“Running”，或runtime.ReadMemStats显示NumGoroutine持续上涨不回落 - 对策：用
sync.Pool复用频繁分配的小对象（如[]byte），减少GC压力导致的调度停顿 - CPU密集型任务中主动让出：
runtime.Gosched()，避免被抢占机制强制中断带来的上下文切换开销
最易被忽略的一点：goroutine泄漏往往不是代码漏了close或return，而是channel未消费完、timer未Stop、或context未正确传递取消信号——这些都会让G永远卡在select或recv上，静默吃掉P和M资源。
