go程序在容器中cpu跑不满是预期行为，因其默认gomaxprocs设为宿主机cpu总数而非--cpus限制值，导致p数远超实际配额，引发调度争抢与cfs throttling；须主动读cgroup（v1/v2）计算quota/period并调用runtime.gomaxprocs设整数上限。
Go 程序在容器里跑不满 --cpus 限制，不是 bug 是预期行为
Go 运行时默认会把 GOMAXPROCS 设为宿主机逻辑 CPU 总数，而不是容器的 --cpus 限制值。结果就是：你用 docker run --cpus=1.5 启动容器，Go 却可能启动 8 个 P（processor），导致调度争抢、线程阻塞、GC 停顿变长，实际 CPU 使用反而被内核反复掐断。
根本原因在于 Go 1.13 之前不读 cgroup 信息；即使现在默认启用了 +UseContainerSupport（Java 那套机制），Go 本身仍不自动适配 CPU 配额——它只看 /proc/cpuinfo，而 Docker 不改这个文件。
- 验证方式：进容器执行
go env GOMAXPROCS，再对比cat /sys/fs/cgroup/cpu.max（cgroup v2）或cat /sys/fs/cgroup/cpu/cpu.cfs_quota_us（v1） - 典型现象：
docker stats显示 CPU% 接近 150%，但 Go 应用吞吐没提升，pprof 显示大量 goroutine 在runtime.mcall或semacquire上等待 - 必须手动设
GOMAXPROCS，且推荐设为整数（如--cpus=1.5→GOMAXPROCS=1），避免小数引发调度抖动
如何让 GOMAXPROCS 自动匹配 --cpus
不能靠环境变量硬编码，得从 cgroup 读配额再算——因为 --cpus=1.5 在 cgroup v2 下是 250000 100000（quota/period），需做除法；v1 下是 cpu.cfs_quota_us 和 cpu.cfs_period_us 两个文件。
推荐在 main() 开头加一段初始化逻辑：
func initCPULimit() {
quota, period := readCgroupCPU()
if quota > 0 && period > 0 && quota != -1 {
limit := int64(quota) / int64(period)
if limit > 0 {
runtime.GOMAXPROCS(int(limit))
}
}
}
其中 readCgroupCPU() 需兼容 v1/v2：
– v2 路径：/sys/fs/cgroup/cpu.max，格式如 "250000 100000"
– v1 路径：/sys/fs/cgroup/cpu/cpu.cfs_quota_us 和 /sys/fs/cgroup/cpu/cpu.cfs_period_us
- 注意：Docker 20.10+ 默认启用 cgroup v2，但部分 CentOS/RHEL 仍默认 v1，必须都覆盖
- 别用
os.Getenv("GOMAXPROCS")fallback，它不可靠——Docker 不透传该变量，且用户可能误设 - 不要在
init()外部调用runtime.GOMAXPROCS，否则可能被 runtime 初始化覆盖
为什么 --cpu-shares 对 Go 应用几乎无效
--cpu-shares 是 CFS 权重，只在 CPU 竞争时起作用；而 Go 的抢占式调度会让 goroutine 主动让出时间片，导致权重策略“失焦”。实测中，两个 Go 容器分别设 --cpu-shares=512 和 2048，在空闲主机上 CPU% 完全一致；只有当宿主机整体 CPU 利用率 >90% 时，比例才略接近 1:4。
- 真正影响 Go 表现的是硬配额：
--cpus或--cpuset-cpus - 若需 NUMA 亲和性（比如绑核降低 cache miss），优先用
--cpuset-cpus="0-1"+GOMAXPROCS=2，比--cpu-shares稳定得多 - Swarm/K8s 场景下，
--cpu-shares会被平台资源模型覆盖，直接忽略
Go HTTP 服务在低 --cpus 下响应延迟突增的排查点
当设 --cpus=0.5 后，HTTP 接口 P99 延迟翻倍，但 docker stats 显示 CPU% 常驻 45%～50%，说明不是 CPU 不够，而是调度卡点。
- 检查是否启用了
http.Server.ReadTimeout/WriteTimeout：超时未设会导致连接堆积，goroutine 卡在 syscall - 确认没有阻塞式系统调用（如
time.Sleep、同步文件读写），它们不触发 Go 调度器让出，会拖垮整个 P - 用
go tool trace抓取 trace，重点看Proc Status是否频繁切换、Network I/O是否有长阻塞 - 若用
net/http默认 transport，注意MaxIdleConnsPerHost默认 2，高并发下会排队，和 CPU 无关但表现类似
cgroup CPU 配额生效很快，但 Go 运行时感知滞后；最易被忽略的是：你设了 --cpus=1.2，却忘了 GOMAXPROCS 还是 8 —— 此时内核在掐进程，而 Go 在瞎调度。
