Java内存泄漏本质是对象仍被GC Roots可达却无业务用途，主因包括静态集合持有、资源未关闭、监听器未注销、ThreadLocal残留、内部类隐式引用、缓存设计不当、finalize复活及类加载器泄漏，需针对性规避。
Java内存泄漏不是GC失灵，而是对象本该被回收，却因被意外持有引用而无法释放。核心逻辑始终是：对象仍处于GC Roots可达路径上，且已无业务用途。
静态集合长期持有对象
静态Map、List等容器生命周期与JVM一致，若持续add却不remove，对象会一直驻留堆中。尤其在缓存、统计、监听注册等场景易发。
- 避免直接用static List/Map存储业务对象；确需缓存时，优先选WeakHashMap或Guava Cache，并设size limit与expireAfterWrite
- 若必须用静态集合，配套提供clear()或定期清理逻辑，例如按时间戳或访问频次淘汰
- 注意单例类中持有的Context——Android开发中务必用Application Context，而非Activity Context
资源未显式关闭
InputStream、Connection、ResultSet、Socket等实现AutoCloseable接口的资源，未关闭会导致底层句柄和关联对象无法释放，间接引发堆内存滞留。
- 强制使用try-with-resources语法，编译期保障close调用
- 避免在finally块中仅捕获异常却不抛出或记录，导致close失败被静默吞掉
- 第三方SDK（如数据库连接池）需确认其资源归还机制，防止连接泄露后线程持续持有Connection引用
监听器与回调未注销
GUI事件、广播接收器、RxJava订阅、OkHttp拦截器等注册后未反注册，会使监听目标（如Activity、Fragment）被长期持引用，无法GC。
立即学习“Java免费学习笔记（深入）”；
- 在组件生命周期结束处（如onDestroy、onDetach）主动调用removeListener、unregisterReceiver、dispose/disposeAll
- 使用WeakReference包装监听器内部引用，降低强依赖风险
- 优先选用支持自动生命周期绑定的方案，如LiveData.observe(this, …) 或 Jetpack Lifecycle-aware组件
ThreadLocal变量残留
在线程池复用场景下，ThreadLocal若不手动remove，线程再次被调度时仍持有前一次任务的旧数据，尤其当值为大对象或含Context时危害显著。
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
- 每次使用完ThreadLocal后立即调用remove()，建议封装成工具方法统一处理
- 避免在ThreadLocal中存Activity、View等短生命周期对象
- 考虑用InheritableThreadLocal需更谨慎，子线程继承后同样需清理
非静态内部类隐式引用外部类
匿名类、Handler、Runnable定义在Activity或Service内部时，会隐式持有this引用。若它们被异步任务、静态变量或线程池长期持有，将导致外部Activity实例无法回收。
- 将内部类声明为static，通过WeakReference安全访问外部成员
- Handler使用static + WeakReference是Android开发标准实践
- 避免在静态字段中直接赋值非静态内部类实例
缓存与哈希结构设计不当
自建LRU缓存未限制容量，或HashMap键未正确重写hashCode/equals，导致重复put、key无法命中、旧entry堆积不释放。
- 实体类作Map key前，务必重写hashCode和equals，且基于不可变字段（如id）
- 禁止用可变对象（如Date、StringBuilder）作key；若必须，确保其状态不再变更
- 缓存优先选用成熟库（Caffeine、Guava Cache），内置过期、大小控制与引用清理能力
finalize复活对象
在finalize方法中将this重新赋给静态变量或全局容器，使本该回收的对象“起死回生”，破坏GC判定逻辑，且finalize执行不可控、开销大。
- 彻底弃用finalize，改用Cleaner（Java 9+）或PhantomReference配合ReferenceQueue做资源清理
- 资源释放逻辑应放在显式close或destroy方法中，而非依赖GC时机
类加载器泄漏
Web容器或OSGi环境中，热部署模块卸载时，若自定义ClassLoader被静态变量、线程或缓存强引用，其所加载的所有类及静态数据均无法卸载，Metaspace持续增长。
- 避免在静态上下文中长期持有ClassLoader实例
- 使用Thread.currentThread().getContextClassLoader()替代显式保存Classloader引用
- 确保所有动态加载类的资源（如文件、网络连接）随ClassLoader一并释放
不复杂但容易忽略——多数泄漏源于“一时方便”的引用延长，而非技术难点。关键是在设计阶段就明确对象生命周期边界，并借助MAT、JProfiler或Arthas定期做堆转储分析，把问题拦在上线前。
