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
cache = new HashMap(); - 若必须用，搭配定时清理（如ScheduledExecutorService定期调用removeExpired()）；
- 更稳妥的做法是把集合生命周期绑定到具体业务对象上，用局部变量代替全局静态。
内部类与监听器要“断干净”
非静态内部类、匿名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接口，才能纳入该语法支持范围。
内存泄漏不是玄学问题，本质是对象生命周期与引用关系没对齐。写完一段逻辑，多问一句：“这个对象什么时候真正不需要？谁还在拽着它？”——答案清楚了，泄漏就防住了。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
