Java内存泄漏排查须回归“该走的没走”本质，忌盲目扩堆、只看堆栈、无监控盲查、滥用弱引用；应结合MAT分析GC Roots、配置原生GC日志、强化代码审查与缓存治理。
直接加内存、只看报错堆栈、跳过监控盲猜原因——这三类做法在Java内存泄漏排查中看似高效，实则南辕北辙，常把问题拖得更久、改得更偏。真正有效的纠正是从逻辑起点回归：泄漏不是“内存不够”，而是“该走的没走”。下面说几个高频错误及对应修正动作。
错误一：一见 OOM 就调大 -Xmx，以为是配置小了
很多团队发现 OutOfMemoryError 后，第一反应是把 -Xmx 从 2G 改成 4G，甚至 8G。结果服务短暂恢复，几天后照样崩。这不是扩容，是给泄漏对象腾出更多“棺材板”。
✅ 正确做法：
- 先确认是不是泄漏：观察老年代使用率是否持续 >90%，Full GC 后内存不回落，且 GC 耗时越来越长
- 若符合泄漏特征，暂停调参，立即开启 -XX:+HeapDumpOnOutOfMemoryError 并保留最近一次 dump 文件
- 用 MAT 或 JProfiler 打开 dump，按“dominator tree”排序，重点看谁持有了最多对象实例（比如某个静态 Map、未注销的监听器）
错误二：只盯异常堆栈顶那几行，忽略引用链源头
日志里报 java.lang.OutOfMemoryError: Java heap space，堆栈指向某次 new byte[1024*1024] ——很多人立刻去改这个数组大小。但真实原因可能是：这个 byte[] 是被一个静态缓存容器反复 hold 住，而缓存本身从未清理。
✅ 正确做法：
- 在 MAT 中右键可疑大对象 → “Path to GC Roots” → 勾选“exclude weak/soft references”
- 逐层往上追，直到看到 static 字段、ThreadLocal、单例 Bean 等强持有源
- 重点关注：static 集合、注册未注销的 Listener、未关闭的 Connection、非静态内部类隐式引用外部类
错误三：不设监控就上线，靠崩溃后“复现+抓dump”被动响应
等 OOM 才启动排查，等于等病人休克再量血压。此时 JVM 已严重失稳，dump 文件可能损坏，GC 日志也早已滚动覆盖。
✅ 正确做法：
- 上线前就配好基础监控：JVM 堆内存曲线（尤其老年代）、Full GC 次数/耗时、线程数趋势
- 关键服务加 -Xlog:gc*:file=gc.log:time,uptime,level,tags —— 不依赖第三方 Agent，原生日志够用
- 对高风险模块做代码审查：凡含 static、ThreadLocal、addXXXListener、new Thread() 的地方，必须配套 remove/clear/close 逻辑
错误四：用 WeakReference / SoftReference 当“万能解药”乱套
听说“弱引用能防泄漏”，就在所有静态容器里换成 WeakHashMap。结果业务查不到缓存，大量穿透 DB，接口超时飙升——WeakReference 解决的是“可丢弃”场景，不是“该管理”问题。
✅ 正确做法：
- WeakHashMap 仅适用于 key 是临时对象、且允许随时被回收的场景（如 GUI 组件映射）
- 业务缓存必须用 Guava Cache 或 Caffeine：设置 maximumSize + expireAfterWrite，由框架保障淘汰
- 静态集合若真需长期存在，必须提供显式清理入口（如 Spring @PreDestroy、ShutdownHook），并写进运维 checklist
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
