局部变量存储在栈帧的局部变量表中，基本类型值直接存放，引用类型存放指向堆中对象的地址。
局部变量到底存在栈帧的哪个位置
局部变量存于当前线程栈中，具体是方法调用时创建的栈帧（Stack Frame）里的「局部变量表」（Local Variable Table）。它不是随便扔在栈内存某处，而是有固定索引编号的连续槽位——比如 iload_1 指令就是从索引 1 的槽里取 int 值。
常见错误现象：NullPointerException 却找不到 null 赋值点，其实是因为局部变量引用被新赋值覆盖，或方法已 return，栈帧销毁，槽位内容失效——不是对象被 GC 了，是“指向它的那个槽”没了。
- 基本类型（如
int、boolean）值直接存进局部变量表对应槽位 - 引用类型（如
String s）存的是堆中对象的地址，s本身在栈帧里，new String("hi")在堆中 - for 循环末尾定义的新变量可能复用前面已出作用域的槽位，所以栈空间不随代码行数线性增长
- 方法参数也是局部变量，同样走这套机制，哪怕传的是对象引用
成员变量为什么一定嵌在堆中对象的内存布局里
成员变量属于对象实例的一部分，而 JVM 创建对象时，会把对象头、实例数据（即所有非 static 字段）、对齐填充三块内容一并分配在堆上。你写的 private int count 或 private List<String> items，字段本身和它的值（或引用）都固化在这个堆块内部。
使用场景：当你写 this.count 或 obj.items，JVM 实际是在堆中根据对象起始地址 + 字段偏移量去读写——这个偏移量在类加载阶段就确定了，不是运行时查表。
-
count是基本类型，值直接存在对象内存块里；items是引用类型，它存的是另一个堆对象（如ArrayList）的地址 -
static字段不在此列，它在元空间（JDK 8+），和任何对象实例无关 - 逃逸分析可能导致对象栈上分配（标量替换），但这是 JVM 优化，语义不变：你写的成员变量逻辑仍按“属于堆中对象”理解
- 没有“成员变量单独在堆里”这回事——它永远依附于所属对象的内存块
怎么验证某个字段真正在堆中哪个位置
光看代码猜不出来，得用 JOL（Java Object Layout）工具实测。它能打印出类实例在堆中的完整内存布局，包括每个字段的偏移量、占用字节、是否受压缩指针影响。
示例：运行 new ArrayList<>() 后用 ClassLayout.parseInstance(obj).toPrintable()，你会看到 elementData 字段在对象起始地址 + 24 字节处，类型是 Object[] 引用——这就是它在堆中真实嵌入的位置。
- 字段偏移量不是按声明顺序严格排列的，JVM 会按大小重排（如先放 long/double，再 int，最后 byte/boolean）以提升内存对齐效率
- 32 位 JVM 和开启压缩指针（-XX:+UseCompressedOops）的 64 位 JVM，引用字段占 4 字节；否则占 8 字节
- 空对象（仅
Object obj = new Object();）在开启压缩指针时也至少占 16 字节（对象头 12 + 对齐填充 4）
局部变量遮蔽成员变量时，this.field 到底访问的是哪块内存
this.count 访问的是当前对象在堆中的那个 count 字段，和局部变量 count 完全无关——前者在堆中某偏移地址，后者在栈帧某个槽位，物理隔离，互不影响。
容易踩的坑：在 setter 方法里写 count = count;，你以为是赋值，其实是局部变量给自己赋值；必须写 this.count = count; 才真正写入堆中对象。
- 静态方法里不能用
this，因为没对象实例，也就没堆中那块内存可访问 -
this本身是个隐式局部变量，存的是当前对象的堆地址，它自己在栈帧里，但它指向的内容在堆中 - 局部变量名和成员变量名相同时，编译器按“就近原则”绑定，不加
this就永远访问不到成员变量
