Go程序无法自行限制CPU和内存配额，必须依赖Docker/Kubernetes等外部环境通过cgroups强制实施；runtime.GOMAXPROCS和GOGC仅影响调度与GC，不提供容器级资源限制。
Go 程序自身无法直接限制 CPU 和内存配额
Go 运行时没有内置的、类似 cgroups 的资源隔离机制。你调用 runtime.GOMAXPROCS 或设置 GOGC，只影响调度和 GC 行为，**不构成容器级资源限制**。真正生效的 CPU / 内存上限，必须由外部运行环境（如 Docker、Kubernetes）通过 cgroups v1/v2 强制施加。Go 程序感知到的是宿主机或容器的“虚拟视图”，比如 runtime.NumCPU() 返回的是容器 cpuset.cpus 允许的逻辑核数，而非物理机总数。
Docker run 时必须显式传入 --cpus 和 --memory
不加参数等于不限制，Go 进程可能吃满节点资源。常见错误是只设 --cpus=2 却忽略 --memory，导致 OOM 被 kernel kill —— 此时你看到的不是 Go panic，而是进程被 signal 9 终止，dmesg -T | grep -i "killed process" 才能看到真实原因。
-
--cpus=1.5：等价于--cpu-period=100000 --cpu-quota=150000，适用于突发型负载 -
--cpuset-cpus="0-1"：绑定到特定 CPU 核，避免跨核缓存失效，适合低延迟场景 -
--memory=512m：硬限制，超过立即 OOM kill；--memory-reservation=256m是软限制，仅在内存紧张时起作用 - 务必搭配
--memory-swap=512m（禁用 swap）或明确设为-1（允许无限 swap），否则默认swap=memory*2可能掩盖真实内存压力
Go 应用内需适配容器环境做主动降级
单纯依赖 cgroups 被动限流不够稳健。当容器内存逼近 --memory 上限时，Go 的 runtime.ReadMemStats 仍可能读到较低的 Alloc 值（因未触发 GC），但 sys 已接近上限。此时应结合 /sys/fs/cgroup/memory/memory.usage_in_bytes（cgroup v1）或 /sys/fs/cgroup/memory.current（v2）做主动判断。
func getContainerMemoryUsage() uint64 {
// 优先读 cgroup v2
if data, err := os.ReadFile("/sys/fs/cgroup/memory.current"); err == nil {
if n, err := strconv.ParseUint(strings.TrimSpace(string(data)), 10, 64); err == nil {
return n
}
}
// fallback to v1
if data, err := os.ReadFile("/sys/fs/cgroup/memory/memory.usage_in_bytes"); err == nil {
if n, err := strconv.ParseUint(strings.TrimSpace(string(data)), 10, 64); err == nil {
return n
}
}
return 0
}
拿到值后，对比 /sys/fs/cgroup/memory/memory.limit_in_bytes（v1）或 /sys/fs/cgroup/memory.max（v2），若使用率 > 85%，可触发日志采样降频、关闭非核心 goroutine、拒绝新连接等策略。
避免在 Go 中误用 runtime.GOMAXPROCS 干预 CPU 限制
有人试图用 runtime.GOMAXPROCS(2) 模拟 --cpus=2，这是危险的。GOMAXPROCS 控制的是 OS 线程并发数，不是 CPU 时间配额。在 --cpus=0.5 的容器里，GOMAXPROCS=2 会导致大量线程争抢 0.5 核时间片，上下文切换暴涨，反而降低吞吐。正确做法是让 GOMAXPROCS 自动适配：
func init() {
if n, err := strconv.Atoi(os.Getenv("GOMAXPROCS")); err == nil {
runtime.GOMAXPROCS(n)
} else {
// 让 runtime 自动读取 cgroups 信息（Go 1.19+ 默认启用）
// 不需要手动 set，除非有特殊调度需求
}
}
Go 1.19 起默认开启 runtime/internal/syscall 对 cgroups 的自动探测，runtime.NumCPU() 和默认 GOMAXPROCS 均已反映容器 CPU 配额。强行覆盖反而破坏这一机制。
最易被忽略的一点：Docker 默认使用 cgroups v1，而较新内核（如 Ubuntu 22.04+）可能默认启用了 cgroups v2。若你的监控脚本硬编码读取 /sys/fs/cgroup/memory/memory.usage_in_bytes，在 v2 环境下会失败且静默返回 0——这会让内存预警完全失效。
