Java中变量不占堆内存，真正需释放的是其指向的对象；GC能否及时回收取决于对象是否被“可达引用”持有，可通过设null、缩小作用域、避免静态引用、使用弱/软引用等让对象尽早不可达。
Java 中变量本身不占堆内存，真正需要释放的是它所指向的对象。垃圾回收（GC）是否能及时回收，关键在于对象是否还被“可达引用”持有。你无法强制立即释放，但可以通过合理操作让对象尽早变成“不可达”，从而被 GC 在合适时机回收。
让对象尽快进入可回收状态的核心方法
-
把引用变量设为
null
当明确知道某个对象后续不再使用，且该引用是唯一或最后的强引用时，赋值为null是最直接的提示。例如：List<String> data = new ArrayList<>(10000); // ... 使用完 data data = null; // 断开引用，帮助 GC 识别该 ArrayList 可回收
提前结束引用的作用域
局部变量天然在方法结束时失效，无需手动干预；但若方法很长、中间某段之后就不再用某个大对象，可将其提前置为null，或用更小的作用域包裹（比如用{}限定块级作用域），避免延长对象存活时间。避免静态引用长期持有对象
静态变量生命周期与类相同，只要类没卸载，它持有的对象就一直可达。如果静态集合（如static Map cache）不断添加却不清除，极易导致内存泄漏。应配合弱引用（WeakHashMap）、定时清理或 LRU 策略控制。-
用弱引用/软引用替代强引用（按需）
-
WeakReference<T>：GC 时不管内存是否充足都会回收，适合缓存、监听器等临时关联场景。 -
SoftReference<T>：只在内存不足时才回收，适合图片缓存等可容忍丢失的场景。
示例：WeakReference<List<String>> weakList = new WeakReference<>(new ArrayList<>()); // 后续 weakList.get() 可能返回 null，需判空
-
关于 System.gc() 的说明
立即学习“Java免费学习笔记（深入）”；
-
System.gc()只是建议 JVM 尽快执行 GC，不保证立刻执行，也不推荐在生产代码中调用。 - 它可能带来性能抖动（Stop-The-World），且现代 JVM 已足够智能，依赖自动触发更可靠。
真正“及时”的关键不在代码里，而在设计上
- 减少长生命周期对象对短生命周期对象的意外持有（如内部类隐式持外部类引用、监听器未反注册）
- 避免在 ThreadLocal 中存储大对象且不调用
remove() - 使用 try-with-resources 管理流、连接等资源（虽不直接管堆内存，但防止因资源泄漏间接拖慢 GC）
不复杂但容易忽略
