JIT 编译优化：逃逸分析与标量替换

Java 程序不是"一启动就全编译成机器码"，而是两条腿走路——解释器 + JIT 编译器的混合执行模型。

解释器逐条翻译字节码执行：启动快（省去编译等待），但每条指令都要"翻译一步再执行一步"，单条慢。JIT 编译器（Just-In-Time）把被反复执行的"热点代码"直接编译成机器码缓存起来：编译要花时间，但编译后单条指令快一个数量级。两者配合的哲学是——先让解释器带着程序跑起来，再把越跑越热的代码交给 JIT 优化。

"热点"怎么判定？靠方法调用计数器和循环回边计数器（字节码计数器）：方法被调用、或循环回边达到阈值（默认约 10000，由 -XX:CompileThreshold 控制），就触发 JIT 编译——而且是用后台编译线程异步进行，不阻塞前台执行。

JDK 8 起默认开启分层编译（Tiered Compilation），五级由低到高：

两个编译器分工明确：C1（Client）编译快、启动快，负责收集 profile；C2（Server）编译慢、优化狠，吃 C1 攒下的 profile 做激进优化。所谓 profile，就是运行期真实统计——哪个分支高频、某个虚方法实际调用到的具体类型有几个——它是一切激进优化的依据。

顺带补一个细节：方法调用计数器和回边计数器都不是"只会涨不会跌"的简单累加，而是按时间衰减的——JVM 周期性把计数减半（俗称"衰减/衰减计数器"），目的很务实：只把那些持续热、反复热的代码送进编译，避免"某段时间偶尔跑得多、之后永远冷下来"的代码白占编译产物。这个衰减设计，是编译器能长期保持"只优化真正值得优化的代码"的关键。

逃逸分析（Escape Analysis，EA）是 C2 编译阶段做的一次数据流分析，回答一个问题：某个 new 出来的对象，它的引用有没有"逃出"当前方法、甚至当前线程？分析结果决定这个对象能不能被"就地拆解"优化。三个级别：

工具上，-XX:+DoEscapeAnalysis（C2 默认开）控制开关，-XX:+PrintEscapeAnalysis（JDK 9+ 默认开）能把报告打到日志里——对象会被标记为 ESCAPED（逃逸）/ NOESCAPES（未逃逸）/ PARAMETERS（作参数逃逸）。看日志时盯这仨词即可。

对象逃不出去，C2 就敢干一件"大胆"的事：把对象拆散。一个对象本质是"一堆字段 + 一个对象头"；如果字段都是标量（int/double/reference 这类基础值）、且每个标量都不逃逸，那这个对象就不需要作为一个整体被分配到堆上——把字段拆成独立的局部变量塞进寄存器或栈槽，对象本身"消失"了。这就是标量替换。

// 源码：用一个局部 Point 计算体积的 8 倍
static int volume8() {
    Point3D p = new Point3D(2, 3, 4);   // p 只在方法内用，用完即弃 → 不逃逸
    return 8 * p.x * p.y * p.z;
}

// 优化前（近似字节码）：
    new Point3D            // 分配对象（进 Eden，见「对象创建全过程」）
    dup / invokespecial    // 构造
    getfield x:Point3D     // 读字段……
    // …… 一堆对象访问指令

// 标量替换后（近似）：new 没了，字段变成纯标量运算
    iconst_2 / iconst_3 / iconst_4   // 字段值直接当局部常量/变量
    imul ×若干                        // 纯算术，无对象分配、无字段访问
    ireturn

标量替换省掉的，正是「对象创建全过程」里那整套流程：不在 Eden 分配内存、不写对象头、不产生堆内引用——GC 的压力从源头被掐掉了。对象越多、生命周期越短（典型如纯计算中间量），收益越大：这直接减轻「JVM 堆内存」里年轻代的 Eden 分配压力。

逃逸分析的第二大应用是锁消除。逻辑很直白：一个 synchronized 块的锁对象，如果外界根本看不到它（不逃逸），那"锁"就锁了个寂寞——其他线程永远访问不到这个对象，加锁纯属浪费 CPU。C2 于是直接把 monitorenter / monitorexit 两条字节码删掉。

// 源码：方法内 new 一把锁，只为拼接（真实代码不会这么写，但 StringBuffer 就是这么干的）
public static String concat(String a, String b) {
    StringBuffer sb = new StringBuffer();   // sb 不逃逸 → 它内部的锁也没意义
    synchronized (sb) {                    // append 内部本身又有 synchronized
        sb.append(a).append(b);
    }
    return sb.toString();
}

