线程栈变量存于栈帧的局部变量表和操作数栈，JIT编译后变量可能分配至CPU寄存器、栈帧扩展槽位或被优化消除，取决于寄存器分配、逃逸分析与标量替换。

要理解线程栈与JIT编译后代码中变量的分布，关键不是孤立看“本地内存”这个词，而是厘清JVM运行时内存中哪些区域真正由本地（native）机制参与、哪些变量实际驻留在CPU近端——尤其是栈帧结构、寄存器参与、以及JIT优化对变量生命周期的影响。

线程栈的本质：栈帧 + 局部变量表 + 操作数栈

每个Java线程启动时，JVM为其分配独立的虚拟机栈。栈中每调用一个方法，就压入一个栈帧；方法返回，栈帧弹出。栈帧包含：

• 局部变量表：存放方法参数、显式声明的局部变量（含基本类型值、对象引用）。大小在编译期确定（见class文件的max_locals），不随运行时变化。
• 操作数栈：JVM指令执行的“工作台”，比如iload_0从局部变量表取int，iadd从操作数栈弹出两数相加再压回——这里没有寄存器，全靠栈模拟。
• 动态链接与返回地址：支持方法调用链和异常处理跳转。

注意：栈帧本身在JVM管理的内存中（通常在堆外但受操作系统分配），但它的访问速度接近高速缓存，因为线程栈常被CPU缓存预取；而栈中存储的“对象引用”只是指针或句柄，真实对象一定在堆中。

JIT编译后代码里的变量去哪了？

JIT（如HotSpot的C2编译器）将热点字节码编译为本地机器码，此时变量不再严格遵循JVM栈模型。关键变化有：

• 寄存器分配：JIT会把频繁使用的局部变量（如循环计数器、临时计算结果）直接分配到CPU寄存器，完全绕过操作数栈和局部变量表。这类变量在Java层面不可见，也不占栈空间。
• 栈上分配（逃逸分析启用时）：若JIT判定某个对象未逃逸出当前方法作用域（如new StringBuilder()只在方法内使用），可能将其字段拆解，直接分配在栈帧内（而非堆），提升分配/回收效率。此时“对象”已无完整堆地址，只有若干寄存器或栈偏移量承载其字段值。
• 标量替换：进一步将对象字段（如Point.x, Point.y）当作独立标量处理，各自放入寄存器或栈槽，彻底消除对象头与引用开销。

也就是说：JIT后的变量，可能在CPU寄存器里、可能在线程栈的扩展槽位里、也可能被彻底优化掉（如常量折叠）。它们不再对应class文件里的局部变量表索引。

如何验证与观察？

光看Java代码无法得知JIT行为，需借助工具定位实际内存布局：

• 用-XX:+PrintAssembly（需hsdis）查看JIT生成的汇编，搜索%r10、%eax等寄存器名，确认变量是否被载入寄存器。
• 开启-XX:+UnlockDiagnosticVMOptions -XX:+PrintEscapeAnalysis，观察逃逸分析日志，判断对象是否被栈上分配。
• 用jstack看线程栈帧调用链，但它只显示JVM视角的栈帧，不反映JIT寄存器映射；配合jmap -histo或jstat -gc可辅助判断堆对象是否减少（间接印证栈上分配生效）。
• 本地方法栈（Native Method Stack）仅服务于native方法调用（如Object.wait()底层调用OS线程等待），它不存放Java变量，也不参与JIT优化——它只是C函数调用栈的Java侧镜像。

真正影响变量分布的，是JVM栈结构 + JIT编译策略 + CPU寄存器资源，三者协同决定变量最终落点。理解这点，才能避免把“栈内存”简单等同于“Java局部变量表”。