Java内存泄漏这个问题，其实并非垃圾回收器（GC）失效，而是代码中悄悄保留了本应释放的对象引用。核心解决思路很明确：不要指望GC自动清除，必须手动切断强引用链，对象才能被顺利回收。
首先来看引用类型。强引用虽然使用方便，但正是内存泄漏的主要诱因——只要强引用存在，GC就无法处理。在缓存场景中，换用弱引用或软引用更安全：WeakReference专门用于生命周期短、丢失后影响小的数据，例如临时UI组件映射，下次GC就可能回收；SoftReference适合希望尽量保留、但内存紧张时可以释放的缓存，如图片预加载数据；更省心的做法是直接使用WeakHashMap替代静态Map进行键值缓存——当key对象不再有其他强引用时，整个entry自动消失，无需手动清理。
静态集合必须设定“退出机制”
static List或Map一旦持有对象，这些对象的生命周期将与应用程序同步。只添加不清理，迟早出现内存溢出。如果工具类中声明了public static Map
内部类与监听器务必“彻底断开”
非静态内部类、匿名Runnable、事件监听器等，都会隐式持有外部实例的强引用。一旦它们被注册到长期存活的组件（如单例、静态Handler、线程池任务），外部对象就无法被回收。推荐使用static内部类 + WeakReference组合来切断隐式引用；在Activity或Fragment中注册的监听器、广播接收器，记得在onDestroy()或onDetach()中显式调用unregister/remove；使用RxJava、LiveData等框架时，订阅的生命周期必须紧密绑定，避免订阅者泄漏。
资源关闭不能依赖“记住”，而要靠语法机制保障
文件流、数据库连接、Socket等本身占用的堆内存不大，但它们关联的本地句柄和缓冲区会导致GC效率下降，甚至引发间接泄漏。一律使用try-with-resources——JVM会确保finally块自动执行，无需手动编写close；千万不要在catch块中吞掉异常后跳过close，也不要在finally中忽略close抛出的异常；对于自定义资源类，实现AutoCloseable接口后即可纳入此语法保护范围。
总而言之，内存泄漏并非玄学，而是对象生命周期与引用关系没有对齐。写完一段逻辑后，多问自己一句：“这个对象什么时候真正不再需要？谁还在持有它的引用？”——想清楚这一点，泄漏自然能被有效防范。
