Java内存泄漏本质是堆中对象因引用关系不当而无法被回收，关键在于控制变量作用域、避免隐式长生命周期绑定，并按需选用弱/软/虚引用。
Java 变量本身不直接“泄漏”，真正泄漏的是堆中对象——而变量（尤其是引用类型）的声明方式、作用域和持有关系，决定了这些对象能否被及时回收。关键不是“怎么声明变量”，而是“怎么让变量不意外延长对象的存活时间”。
局部变量：用完即弃，别往外传
方法内声明的变量天然具备短生命周期，但需警惕“无意逃逸”：
- 避免将局部创建的对象添加进静态集合、单例或线程池任务中；
- 流、连接、缓存等资源类对象，即使声明为局部变量，也必须显式关闭（推荐 try-with-resources）；
- 长循环中处理大量数据时，若某临时对象在循环中途就不再需要，可主动置为 null，辅助 GC 提前识别不可达对象。
成员变量：警惕隐式绑定与跨生命周期引用
实例变量随对象存在，静态变量随类存在——它们极易成为内存泄漏入口：
- 不要让 Activity、Fragment、Listener 等短命对象被单例、静态 Map 或后台线程长期持有；
- 注册监听器后，务必在对应销毁时机（如 onDestroy()、close()）反注册或清空引用；
- 对缓存、回调等非强依赖场景，优先使用 WeakReference 或 SoftReference 包装，避免阻碍 GC。
作用域最小化：从写法上切断冗余引用
变量声明位置直接影响其“存活窗口”，越晚声明、越早脱离作用域，风险越低：
立即学习“Java免费学习笔记（深入）”；
- 不用的字段尽量不声明为实例变量，改用方法参数或局部变量；
- 循环内使用的对象，声明在循环体内而非外部（避免重复引用旧对象）；
- 避免为图方便把本该局部使用的对象提升为类级别变量，尤其带状态的工具类实例。
特殊引用与资源：按需选型，不默认强引
不是所有引用都该是强引用。根据语义选择合适类型：
- 强引用：业务主逻辑对象，确保不被回收；
- 软引用：适合缓存——内存紧张时自动释放，防 OOM；
- 弱引用：适合监听器、映射表（如 WeakHashMap），对象仅被弱引用时，GC 下次即可回收；
- 虚引用：配合 ReferenceQueue 实现对象被回收后的清理钩子，如堆外内存释放。
不复杂但容易忽略：变量生命周期可控的本质，是让引用关系清晰、短暂、可预测。写代码时多问一句——“这个引用，还真的需要存在吗？”
