JIT 与逃逸分析：先解释、边跑边记，热了再按记下的情况大胆编译；逃逸分析靠内联才看得见，看见了，new 就不进堆

缺的是两样：只给热的代码花大力气编译（冷代码解释就够，编译它不划算），以及编译时能看穿方法调用，知道一个对象是不是只在这一小段代码里用。前者是分层编译，后者是“内联 + 逃逸分析”。不懂这一点的典型误用：为了“省 GC”给 Money 这种小对象做对象池，结果对象全变成长寿的、进了老年代，还得自己处理并发，比让 C2 标量替换掉慢得多；见 ⑥ 误区 1。

选择规则：长期运行的后端服务，峰值吞吐最要紧，用默认的 JIT 分层编译，把“要预热”当成发布流程的一部分处理；冷启动比峰值重要的（命令行工具、函数计算、频繁扩缩容的小服务），考虑 Native Image 或 AOT 缓存。本页学 HotSpot 的分层编译，和 C2 里最影响你写代码方式的两件事：内联和逃逸分析。

④-1 分层编译：一个方法从冷到热，换三次“身体”

为什么要三层，不直接上 C2：C2 编一个方法要几毫秒到几十毫秒、还要一份足够长的 profile，C1 编得快一个量级。先用 C1 让代码“快起来”，同时让 3 级代码继续记 profile，攒够了再交给 C2。编译在后台的编译线程里做（本机 2 核，CICompilerCount=2：C1、C2 各一个），业务线程不用等，期间照常跑旧版本。⑤ 的 -XX:+PrintCompilation 里能看到 priceOf 先出现 3 级，再出现 4 级，接着 3 级那版被标成 made not entrant（不再给新调用用）。

④-2 内联和去虚化：C2 先把调用“抹平”，后面的优化才看得见

Money unit = new Money(BASE[sku & 1023]);
return unit.times(qty)
           .off(qty >= 10 ? 5 : 0)
           .cents;

long c1 = BASE[sku & 1023];   // unit.cents
long c2 = c1 * qty;           // times() 的 new 没了
int  p  = qty >= 10 ? 5 : 0;
long c3 = c2 * (100 - p) / 100; // off() 的 new 没了
return c3;                    // 0 次分配

内联本身省的是一次调用的开销，几个纳秒；它真正值钱的地方是让 C2 能把调用方和被调用方放在一起看，常量传播、去掉多余的检查、逃逸分析都要在这之后才做得成。所以 JIT 时代的“小方法、多层调用”并不慢；被调用的方法大到内联不进来，或者调用点见过太多实现，后面的优化才会一起丢掉。

④-3 逃逸分析：对象有三种结局，只有一种能不进堆

逃逸判定台选一种写法，先猜进不进堆，再看本机实测

数字来自 ⑤ 的 Escape：每种写法先预热 300 万次，再量 1000 万次，取每次的平均分配字节。本机 2 核 ARM，JDK 17.0.20.1。

④-4 推测和去优化：C2 敢赌，是因为输了能退回去

为什么这样设计：编译放在运行时，而不是构建时

决定胜负的约束：Java 是动态的（虚方法默认可重写、类可以运行时加载），而后端服务一跑就是几天。动态让静态编译只能保守，长期运行又让“前几十秒慢一点”摊得很薄。冷启动成了瓶颈的场景（Serverless、弹性扩容），这个账就要重算，这正是 Native Image 和 JDK 24 起 AOT 缓存出现的原因。

基本用法：看 JIT 在干什么的几条参数

-XX:+PrintCompilation                // 每编一个方法打一行：级别、% 表示 OSR、made not entrant
-XX:TieredStopAtLevel=1              // 只用 C1（启动快、峰值低）
-Xint                                // 只解释，对照用
-XX:-DoEscapeAnalysis                // 关掉逃逸分析，对照用
-XX:-OmitStackTraceInFastThrow       // 热点异常也保留堆栈（⑥ 坑 1）
jcmd <pid> Compiler.codecache         // 代码缓存用了多少
jcmd <pid> Compiler.queue             // 编译队列里排着谁
-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining   // 每个调用点内联没有、为什么

阈值、内联大小这些参数为什么一般不该动，放到 ⑥ 第三圈。JMH 怎么写也在 ⑥。

cd java && JAVA_HOME=/usr/lib/jvm/java-17-openjdk-arm64 mvn -q -pl jvm/jvm-jit-escape compile
cd jvm/jvm-jit-escape && J=/usr/lib/jvm/java-17-openjdk-arm64/bin/java; M=labs.jvm.jvm_jit_escape
$J -cp target/classes $M.Warmup                                   # 1. 预热曲线
$J -XX:+PrintCompilation -Dbatches=3 -cp target/classes $M.Warmup | grep -E "priceOf|batch|Money"
$J -cp target/classes $M.Escape                                   # 2. 八种写法进不进堆
$J -XX:-DoEscapeAnalysis -cp target/classes $M.Escape
$J -cp target/classes $M.Myths                                    # 3. 两个误区
$J -XX:-OmitStackTraceInFastThrow -cp target/classes $M.Myths

