Java内存泄漏常见根源是长生命周期对象无意持有短生命周期对象引用，导致后者无法回收；典型场景包括静态集合类、非静态内部类、单例不当引用、监听器未注销，均需通过弱引用、淘汰策略或配对注销规避。
Java中内存泄漏的常见根源，就是长生命周期对象无意中持有了短生命周期对象的引用，导致后者无法被垃圾回收器回收。这种问题不依赖于手动内存管理，却因引用关系“卡住”了本该释放的对象，最终造成堆内存持续增长甚至OOM。
静态集合类长期持有对象
静态变量的生命周期与JVM一致，一旦其中存入对象，除非显式移除或清空，否则这些对象会一直驻留内存。
- 典型场景：用 static Map/ArrayList 实现缓存，只增不删
- 风险点：缓存键无过期机制、未做容量限制、未触发清理逻辑
- 建议做法：改用 WeakHashMap（键为弱引用）或 Caffeine 等带淘汰策略的缓存库；若必须用原始集合，配套实现定时清理或LRU淘汰
非静态内部类隐式持有外部类
非静态内部类默认持有一个对外部类实例的隐式引用。当内部类被传递到线程、监听器、异步回调等长生命周期上下文中时，外部类也会被“拖住”无法释放。
- 典型场景：在Activity或Service中定义非静态Handler、Runnable、匿名监听器，并注册到全局事件总线或线程池
- 风险点：外部类（如Activity）已销毁，但因内部类仍存活，整个实例被强引用保留
- 建议做法：优先使用 静态内部类 + WeakReference 持有外部对象；避免在内部类中直接访问外部类成员，改用传参方式
单例与全局服务不当引用
单例对象在整个应用生命周期内存在，若它持有Activity、Fragment、Context等短生命周期对象的强引用，就会形成泄漏链。
立即学习“Java免费学习笔记（深入）”；
- 典型场景：单例中保存了Application Context以外的Context（如Activity.this）、或缓存了View、Listener等UI组件
- 风险点：Activity重建或退出后，其引用仍被单例持有，导致整套视图树无法回收
- 建议做法：单例中统一使用 ApplicationContext；对需持有UI对象的场景，改用 WeakReference 并在使用前判空
监听器和回调未及时注销
注册到系统服务、EventBus、RxJava、LiveData等机制中的监听器，若未在适当时机反注册，会持续持有目标对象引用。
- 典型场景：在onCreate中注册广播接收器或PropertyChangeListener，却在onDestroy中遗漏unregister
- 风险点：监听器本身可能很小，但它持有的宿主对象（如Activity）体积巨大
- 建议做法：遵循“注册与注销配对”原则；优先使用支持自动生命周期绑定的方案（如LifecycleObserver、viewLifecycleOwner）
