根本原因是容器cgroups限制CPU配额，Go调度器只能在分配的配额内工作；GOMAXPROCS应设为quota/period向下取整，runtime.NumCPU()返回宿主机核数不感知容器限制，CFS throttling会导致CPU毛刺和响应延迟。
Go应用在容器里CPU跑不满，GOMAXPROCS设再大也没用？
根本原因不是Go没调度能力，而是容器运行时（比如Docker）通过cgroups限制了CPU可用时间，Go的调度器只能在分配到的配额内工作。即使你把GOMAXPROCS设成64，但容器只被分配了0.5个CPU核（即cpu.quota = 50000, cpu.period = 100000），那Go最多也就跑出0.5核的吞吐。
实操建议：
- 先确认容器真实CPU配额：
cat /sys/fs/cgroup/cpu,cpuacct/cpu.cfs_quota_us和/sys/fs/cgroup/cpu,cpuacct/cpu.cfs_period_us，算出实际核数上限（quota/period） -
GOMAXPROCS建议设为该值向下取整（比如配额是1.8核，就设GOMAXPROCS=1；2.9核可设2），避免goroutine频繁抢占却抢不到时间片 - 别依赖
GOMAXPROCS=0自动探测——它读的是宿主机CPU数，不是容器可见核数
为什么docker run --cpus=2后，runtime.NumCPU()还是显示48？
runtime.NumCPU()返回的是宿主机的逻辑CPU总数，它不感知cgroups限制。这是Go故意设计的：底层调用sysconf(_SC_NPROCESSORS_ONLN)查的是系统级信息，和容器隔离无关。
这意味着：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 所有基于
NumCPU()做并发度决策的代码（比如启动worker数量）都会误判，可能起太多goroutine导致上下文切换开销飙升 - 正确做法是优先读cgroups接口：检查
/sys/fs/cgroup/cpu/cpu.cfs_quota_us是否存在且>0，再结合cpu.cfs_period_us推算可用核数 - 生产环境建议封装一个
GetAvailableCPU()函数，fallback到NumCPU()仅用于非容器场景
GOMAXPROCS动态调整能解决突发负载吗？
能，但有延迟和副作用。调用runtime.GOMAXPROCS(n)会触发全局stop-the-world短暂暂停（毫秒级），并重排P（Processor）队列。它不是“立刻多出n个并行单位”，而是让调度器后续按新P数分发G。
注意这些坑：
- 如果容器配额已满（比如cfs_quota_us == cfs_period_us），调高
GOMAXPROCS只会加剧goroutine排队，不提升实际吞吐 - 频繁调用（如每秒改一次）会导致调度抖动，反而降低稳定性
- 推荐只在启动时设一次，或在明确检测到CPU配额变更（如K8s中
resources.limits.cpu更新）后谨慎调整
Go服务在K8s里CPU usage曲线毛刺大，和CFS throttling有关？
非常可能。当容器进程用满配额后，CFS会强制throttle——表现为/sys/fs/cgroup/cpu/cpu.stat里nr_throttled持续增长，同时throttled_time上升。此时Go程序看似“卡顿”，其实是被cgroups挂起了。
排查和缓解方法：
- 进容器执行：
cat /sys/fs/cgroup/cpu/cpu.stat | grep throttled，若throttled_time> 0且随时间增长，基本确定是CFS限制造成 - 临时缓解：提高
cpu.limits（但别盲目加，要结合实际压测）；更优解是优化Go代码，减少非必要goroutine和锁竞争 - 监控建议：把
container_cpu_cfs_throttled_periods_total（cAdvisor指标）加入告警，比看CPU usage百分比更能反映真实瓶颈
真正难处理的是那种“配额刚好够平均负载、但扛不住短时尖峰”的情况——CFS throttle一触发，Go的timer和network poller响应都会变慢，这时候光调GOMAXPROCS没用，得从请求模型和限流策略入手。
