局部变量总在栈上分配，因为Java虚拟机规范强制要求每个方法调用时创建栈帧，用于存储局部变量、操作数栈等，实现瞬时自动分配与释放，无GC开销。
局部变量为什么总在栈上分配
Java 虚拟机规范强制规定：方法调用时，每个栈帧（Stack Frame）必须为局部变量、操作数栈、动态链接等分配独立的栈空间。这意味着 int x = 5、String s = "hello"、甚至 new Object() 的引用本身（不是对象），都压入当前线程的 Java 栈。
关键点在于：栈分配是瞬时、自动、无 GC 开销的。只要方法执行完，整个栈帧弹出，所有局部变量（包括引用变量）立即失效。
-
String s = new String("abc")：变量s（引用）在栈，new String("abc")实例在堆 - 方法参数（如
void f(String arg)中的arg）也是局部变量，同样在栈 - for 循环内声明的
int i、if 块内的Object tmp，作用域一结束，栈空间就回收，不等 GC
成员变量为什么绑定在堆内存
成员变量属于对象状态的一部分，而对象实例（new MyClass()）只能分配在堆中——这是 JVM 堆内存的唯一职责：容纳所有“存活时间不确定、跨方法共享、需 GC 管理”的数据结构。
当你写 private String name;，它不是独立存在的；它和所属对象一起被分配在堆上，作为对象头之后的连续字段布局。哪怕 name 是 null，这个字段占位依然存在（对齐填充可能影响大小）。
- 实例变量随对象诞生而存在，对象被 GC 回收时才释放对应字段空间
- static 成员变量（类变量）例外：它存在方法区（JDK 8+ 是元空间），不是堆，但也不在栈
- 不要混淆“成员变量的值”和“成员变量本身”：基本类型值直接存堆中对象体内；引用类型值存的是地址（4 或 8 字节），指向另一个堆对象
怎么验证变量到底在哪儿
不能靠 System.out.println 看出来，得借助 JVM 底层视角。最直接的方式是用 jhsdb（JDK 9+ 自带）或 jmap + HSDB 工具 dump 堆/栈快照后分析。
更轻量的做法是观察行为差异：
- 局部变量无法被多个线程同时访问（除非逃逸），而成员变量天然可被共享——这是栈 vs 堆最实际的副作用
- 用
-XX:+PrintGCDetails观察 GC 日志：局部变量从不触发 GC；成员变量所在对象若不可达，才会在 Young GC / Full GC 中被清理 - 故意让局部变量引用大对象（如
byte[] big = new byte[1024*1024*10]），会快速耗尽栈空间报StackOverflowError；而同样大小的数组作为成员变量，只增加堆压力，栈无感
容易误判的几个典型场景
初学者常把“变量值所在位置”和“变量本身所在位置”混为一谈，尤其在涉及对象引用时。
-
String s = "hello"：字符串字面量"hello"在字符串常量池（堆中），变量s（引用）在栈——二者不在同一块内存 -
this.name = s：只是把栈上的s引用值复制到堆中当前对象的name字段里，没发生对象拷贝 - 逃逸分析后的局部对象可能被栈上分配（
-XX:+DoEscapeAnalysis），但这是 JIT 优化，语义上它仍是堆对象，且该优化在 JDK 17+ 默认关闭，不可依赖
真正决定内存位置的是变量的生命周期归属：由方法控制生死的 → 栈；由对象生命周期绑定的 → 堆。别被“new 出来就在堆”这种笼统说法带偏——new 出来的只是对象，而引用变量本身，永远看它在哪声明、归谁管。
