Go程序突然被系统OOM Killer干掉怎么办
绝大多数Go服务被杀，不是因为代码里有内存泄漏，而是进程总内存超了系统限制，被Linux的OOM Killer盯上。这时候dmesg -T | grep -i "killed process"会明确告诉你哪个进程被杀了、当时用了多少内存。
关键判断：先看是不是真的内存用超了，而不是GC没跑——Go的runtime.ReadMemStats显示的Alloc或HeapInuse可能才几百MB，但process RSS（比如ps -o pid,rss,comm -p $PID）已经几个GB。这说明内存没被OS回收，常见于大量mmap、cgo调用、或GC未触发导致堆外内存堆积。
- 检查是否启用了
GODEBUG=madvdontneed=1（Go 1.19+默认），它让Go在释放内存时用MADV_DONTNEED而非MADV_FREE，更积极归还物理内存 - 如果用了
cgo，确认C侧分配的内存是否被正确free；CGO_ENABLED=0编译可快速排除干扰 - 避免长期持有大对象指针（比如把
[]byte塞进全局map），它会阻止整个底层数组被回收
怎么安全地给Go进程设内存上限
Go本身不提供硬内存限额，靠GOMEMLIMIT（Go 1.19+）是软目标，只影响GC触发时机，不阻止RSS上涨。真要限死，得靠OS层：
- 容器场景：用
docker run --memory=2g或K8s的resources.limits.memory，配合GOMEMLIMIT=1.5g（建议设为limit的75%）让GC提前介入 - 裸机部署：用
systemd的MemoryMax+MemoryLow，比ulimit -v更可靠（后者对mmap无效） - 别信
GOGC=10能救命——它只会让GC更频繁，但若对象存活率高，反而加剧停顿和元数据开销
示例：GOMEMLIMIT=1600MiB ./myserver会让GC在堆内存接近1.6GB时启动，但若cgo开了1GB的共享内存，RSS照样爆到2.6GB被OOM Killer干掉。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
立即学习“go语言免费学习笔记（深入）”；
pprof抓不到内存问题？试试这些冷门指标
只看pprof heap --inuse_space容易漏掉真正的凶手。很多OOM现场，inuse_space不高，但alloc_objects飙升，或者heap_sys - heap_inuse差值巨大（说明内存被分配但未被Go管理）。
- 必查
runtime.MemStats.Sys和runtime.MemStats.HeapSys差值：超过500MB就说明有大量堆外内存（如unsafe.Alloc、mmap、cgo） - 用
go tool pprof -http=:8080 http://localhost:6060/debug/pprof/heap?debug=1打开后点“View” → “Proto”，搜extra_memory_usage字段（Go 1.21+新增） - 如果
goroutine数稳定但heap_objects持续涨，大概率是缓存没设淘汰策略，或sync.PoolPut错对象（比如Put了带指针的大结构体）
GC调优不是调GOGC，而是管住三类对象
降低GOGC值对高吞吐服务通常是负优化。真正该盯的是三类易失控对象：
-
短期大对象：>32KB直接进堆，避开逃逸分析，但GC扫描成本高；改用
sync.Pool复用，注意Pool的New函数不能返回带长生命周期引用的对象 -
长生命周期小对象：比如HTTP handler里闭包捕获了整个request context；用
context.WithValue传必要字段，而非整个struct -
间接引用链：一个
*bytes.Buffer被存在map里，buffer底层[]byte又引用了另一个大slice——这种链式持有会让整条链无法回收；用buf.Reset()清空内容，再buf = nil切断引用
最常被忽略的一点：Go的GC不会回收正在被finalizer等待的对象，哪怕你已显式runtime.SetFinalizer(x, nil)，finalizer队列处理有延迟。线上禁用finalizer，或确保其逻辑毫秒级完成。