// StringBuffer.append 是 synchronized 的，每次 append 都 monitorenter/monitorexit；
// 锁消除后：这些 monitorenter/monitorexit 被 C2 整体删掉，只剩纯粹的字符拷贝。

实用的教训：单线程局部拼接时，用 StringBuilder（无锁）而不是 StringBuffer（方法级 synchronized）。现代 JIT 通常能靠逃逸分析把 StringBuffer 的锁消除掉、追平差距，但"编译器能否帮上忙"存在不确定性——从源头写对，比赌编译器优化更可靠。

标量替换和锁消除"听起来很美"，面试和调优时都要能证明它生效。四条验证路径，从易到难：

1. javap -c 对比字节码：优化后目标方法里 new 指令消失（或锁指令消失）——最直观，能直接给面试官看。
2. JIT 日志开关：-XX:+PrintEscapeAnalysis 看对象是否标记为 NOESCAPES；-XX:+PrintInlining 看方法有没有被内联（内联是逃逸分析的前提，见下一站）。
3. GC 日志对比：标量替换生效后，Eden 分配速率下降、Young GC 次数变少——同一段负载，开/关 -XX:-DoEscapeAnalysis 各跑一遍对比「GC 日志分析」里的分配速率指标。
4. JMH 微基准：用 JMH 测吞吐。注意两点：必须充分预热（否则结果还在解释器里跑，看不到任何优化），多个 fork 消除抖动。典型纯计算微基准里，标量替换能带来数倍吞吐提升、GC 分配速率可降一个数量级——具体量级取决于负载，绝不背死数字，但"数量级"这个形容词是对的。

逃逸分析不是孤立的——它只在方法被内联进调用者之后才看得见完整的上下文。想给一个方法 m() 里的对象做标量替换，前提是 m() 已经被内联到它的调用者里：内联把"跨方法的对象流转"压平成本地代码，逃逸分析才能判断这个对象其实哪也没去。走到标量替换/锁消除之前，中间那条看不见的管线是：

内联失败，后面全断。哪些会拦路？方法体太大（超过 -XX:MaxInlineSize，默认 35 字节；热点方法 -XX:FreqInlineSize 默认放宽到 325 字节）；虚调用的多态目标太多（常见说法是目标类型 > 4 触发 megamorphic，不再内联）；递归方法；以及被反射调用的方法。这些场景里 C2 全都会退而求其次——不做内联，随之放弃标量替换和锁消除。

虚调用的内联判定有个更精细的机制值得知道：JIT 靠 profile 统计这个调用点实际出现过的具体类型，生成"多态内联缓存（PIC）"——常见形态是"如果目标是类型 A 就走 A 的内联体，是 B 就走 B，两三个都不是就责回虚分派"。当 profile 显示目标类型稳定在少数几个，内联就成立；一旦目标类型激增（megamorphic，巨多态），缓存价值归零，JIT 放弃内联。这也是"面向接口写代码虽好，但过度抽象让调用点巨多态反而伤 JIT"这层权衡的技术根源。

逃逸分析不是万能的，边界很多，全是追问密集区：

1. 对象一旦赋给字段 / 作为返回值，就逃逸了——调用者可能持着它传给别人，编译器不能赌它只有一个消费者。
2. 对象参与"身份类"操作：== 比较、identityHashCode、synchronized、序列化、反射调用——这些依赖"这个对象以整体身份存在"，拆了就改语义，编译器只能保守放弃。
3. C1 不做逃逸分析：只有 C2 做。所以分层编译的头几秒（还在 C1/解释层），看不到标量替换的效果。
4. 反优化（deoptimization）会撤销：逃逸分析是"编译期假设"，一旦运行期 profile 推翻假设（多态点变多、新类被加载、内联失效），C2 会退回解释执行重新观察（-XX:+Deoptimization 默认开）。所以优化不是一次性买断，而是随 profile 动态进退。
5. 逃逸分析 ≠ 对象池：字符串常量池、Integer 缓存（-128~127）是"复用已有对象"的缓存机制，与逃逸分析"让对象不再分配"完全是两回事。

关于第 4 条"反优化"，再点透一点：反优化不是"编译错了回炉"，而是一个有 safepoint 协作的正式机制——当运行期观测（比如 profile 里多态目标数量飙升、或新类被加载改写了继承关系）推翻了编译时假设，JVM 会等到一个安全点（safepoint），把对应栈帧从"机器码状态"安全地搬回"解释器状态"，继续以解释方式执行，并重新采集 profile。代价是"已优化的机器码作废 + 一段时间解释执行变慢"，换来的是语义永远正确。理解了它是"优化可以被撤销"，才不会被"JIT 优化一次就永久生效"这类坑问倒。

面试回答模板

高频追问表