Golang容器资源限流技巧

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——这会让内存预警完全失效。