变量本身是引用容器，真正分配与回收的是其指向的对象；对象分配位置由变量声明方式（如局部/静态）和逃逸分析决定，存活状态取决于是否可达GC Roots，而引用类型（强/软/弱/虚）可主动调控回收时机。
理解变量对象在 JVM 中的分配与回收，关键不是背算法，而是看它“怎么活、在哪活、怎么死”。变量本身（如局部变量、静态变量）只是引用容器，真正被分配和回收的是它所指向的对象。整个过程由对象生命周期驱动，而变量的作用，是决定这个对象能否“活下来”。
变量如何影响对象的分配位置
变量声明方式和作用域，间接左右对象出生地：
-
局部变量引用的新对象：绝大多数情况，
Object obj = new Object()创建的对象优先进入 Eden 区；若对象较大（如new byte[2*1024*1024]），且设置了-XX:PretenureSizeThreshold=1048576，会直接进老年代，避免年轻代频繁复制 -
静态变量引用的对象：如
public static List，该 ArrayList 实例一创建就可能长期存活，很快晋升老年代；若持续往里 add 大量字符串，还会加速老年代填充cache = new ArrayList(); - 方法参数或返回值中的对象：不改变分配逻辑，但影响逃逸分析结果——若 JIT 判定该对象未逃逸出当前方法，可能直接栈上分配（标量替换），根本不进堆
变量生命周期决定对象“是否可达”
GC 不看变量名，只看从 GC Roots 能否触达对象。变量的存续时间，就是对象的“保命线”：
- 方法内定义的局部变量，在方法执行完出栈后自动消失 → 它引用的对象立刻失去一条 GC Root，若无其他引用，下次 Minor GC 就可能被回收
- 类的静态字段（
static）随类存在而存在 → 它引用的对象只要不被显式置为null，通常一直可达，容易造成内存堆积 - 线程局部变量（
ThreadLocal）需特别注意：线程长期运行时，若未调用remove()，其持有的对象即使业务逻辑已结束，仍被 ThreadLocal Map 强引用，引发内存泄漏
用不同引用类型主动参与回收节奏
变量不只是强引用容器，还可选用更“松”的引用策略，把回收时机交给 JVM 统筹：
-
软引用（
SoftReference）：适合缓存场景，如SoftReference；仅当 JVM 内存不足时才回收，既延缓回收又防 OOMcachedImg = new SoftReference(loadBigImage()); -
弱引用（
WeakReference）：适合临时映射，如WeakHashMap的 key；只要发生 GC（哪怕是 Minor GC），key 对应的 Entry 就可能被清除 -
虚引用（
PhantomReference）：不阻止回收，仅用于对象被回收后的通知，常配合ReferenceQueue做资源清理（如关闭堆外内存、注销监听器）
实战中一眼定位分配/回收异常
结合变量行为看 GC 日志和堆快照，问题往往直击要害：
- 日志中频繁出现
[GC (Allocation Failure)：说明 Eden 区总不够用 → 检查是否有局部变量无意持有了大对象或长生命周期集合 - 老年代使用率缓慢上升且 Full GC 后下降不多：大概率是静态集合类（如
static Map）不断 put 却不 remove → 找对应变量声明处 - jmap -histo 输出中某类实例数异常高：按类名反查哪些变量在反复 new 它，再看这些变量是否本该复用或及时释放
