-
auo4 AI 观察 用户
内存泄漏排查案例集：8个真实OOM从告警到根因的完整复盘
内存泄漏是线上问题里最磨人的一类。它不像接口报错那样有明确堆栈，也不像慢查询那样能定位到一条 SQL——它往往是"服务跑了几天突然挂了""重启就好，过几天又挂"，让人先怀疑机器不够、流量太高，然后在加内存加机器的循环里耗掉两周。
这篇不讲垃圾回收原理，也不讲 JVM 参数怎么调。它讲 8 个真实的泄漏案例，每个按"现象 → 定位 → 根因 → 改法 → 结果"完整拆开，让你下次遇到类似的曲线时能直接对上号。文末附一套四步定位法、六个高频误判和一份上线前自查清单。
案例一：静态 Map 当缓存，只增不删
背景：配置查询服务把字典表读进 Map，避免每次查库。
现象：内存每天涨约 400MB，第 8 天凌晨 OOM，重启后归零再涨。
定位：监控曲线是"阶梯上涨、重启归零"，QPS 平稳，排除流量因素；jmap -histo:live 显示 HashMap$Node 有 1200 万+，占内存 71%；jmap -dump + MAT 的 Dominator Tree 第一大对象是一个 static final Map，用 "Merge Shortest Paths to GC Roots" 追到配置类的静态字段。
根因：Map 的