变量归属由jvm内存布局天然决定：局部变量存虚拟机栈（线程私有），实例变量存堆（线程共享），静态变量存方法区（线程共享），引用与对象分离，真正隔离需靠threadlocal等设计实现。
线程私有与共享区域的变量隔离，本质不是靠“手动隔离”，而是由JVM内存布局天然决定的——变量存到哪块区域，就决定了它被谁访问、是否需要同步。关键在于理解变量的生命周期和声明位置如何映射到具体内存区域。
变量声明位置决定内存归属
Java中没有“把变量声明为私有/共享”的语法开关，它的归属完全取决于变量类型和作用域：
- 局部变量（含方法参数）：始终分配在虚拟机栈的栈帧里，属于线程私有。即使变量是对象引用，引用本身在线程栈上，而它指向的对象实例仍在堆中。
- 成员变量（实例变量）：随对象实例一起分配在堆中，所有线程可见，天然共享。访问时需考虑同步或可见性（如volatile、synchronized）。
- 静态变量：存储在方法区（元空间），属于类元数据的一部分，所有线程共享，修改会影响全局状态。
- 常量（编译期常量，如public static final int）：直接内联进字节码，不占运行时内存；非常量字符串字面量则进入运行时常量池（方法区），同样共享。
引用 vs 对象：隔离常被误解的一点
一个常见误区是认为“对象引用在线程栈里，所以整个对象就是线程私有的”。其实不然：
- 栈中只存引用（比如Object obj = new Object()中的obj），它是个4字节或8字节的地址值，线程私有；
- new Object()创建的实际对象，在堆中分配，只要多个线程持有该对象的引用，就能并发访问它；
- 真正实现“逻辑私有”，得靠设计：比如用ThreadLocal包装对象，让每个线程持有一份独立副本，底层正是利用了线程私有栈 + 堆中各自独立的对象实例。
排查变量可见性问题的内存视角
当遇到多线程下变量值“看不到更新”或“值错乱”，可顺着内存区域反推原因：
- 如果变量是局部变量，却出现异常——大概率是闭包逃逸或Lambda捕获了外部可变状态，导致本该私有的引用意外暴露；
- 如果静态变量被多个线程修改后结果不符合预期——说明缺少同步，因为方法区里的静态字段是跨线程共享且无锁的；
- 如果对象字段更新后其他线程读不到最新值——可能是没用volatile修饰，或未进入synchronized块，导致JVM允许工作内存缓存旧值（涉及主内存与工作内存模型，但根源仍在堆的共享属性）。
工具辅助验证内存分布
仅靠代码推理容易出错，可用工具确认实际分配位置：
- 使用jmap -histo
查看堆中对象数量和大小，确认哪些类实例大量存在； - 通过jstack
观察线程栈帧，定位局部变量所在方法及调用链； - 配合JIT编译日志（-XX:+PrintCompilation）或JFR事件，判断热点方法是否被内联，间接影响栈帧结构；
- 对可疑静态字段，用jcmd
VM.native_memory summary 结合元空间使用量交叉验证。
