Go服务无内置CPU/内存硬限，需依赖cgroups等外部机制；Docker中应设--cpus和--memory并禁用GOMAXPROCS环境变量，K8s需注意cgroup v1精度问题及大页影响。
Go 服务本身不支持内置 CPU/内存限制
Go 运行时没有提供类似 ulimit 或容器级的资源硬限能力。你调用 runtime.GOMAXPROCS 只能控制 P 的数量（影响并发调度粒度），debug.SetMemoryLimit（Go 1.19+）仅用于触发 GC，**不是内存上限**——进程仍可突破该值并被 OS OOM kill。
真正生效的资源限制必须由外部机制实现：
- 容器环境（Docker / Kubernetes）通过 cgroups 设置
--cpus、--memory等参数 - 宿主机用
systemd的MemoryMax、CPUQuota - 手动启动时套一层
ulimit -v / -s / -n（效果有限，且不控堆外内存）
Docker 中限制 Go 服务 CPU 和内存的正确写法
Docker 是最常用场景。注意：Go 程序会读取 cgroup 限制并自动适配 GOMAXPROCS（Go 1.14+），但**必须显式启用**：
docker run \ --cpus="2.5" \ --memory="2g" \ --memory-swap="2g" \ -e GODEBUG=schedtrace=1000 \ my-go-app
关键点：
立即学习“go语言免费学习笔记（深入）”；
-
--cpus="2.5"表示最多使用 2.5 个逻辑 CPU 时间片，Go 运行时会设GOMAXPROCS=2（向下取整） -
--memory限制 RSS + page cache，超限触发 cgroup OOM；--memory-swap设为同值表示禁用 swap - 务必避免同时设
GOMAXPROCS环境变量——它会覆盖 cgroup 自动推导，导致 CPU 调度失准
Kubernetes 中配置 resources 导致 Go 服务异常的常见原因
YAML 中写了 resources.limits.memory 却发现 Pod 频繁 OOMKilled？大概率是 Go 程序触发了 **cgroup v1 的 memory limit 不精确问题** 或未适配大页：
- Go 默认使用 mmap 分配大块内存（如
sync.Pool缓存对象），这部分可能绕过 Go heap 统计，但仍在 cgroup 内——OS 层面已超限 - K8s 默认用 cgroup v1；升级到 v2 后，
memory.max更严格，建议在Container中加注解：container.apparmor.security.beta.kubernetes.io/app: runtime/default - 若用
debug.SetMemoryLimit，需配合debug.SetGCPercent(-1)手动触发 GC，否则无实际限流效果
如何验证 Go 进程是否真的受控于 cgroup 限制
进入容器或 Pod，检查运行时是否识别到约束：
cat /sys/fs/cgroup/memory.max cat /sys/fs/cgroup/cpu.max go run -gcflags="-m" main.go | grep "GOMAXPROCS"
更直接的方式是在代码中打印：
package main
<p>import (
"fmt"
"runtime"
)</p><p>func main() {
fmt.Printf("GOMAXPROCS: %d\n", runtime.GOMAXPROCS(0))
fmt.Printf("NumCPU: %d\n", runtime.NumCPU())
}如果 GOMAXPROCS 值等于 docker --cpus 向下取整结果（如 --cpus=1.2 → 1），说明识别成功；若始终等于宿主机 CPU 数，则 cgroup 未生效或被 GOMAXPROCS 环境变量覆盖。
内存方面，runtime.ReadMemStats 的 Sys 字段接近 /sys/fs/cgroup/memory.max 值时，说明限制正在起作用——但要注意 Sys 包含了堆外内存，不能只看 Alloc。
