容器中 runtime.gomaxprocs 默认取宿主机 cpu 数而非容器限制值，导致 p 过多、抢占加剧、上下文切换飙升；应显式设为容器 cpu 限额或通过 cgroup 自动推算。
为什么 runtime.GOMAXPROCS 不等于 CPU 核心数就容易出问题
容器环境下，Go 程序默认通过 runtime.GOMAXPROCS 控制并行 P 的数量，而它在 Go 1.5+ 默认设为 NumCPU() —— 即宿主机的逻辑 CPU 数，不是容器 --cpus 或 cpu.shares 限制值。这会导致：P 过多但实际可用 CPU 时间片不足，goroutine 频繁抢占、上下文切换飙升，execsystime 和 schedlatency 指标异常升高。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 启动时显式设置
GOMAXPROCS：比如容器限制为 2 核，用GOMAXPROCS=2 ./myapp - 更稳妥的方式是读取
/sys/fs/cgroup/cpu/cpu.cfs_quota_us和/sys/fs/cgroup/cpu/cpu.cfs_period_us自动推算（注意 Docker/K8s 中路径可能为/proc/1/cgroup+ 挂载点映射） - 避免在运行中反复调用
runtime.GOMAXPROCS，它会触发 STW，高并发服务慎用
容器内存超限前如何让 Go 主动触发 GC
Go 的 GC 触发基于堆增长比例（默认 GOGC=100），但容器有 memory.limit_in_bytes，等 RSS 接近 limit 再 GC 往往来不及 —— OOMKilled 直接杀进程，不会留给 Go 清理机会。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
debug.ReadMemStats定期采样MemStats.Alloc和MemStats.Sys，结合 cgroup 内存上限估算剩余可用空间 - 当
Alloc > 0.7 * cgroup_limit时，调用debug.FreeOSMemory()+runtime.GC()强制回收（注意：后者会 STW，需控制频次） - 上线前压测时，用
go tool trace观察 GC pause 是否集中在内存压力峰值段，验证策略有效性
pprof 在容器里采集不到完整调度和内存数据？检查这几个路径
容器默认挂载的 /proc 是隔离的，但 Go 的 pprof（尤其 /debug/pprof/sched、/debug/pprof/heap）依赖内核 procfs 接口。若容器未挂载 /proc 或权限受限（如 securityContext.privileged: false），部分 profile 会返回空或 404。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- Docker 启动加
--pid=host或显式挂载-v /proc:/proc:ro（K8s 对应volumeMounts+hostPath） - 确认容器内可读
/proc/self/stat和/proc/self/status——pprof调度分析依赖这些字段 - 避免用
net/http/pprof默认路由暴露全量 profile，生产环境只启用必要端点（如仅/debug/pprof/heap），并通过 sidecar 或kubectl port-forward访问
为什么 sync.Pool 在短生命周期容器里反而拖慢性能
sync.Pool 的设计假设是“对象复用能跨多次请求”，但在 Serverless 或批处理类容器中（如 K8s Job，运行几秒即退出），Pool 里的对象根本没机会被复用，却要承担清理开销（runtime.SetFinalizer + sweep 成本），且 Pool 本身占内存、GC 时还要扫描其内部结构。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 对生命周期 sync.Pool（设
sync.Pool{}不用，或编译期条件关闭） - 若必须用，配合
runtime/debug.SetGCPercent(-1)临时停 GC（仅限极短任务），避免 Pool 扫描干扰 - 用
go tool pprof --alloc_space对比启用/禁用 Pool 的分配总量和对象数，看是否真有复用收益
容器资源优化最易被忽略的，是把宿主机指标当容器指标用 —— NumCPU()、MemStats.Sys、/proc/meminfo 全部来自宿主机视角，不经过 cgroup 层抽象。所有资源判断逻辑，必须主动读取 cgroup 文件系统，而不是依赖 Go 运行时默认行为。
