JIT热点探测不为变量设计数器，而是通过方法调用和循环回边计数器标记执行上下文为热点，再在编译阶段基于类型稳定性等分析变量以实施栈上分配、标量替换等优化。
要理解JIT热点探测算法中计数器如何影响变量相关的编译决策，关键不是看“变量本身”，而是看变量所处的**执行上下文是否被计数器标记为热点**。JVM不为单个变量设计数器，它通过方法调用和循环回边两个维度统计执行频次，再据此决定是否编译、何时编译、编译到什么程度——而变量的优化（如栈上分配、标量替换、常量传播）正是在编译阶段才真正发生。
方法调用计数器决定“是否启动编译”
每个非native方法都有一个调用计数器，每次进入方法时加1。一旦超过阈值（Server模式默认10000），该方法被提交至C1编译队列：
- 这个动作本身不依赖变量类型或数量，只依赖调用次数
- 但计数器达标后，JIT在编译时会分析方法内所有变量：比如局部变量是否逃逸、是否被频繁读写、类型是否稳定
- 若某int变量在整个方法中始终未变，C1可能做常量折叠；若它被反复赋值且类型未变，C2后续可能做寄存器分配优化
回边计数器触发OSR编译，直接影响循环内变量处理
回边（back edge）指循环末尾跳转回开头的字节码指令（如goto、if_icmp）。每次执行该跳转，回边计数器+1。超阈值后触发栈上替换（On-Stack Replacement），即在循环中途把解释执行切换为已编译的机器码：
- 此时JIT重点分析循环体内的变量生命周期：例如数组索引i、累加器sum、临时对象ref
- 若i始终是int、sum始终是long、ref指向同一类实例，C2可做循环展开+冗余检查消除
- 反之，若循环中某变量中途被改为其他类型（如sum = "done"），则触发去优化，退回到解释执行
计数器衰减与类型稳定性共同决定“能否升到C2”
计数器不是只增不减。JVM定期对其衰减（如每100ms减半），防止历史调用干扰当前判断。但更重要的是：C2编译不仅要看计数器数值，更要看变量行为是否“稳定”：
- 方法被调用1万次，但每次传入的参数类型不同（Object泛型擦除后实际是String/Integer混用）→ C1编译后可能长期卡在level 3，无法升级C2
- 某个局部变量在前9999次调用中都是int，第10000次突然变成double → 回边计数器虽达标，C2仍拒绝激进优化（如向量化），甚至触发去优化
- 使用final修饰或@Stable注解提示JIT该变量类型不变，能加快C2接管速度
验证变量是否受益于计数器驱动的编译
光看计数器阈值没用，得观察变量在真实编译产物中的表现：
- 加参数-XX:+PrintCompilation -XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining，看方法编译级别（level 4= C2）及内联日志中是否包含目标变量所在方法
- 用-XX:+PrintEscapeAnalysis确认变量是否被标量替换（即堆分配被消除）
- 若stats显示deoptimized count > 0，说明变量类型或控制流不稳定，导致编译成果被丢弃
