gomemlimit不是硬内存限制，而是通过提前触发gc来软约束堆内存；它不影响mmap、cgo等非堆内存，rss仍可能超限被oomkilled。
Go 1.19+ 的 GOMEMLIMIT 是什么，它真能“限制内存”吗？
不能。它不强制限制进程 RSS，而是让 Go 运行时更早触发 GC，把堆目标（GC trigger）从“上次 GC 后分配量 × 2”改为“不超过 GOMEMLIMIT 减去估算的非堆开销”。本质是**用 GC 频率换内存上限的软约束**。
常见错误现象：GOMEMLIMIT=1G 后 RSS 仍飙到 1.4G；或 GC 突然变频繁、CPU 升高——说明运行时在拼命回收，但 OS 已经给了更多页，而 Go 暂未归还。
- 必须搭配
GOGC使用：若GOGC=off或设得极大，GOMEMLIMIT失效 - 值建议设为容器 memory limit 的 80%～90%，留出 runtime、stack、mmap、cgo 等非堆空间余量
- 单位支持
B/K/M/G，例如GOMEMLIMIT=2G，不接受小数或表达式
为什么设置了 GOMEMLIMIT，RSS 还是超限被 OOMKilled？
因为 Linux cgroup v1/v2 的 memory limit 是硬边界，而 Go 只管堆（heap），不管：mmap 分配的大块内存（如 bufio 底层 buffer、unsafe 手动申请）、全局变量、goroutine stack、CGO 调用的 C 堆内存。这些全算在 RSS 里，但 GOMEMLIMIT 对它们完全无感。
典型场景：服务用 net/http 处理大文件上传，底层 io.Copy 可能触发 mmap；或用了 sqlite、zstd 等 CGO 包，其 C 层 malloc 不受 Go GC 管控。
立即学习“go语言免费学习笔记（深入）”；
- 检查真实内存分布：用
go tool pprof http://localhost:6060/debug/pprof/heap看 heap；再用cat /sys/fs/cgroup/memory/memory.usage_in_bytes看实际 RSS -
GOMEMLIMIT无法替代 cgroup 配置——容器必须设memory.limit_in_bytes，否则没意义 - 若大量使用
unsafe或 mmap，请手动调用runtime/debug.FreeOSMemory()（慎用，有性能代价）
GOMEMLIMIT 和 GOGC 怎么配合才不翻车？
单独调低 GOGC 会让 GC 更勤，但可能因 STW 累积导致延迟毛刺；只设 GOMEMLIMIT 又可能 GC 太晚、OOM 在前。二者要协同压测。
推荐组合（以容器 limit=4G 为例）：
-
GOMEMLIMIT=3.2G（80%） +GOGC=50：适合读多写少、内存敏感型服务（如 API 网关） -
GOMEMLIMIT=2.8G（70%） +GOGC=30：适合写密集、需稳住 RSS 的场景（如日志聚合） - 避免
GOGC=10以下：GC 过于激进，goroutine 调度和分配器锁竞争会明显上升
注意：GOGC 是百分比，不是 MB；GOMEMLIMIT 是绝对上限，两者量纲不同，不能直接换算。
Go 1.18 及更早版本能不能用 GOMEMLIMIT？
不能。该环境变量是 Go 1.19 引入的，1.18 及之前版本读到会直接忽略，且无任何提示。升级前务必确认 Go 版本：
go version
若无法升级，替代方案只有：GOGC 调低 + 手动 debug.SetGCPercent + 容器侧严格 memory limit + 主动监控 /sys/fs/cgroup/memory/memory.usage_in_bytes 并触发优雅降级。
容易被忽略的一点：即使 Go 版本够新，Docker/K8s 若用的是老旧 containerd 或 runc，可能因 cgroup v1 兼容问题导致 memory.stat 解析不准，进而影响 GOMEMLIMIT 内部估算——建议生产环境统一用 cgroup v2。
