GOMAXPROCS 默认读宿主机CPU数而非容器配额，导致P数量远超cgroup允许的CPU时间，引发频繁调度抖动和GC延迟；应优先通过cgroup自动计算并设置，而非硬编码或依赖环境变量。
为什么容器里 CPU 忽高忽低，GOMAXPROCS 是罪魁祸首？
Go 进程在容器里跑着跑着 CPU 使用率就抖动飙升、延迟拉长，甚至 GC 暂停时间翻倍——大概率不是代码写得烂，而是 GOMAXPROCS 还在傻乎乎地读宿主机的 32 核，而你的 Pod 只被分了 limits.cpu: "500m"（即半核）。运行时开了 32 个 P，但 cgroup 每 100ms 只给 50ms 时间片，结果所有 P 抢这半核，上下文切换爆炸。
- 现象：
cat /proc/cpuinfo | grep processor | wc -l返回 32，但cat /sys/fs/cgroup/cpu/cpu.cfs_quota_us是 50000、cpu.cfs_period_us是 100000 → 实际配额 = 0.5 核 -
runtime.NumCPU()返回的是 cgroup 允许的逻辑 CPU 数（v2）或宿主机数（v1），不可靠；默认GOMAXPROCS就是它 - Go 1.15+ 支持
GOMAXPROCS=0自动适配 cgroup v2 的cpu.max，但 v1 下仍无效 —— 大部分 K8s 集群还在用 v1 - 别信“Docker 的
--cpus=2会自动设好GOMAXPROCS”，它不会。Go 运行时根本不读这个参数
怎么安全地设置 GOMAXPROCS？优先级和实操顺序
不能硬编码，也不能全靠环境变量；得按「cgroup 检测 → 环境变量兜底 → 启动时覆盖」三层来落地。
- 启动前第一件事：在
main()最开头调用runtime.GOMAXPROCS(n)，n 要从 cgroup 计算而来（不是os.Getenv("GOMAXPROCS")） - v2 环境读
/sys/fs/cgroup/cpu.max（格式如50000 100000），v1 读/sys/fs/cgroup/cpu/cpu.cfs_quota_us和cpu.cfs_period_us，算出floor(quota / period) - 推荐直接用
github.com/uber-go/automaxprocs：一行automaxprocs.Set()就搞定检测 + 设置 + 日志，它连 v1/v2 自动 fallback 都做了 - 如果必须用环境变量，只在 CI/CD 或 K8s Downward API 注入时设
GOMAXPROCS=2，且确保它不被代码里其他runtime.GOMAXPROCS()覆盖
GOMAXPROCS 设太大 or 太小，分别会怎样？
不是“越大越好”也不是“越小越省”，得看 workload 类型和容器配额是否对齐。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 设太大（比如配额 1 核却设成 8）：P 过多 → M 频繁创建销毁 → 上下文切换暴涨 →
context_switches_total指标飙升 3–4 倍，CPU throttling 频发 - 设太小（比如配额 4 核却设成 1）：单个 P 跑满，其他核空转 → 并发吞吐上不去，HTTP QPS 卡在瓶颈，尤其压测时明显
- CPU 密集型服务（如计算、编解码）：建议
GOMAXPROCS == 容器 CPU 配额向上取整（500m → 1，1500m → 2） - I/O 密集型服务（如 HTTP API、DB Proxy）：可略高于配额（如配额 2 → 设 3~4），因为 goroutine 经常让出 P 等 syscall，适当冗余能提升利用率
K8s 里最容易被忽略的两个坑
配置写了 resources.limits.cpu: "2"，但 Pod 还是抖，问题往往藏在细节里。
立即学习“go语言免费学习笔记（深入）”；
- K8s 默认用 cgroup v1，
cpu.cfs_quota_us在低配额（如100m）下精度差，实际调度抖动比 v2 大得多；升级到 cgroup v2 是根治法，但短期可用cpu-quota-aware的 initContainer 预热或限流降级 - 没关
swap：Docker 默认--memory-swap=2g（当--memory=1g），Go 的匿名内存页被 swap 后，GC 扫描变慢、延迟毛刺明显；务必加--memory-swap=1g或--memory-swappiness=0 - 别只盯着
limits，requests决定调度位置；若requests.cpu远低于limits.cpu，K8s 可能把 Pod 调度到已满载节点，实际可用 CPU 更少
cgroup v1 的 quota 解析、v2 的 max 解析、Downward API 注入时机、automaxprocs 的 panic 处理边界……这些都不是“设个环境变量就完事”的事。真正在意延迟和稳定性，就得把 GOMAXPROCS 当作和 http.Server.ReadTimeout 一样严肃对待的启动参数。