1. 预热：第一批 20 万次就完成了从解释到 C2

$ java … Warmup
批  1     24.7 ns/次    6.1 B/次  累计   30.5 ms
批  2      4.1 ns/次    0.0 B/次  累计   46.9 ms
批  3      8.5 ns/次    0.0 B/次  累计   49.1 ms
批  4      3.7 ns/次    0.0 B/次  累计   50.4 ms
批 10      3.7 ns/次    0.0 B/次  累计   58.7 ms
批 30      3.7 ns/次    0.0 B/次  累计   84.0 ms
$ java -Xint … Warmup
批  1    359.6 ns/次   72.0 B/次  累计   94.1 ms
批  5    353.1 ns/次   72.0 B/次  累计  395.0 ms

$ java -XX:+PrintCompilation … | grep …
时间ms 编号  级别
68   69       3   Money::off (22 bytes)
69   67       3   Warmup::priceOf (40 bytes)
69   66       2   Money::<init> (10 bytes)
69   70       4   Warmup::priceOf (40 bytes)
70   67       3   Warmup::priceOf   made not entrant
71   73 %     3   Warmup::batch @ 5 (36 bytes)
72   75 %     4   Warmup::batch @ 5 (36 bytes)
93  143       4   Warmup::batch (36 bytes)

读法：第 1 批的 6.1 B/次说明，这 20 万次里大约前 8% 还在解释器和 C1 里跑（6.1 ÷ 72）；从第 2 批起 0 字节。右边，priceOf 在 69 ms 时先被 C1 编成 3 级，几乎同时进了 C2 的 4 级，3 级那版随即作废；% 是 OSR：@ 5 是循环头所在的字节码偏移，batch 的循环转到一半就被换成了编译版，没等它返回。第 3 批 8.5 ns 的那一下，和 93 ms 时 batch 被整个重新编译的时刻对得上。

2. 八种写法，哪些 new 真的发生了

$ java … Escape                 （默认）
A 只在方法里用                   0.0 B/次
B 被返回                        24.0 B/次
C 存进静态字段                   24.0 B/次
D 传参·调用点只见过 1 种实现       0.0 B/次
E 传参·调用点见过 3 种实现        24.0 B/次
F 两条分支各 new 再合流           24.0 B/次
G 小数组 long[4]                 0.0 B/次
H 大数组 long[100]              816.0 B/次

$ java -XX:-DoEscapeAnalysis … Escape
A 只在方法里用                  48.0 B/次
B 被返回                        24.0 B/次
C 存进静态字段                   24.0 B/次
D 传参·调用点只见过 1 种实现      24.0 B/次
E 传参·调用点见过 3 种实现        24.0 B/次
F 两条分支各 new 再合流           24.0 B/次
G 小数组 long[4]                  0.0 B/次
H 大数组 long[100]              816.0 B/次

D 和 E 调的是同一个接口、同样的 fee 方法，区别只在调用点的 profile（④-2）。A 关掉 EA 是 48 B：m 和 m.times(2) 两个对象。G 关掉 EA 也是 0 B，这一条和逃逸分析无关：数组的读写在编译时就被折叠成常量，数组成了没人用的死代码，被直接删掉（按现象推断，没有对照编译日志）。这八行就是 ④-3 判定台里的数字。

3. 两个误区，现场看

① 手写微基准（每轮 5000 万次 priceOf）
第 1 轮  结果丢掉    6.47 ms   结果用上   77.09 ms
第 2 轮  结果丢掉    1.37 ms   结果用上   72.01 ms
第 3 轮  结果丢掉    0.00 ms   结果用上   67.65 ms
第 5 轮  结果丢掉    0.00 ms   结果用上   67.05 ms

② 同一行代码反复 NPE：异常的堆栈有几层
第 1 次：2 层，message=Cannot read field "code"
         because "o.coupon" is null
第 6761 次起：0 层，message=null
$ java -XX:-OmitStackTraceInFastThrow …
20 万次里堆栈一直都在

左边：discard 把 priceOf 的结果丢掉，C2 内联后发现整个循环没有任何可见效果，就把它删了，5000 万次“0.00 ms”。拿这种数字说“X 比 Y 快 1000 倍”，测的是编译器有多聪明。右边：同一个位置 NPE 抛了几千次以后，C2 编译的版本改抛一个预先建好的 NPE，没有堆栈、没有 message。

常见的性能误区

版本差异

下一圈

• JMH 实战：@State、Blackhole、@Fork，以及用 -prof gc、-prof perfasm 看分配和热点汇编
• JITWatch 读 -XX:+LogCompilation：看清每个方法的内联树和去优化原因
• C2 的循环优化：范围检查消除、循环展开、自动向量化，以及 Vector API
• JDK 24 / 25 的 AOT 缓存实测：训练运行怎么做，启动和预热时间各省多少
• GraalVM：Graal JIT 的部分逃逸分析，和 Native Image 的封闭世界假设
• JVM 故障排查（全景第 9 站，下一个知识点）：CPU 飙高时，怎么分清是业务代码、GC 还是编译线程

自测