Java内存泄漏指对象业务上已无用却被引用链持有致GC无法回收，引发内存增长、OOM；常见场景有静态集合未清理、内部类隐式持外部类引用、ThreadLocal未remove、资源未关闭、监听器未反注册；定位靠jmap/LeakCanary/JProfiler等工具分析堆快照与引用链；预防需用WeakHashMap、static内部类、finally中remove ThreadLocal、try-with-resources、生命周期匹配的反注册。
Java内存泄漏是指对象不再被业务逻辑需要，却仍被某些引用链持有，导致垃圾回收器无法回收，最终引发内存占用持续增长、OOM等问题。
常见内存泄漏场景
以下几种情况最容易引发内存泄漏：
- 静态集合类持有对象引用：如 static Map 缓存数据后忘记清理，或 key 是临时对象但未及时 remove；
- 内部类/匿名类隐式持外部类引用：非静态内部类默认持有外部类 this，若该内部类被长期存活的对象（如线程、监听器）引用，外部类也无法释放；
- ThreadLocal 使用不当：在线程池中，ThreadLocal 变量未调用 remove()，会导致旧值在复用线程中一直残留；
- 未关闭资源型对象：如未 close 的 InputStream、Connection、Handler、BroadcastReceiver 等，可能关联着本地内存或系统资源，间接阻碍 GC；
- 监听器/回调注册后未反注册：比如 Activity 中注册了 EventBus、RxJava 订阅、View 的 OnClickListener，但在 onDestroy 时没解绑。
如何定位内存泄漏
靠日志和现象只能怀疑，确认需借助工具：
- jmap + jhat / VisualVM：导出堆快照（heap dump），查看大对象、重复实例、GC Roots 引用链；
- Android 平台推荐 LeakCanary：自动检测 Activity/Fragment 泄漏，给出清晰的引用路径图；
- JProfiler / YourKit：可视化分析对象生命周期、实时监控内存分配热点；
- 注意 GC 日志：频繁 Full GC 且老年代回收效果差，是典型信号；可用 -XX:+PrintGCDetails 观察。
预防与修复建议
写代码时多一层意识，能避开大部分问题：
帮管客CRM客户管理系统
下载
基于WEB的企业计算，php+MySQL进行开发，性能稳定可靠，数据存取集中控制，避免了数据泄漏的可能，采用加密数据传递参数，保护系统数据安全，多级的权限控制，完善的密码验证与登录机制更加强了系统安全性。
立即学习“Java免费学习笔记（深入）”；
- 静态集合类尽量用弱引用容器，如 WeakHashMap；缓存类优先选 Guava Cache 或 Caffeine，自带过期与大小控制；
- 内部类如无需访问外部成员，声明为 static；需传参时显式传入所需字段，避免隐式引用；
- ThreadLocal 使用后务必在 finally 块中调用 remove()，尤其在 try-with-resources 不适用的场景；
- 资源类遵循“谁创建、谁关闭”原则，用 try-finally 或 try-with-resources 包裹；
- 注册监听器的地方，对应生命周期结束时（如 onDestroy、onDestroyView）做反注册；可考虑使用 Lifecycle-Aware 组件（如 LiveData、LifecycleObserver）自动解绑。
基本上就这些。内存泄漏不复杂但容易忽略，关键是理解引用关系和 GC 触发条件，养成及时清理的习惯比事后排查更高效。
