JITWatch通过分析JIT编译日志和汇编代码间接推断变量优化行为，需配置-XX:+LogCompilation、-XX:+UnlockDiagnosticVMOptions、-XX:+PrintAssembly三项参数，结合TriView与Inlining视图定位方法并观察内联、消除、常量传播等痕迹。
JITWatch本身不直接“观测变量”，它分析的是JIT编译器对方法的优化行为，而变量的生命周期、栈帧布局、寄存器分配等细节，需通过字节码和汇编视图间接推断。真正能被你“可视化观测”的，是变量参与的计算路径是否被内联、消除、提升或向量化——这些都体现在方法级的编译决策中。
配置正确的JIT日志输出
没有高质量的日志，后续所有可视化都无从谈起。必须启用三项关键VM参数：
-
-XX:+LogCompilation：生成结构化XML格式的编译日志（如
hotspot_pid12345.log），含内联树、编译层级、失败原因 - -XX:+UnlockDiagnosticVMOptions：解锁诊断选项，是启用下一项的前提
-
-XX:+PrintAssembly：输出汇编代码（需提前配置
hsdis库，Linux/macOS推荐用OpenJDK自带版本）
可附加-XX:LogFile=jit.log指定日志路径，避免与标准输出混杂。
定位目标方法并加载到TriView
JITWatch主界面左侧是类/方法树。要追踪某段含关键变量逻辑的代码：
- 确保你的Java源码和编译后的
.class文件路径已在JITWatch中正确配置（File → Configure paths） - 在树中展开对应类，找到目标方法（例如
calculateSum(int a, int b)） - 双击该方法，自动进入三视图（TriView）：左侧源码、中间字节码、右侧汇编
此时若该方法已被C2编译，三视图将全部填充；若为空，说明未触发JIT，需增加循环调用次数或加-XX:CompileThreshold=100降低阈值。
从汇编反推变量优化痕迹
变量本身不会出现在汇编里，但它的使用方式会留下明确线索：
-
变量被消除：源码中声明但未使用的局部变量，在字节码里可能已无
istore/iload，汇编中完全不可见 -
变量被常量传播：若
int x = 5; return x * 2;，汇编中直接出现mov eax, 10，而非加载再乘 -
变量参与内联后消失：调用
helper(x)且该方法被内联，原x的传参指令（如iload_1）会与helper内部操作融合，汇编中找不到独立的“x搬运”痕迹 -
数组索引变量被强度削减：循环中
i * 4可能被转为lea eax, [rdx+rdx*2]或更直接的地址计算
借助内联视图看变量上下文流转
点击方法名旁的“Inlining”标签页，可查看完整内联树。这里能确认：
- 某个含状态变量的方法是否被拒绝内联（比如因
too big或too many branches），导致变量始终以栈帧形式存在 - 变量所在方法是否作为叶子节点被多层调用者内联，从而让其计算彻底融入上层逻辑
- 若某次内联失败，日志中会写明原因，例如
reason: hot method too big (123 bytes)，提示你拆分逻辑或用@ForceInline干预
这种上下文视角，比单看一个方法的汇编更能说明变量为何“没被优化”或“被优化得特别深”。
