Java引用类型和垃圾回收实战：如何避免内存泄漏

Java内存泄漏本质是代码中无意保留了本该释放的强引用，需主动切断引用链而非依赖GC；应合理选用WeakReference、SoftReference或WeakHashMap，避免静态集合无清理机制，谨慎使用非静态内部类与监听器，并通过try-with-resources保障资源关闭。

Java内存泄漏不是GC失灵，而是代码中无意保留了本该释放的引用。关键不在于“等GC来收”，而在于主动切断那些让对象无法被回收的强引用链。

用对引用类型，让缓存可回收

强引用最常用，但也是泄漏主因——只要它存在，GC绝不会动对象。缓存场景下，改用弱引用或软引用更安全：

• WeakReference：适合生命周期短、可随时丢弃的数据，比如临时UI组件映射，GC下次运行就可能回收；
• SoftReference：适合想尽量保留但允许内存紧张时释放的缓存，如图片预加载数据；
• 直接用WeakHashMap替代静态Map做键值缓存，当key对象无其他强引用时，整条entry会被自动清理。

静态集合必须设“退出机制”

static List或Map一旦持有对象，这些对象就和应用同生共死。不能只往里塞，不往外清：

• 避免在工具类中声明public static Map<String, Object> cache = new HashMap<>();
• 若必须用，搭配定时清理（如ScheduledExecutorService定期调用removeExpired()）；
• 更稳妥的做法是把集合生命周期绑定到具体业务对象上，用局部变量代替全局静态。

内部类与监听器要“断干净”

非静态内部类、匿名Runnable、事件监听器，都隐式持有着外部实例的强引用。如果它们被注册到长期存活的对象（如单例、静态Handler、线程池任务），外部对象就永远无法回收：

立即学习“Java免费学习笔记（深入）”；

• 优先用static内部类 + WeakReference组合，避免隐式引用；
• Activity或Fragment中注册的监听器、广播接收器，务必在onDestroy()或onDetach()中显式unregister/remove；
• 使用RxJava、LiveData等框架时，注意订阅生命周期绑定，避免泄漏订阅者。

资源关闭别靠“记得”，要靠语法保障

文件流、数据库连接、Socket等资源本身不占太多堆内存，但它们关联的本地句柄和缓冲区会拖慢GC，甚至引发间接泄漏：

• 一律使用try-with-resources，JVM保证finally块执行，无需手动close；
• 不要在catch里吞掉异常后跳过close，也不要在finally里忽略close抛出的异常；
• 自定义资源类需实现AutoCloseable接口，才能纳入该语法支持范围。

内存泄漏不是玄学问题，本质是对象生命周期与引用关系没对齐。写完一段逻辑，多问一句：“这个对象什么时候真正不需要？谁还在拽着它？”——答案清楚了，泄漏就防住了。