Java内存泄漏检查需结合工具与代码自查：通过JVM参数生成堆转储和GC日志，用VisualVM、JProfiler或MAT分析引用链，重点排查静态集合、内部类隐式引用、资源未关闭及第三方库误用等常见泄漏点。
Java检查内存泄漏主要靠工具分析堆内存快照，结合代码逻辑排查对象生命周期异常延长的问题。
用JVM参数开启内存监控
启动应用时添加关键参数，让JVM暴露内存信息：
- -XX:+HeapDumpOnOutOfMemoryError：发生OOM时自动生成堆转储文件（.hprof）
- -XX:HeapDumpPath=/path/to/dumps：指定dump文件保存路径
- -verbose:gc -Xloggc:gc.log（Java 8）或 -Xlog:gc*:gc.log（Java 9+）：记录GC日志，观察是否频繁Full GC且老年代回收效果差
用VisualVM或JProfiler抓取堆快照
运行中连接应用，手动触发堆转储（Heap Dump），然后离线分析：
- 看Objects by Class排序，关注实例数异常多、总大小占比高的类（如ArrayList、HashMap、自定义缓存容器）
- 对可疑类右键 → “Show in Instances View”，再选一个实例 → “References” 查谁在引用它
- 重点检查：静态集合（static List/Map）、ThreadLocal变量、未注销的监听器、缓存未设置过期或清理机制
用Eclipse MAT分析hprof文件
打开dump后，先看Leak Suspects Report（自动识别常见泄漏模式）；若没报，手动走三步：
立即学习“Java免费学习笔记（深入）”；
- 使用Dominator Tree，按“Retained Heap”降序，找占内存大且不该长期存活的对象
- 对目标对象点右键 → “Path to GC Roots” → 勾选exclude weak/soft references，查看强引用链
- 顺着引用链往上追，直到发现“不该持有它”的源头（比如某个Activity被静态Map强引用，导致整块Activity内存无法回收）
代码层面自查常见泄漏点
不依赖工具也能提前规避，重点关注这几类写法：
-
静态集合类：避免 static Map
缓存业务对象，改用 WeakHashMap 或加显式清理逻辑 - 内部类/匿名类：非静态内部类隐式持有外部类引用，Handler、Runnable、AsyncTask等在Activity销毁后仍执行，易导致Activity泄漏；建议用静态内部类 + WeakReference
- 资源未关闭：InputStream、Cursor、Bitmap、RxJava Subscription、Kotlin协程Job等，务必在finally或onDestroy中显式close/cancel
- 第三方库误用：如OkHttp的Call未cancel、EventBus未unregister、LeakCanary检测到的警告别忽略
基本上就这些。工具是眼睛，代码习惯是根基——定期抽样看dump，比等OOM更主动。
