jvm内存泄漏是对象引用失控持续积累的结果，表现为老年代阶梯式上涨、full gc回收率降低、响应缓慢；需监控内存曲线形态，排查静态集合、threadlocal未清理、资源未关闭三类高频泄漏点。
JVM内存泄漏不是“突然发生”的故障，而是对象引用关系失控后持续积累的结果。真正危险的信号，不是某次GC停顿变长，而是老年代内存阶梯式上涨、Full GC回收率越来越低、应用响应缓慢却查不到明显瓶颈——这说明大量本该释放的对象，正被某些隐蔽的强引用死死拽住。
看懂内存曲线，比等OOM更重要
监控不能只盯“内存使用率”这个数字，要重点观察堆内存变化形态：
- 老年代内存呈阶梯上升，每次Full GC后回落幅度递减 → 强烈提示存在长期存活对象未释放（如静态缓存、未注销监听器）
- 新生代GC频率正常，但晋升到老年代的对象数量逐轮增加 → 很可能是缓存膨胀、ThreadLocal残留或大对象提前晋升
- Metaspace持续增长且不回落 → 多由动态类加载引发（如Spring AOP代理类、Groovy脚本、热更新框架未卸载类）
建议在JVM启动参数中加入：-Xlog:gc*,safepoint:file=gc.log:time,tags:uptime,level，配合Prometheus+Grafana绘制GC趋势图，在告警触发前就识别异常模式。
三类高频泄漏点，代码里就能堵住
约80%的内存泄漏集中在以下场景，修复成本低、见效快：
- 静态集合无清理机制：把static Map/List换成ConcurrentHashMap + 定期清理逻辑；更优解是改用Caffeine缓存（自带LRU淘汰和定时过期）
- ThreadLocal未remove()：尤其在线程池复用场景下，必须在finally块中调用threadLocal.remove()，否则线程复用时会携带上一个请求的上下文对象
- 资源未显式关闭：InputStream/Connection/ResultSet等，优先用try-with-resources语法；自定义资源类务必实现AutoCloseable接口
堆转储分析，聚焦“谁持有谁”
确认泄漏后，生成heap dump不要急着看“最大对象”，先查引用链起点：
- 用Eclipse MAT打开dump，运行Leak Suspects Report，它会自动标出可疑集合和强引用路径
- 重点关注Shallow Heap小但Retained Heap巨大的对象——往往是泄漏源头（比如一个被静态Map持有的小DTO，却拖着整个用户会话）
- 筛选java.lang.Thread实例，检查其threadLocals字段是否持有大量业务对象
生产环境dump较大，建议用jmap -dump:format=b,file=/tmp/heap.hprof
上线前加一道内存安全卡点
预防比排查更高效，把内存意识融入开发流程：
- Code Review清单中明确加入：“是否有静态引用？”、“是否注册了监听器但没反注册？”、“是否用了ThreadLocal但没remove？”
- 单元测试补充内存敏感用例：模拟多次调用后，通过Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory()估算内存增量，验证对象是否被及时释放
- CI流水线中集成SpotBugs或SonarQube规则，扫描潜在的静态集合滥用、资源未关闭、内部类隐式引用等问题
