JVM 即时编译深度解析：C1/C2、分层编译、OSR 与日志分析

优势：

• 启动快：初期用 C1 快速编译，应用快速响应
• 峰值性能高：热点代码逐步升级到 C2 优化
• 精准优化：基于 Profiling 数据做针对性优化

2.2 五级编译层次详解

注：阈值可通过 -XX:TierXCompileThreshold 调整

Level 0：解释执行

• 所有方法初始状态
• 热点探测：收集方法调用计数器和循环回边计数器
• 示例：

public static void main(String[] args) {
    for (int i = 0; i < 30000; i++) {
        process(i); // 调用 30000 次，触发编译升级
    }
}

Level 1：C1 简单编译

• 适用方法：简单 Getter/Setter、无循环/分支的方法
• 优化：基础内联、常量折叠
• 特点：不插入 Profiling 代码，代码体积小，执行快

Level 2：C1 受限编译

• 触发条件：C2 编译队列已满
• 目标：快速编译以提高性能，避免方法长时间解释执行
• 后续会重新编译为 Level 3/4

Level 3：C1 完全 Profiling

• 插入 Profiling：记录方法调用次数、分支跳转频率、类型继承关系
• 数据用途：为 C2 提供精确优化依据
• 开销：Profiling 代码有一定性能损耗

Level 4：C2 激进优化

• 优化策略：
  • 方法内联：基于调用频率内联热点方法
  • 去虚拟化：根据 Profiling 发现 a.b() 总是调用 ClassA.b()，消除虚方法调用
  • 分支预测：优先编译热点分支
  • 逃逸分析：栈上分配对象，减少 GC 压力
• 去优化（Deoptimization）：若 Profiling 假设失效（如内联的类型变更），退回到 Level 0 重新收集

2.3 分层编译协作流程

方法调用 → Level 0 解释 → 计数达标 → Level 1 C1 编译 → Level 3 C1+Profiling → Level 4 C2 优化 ↓ C2 队列满 → Level 2 C1 受限编译 ↓ 假设失效 → Deoptimization → 回到 Level 0 

关键机制：

• 逆优化（Deoptimization）：当 C2 的激进优化假设被打破（如内联的类型被替换），JVM 会退回到解释执行，重新收集 Profiling 数据后再次编译
• 代码缓存：编译后的机器码存储在Code Cache（默认 240MB，可通过 -XX:ReservedCodeCacheSize 调整）

三、栈上替换（OSR - On-Stack Replacement）

3.1 OSR 定义

在方法执行过程中替换其正在执行的栈帧，主要解决长循环的优化问题。

场景：main 方法执行很长时间，内部循环体是热点，但方法本身调用次数不足，无法触发编译。

3.2 OSR 触发机制

public static void main(String[] args) {
    long sum = 0;
    for (int i = 0; i < 1_000_000_000; i++) {
        sum += i; // 循环回边计数器递增
                  // i 达到阈值后，触发 OSR 编译
    }
}

• 循环回边计数器：每次循环末尾 i++ 触发
• 阈值：-XX:OnStackReplacePercentage=140（默认值，基于 CompileThreshold 计算）

3.3 OSR 编译日志特征

1234 567 % 3 com.example.Main::main @ 10 (58 bytes) # %表示 OSR # @ 10 表示从字节码偏移量 10 处开始 OSR 

3.4 OSR vs 正常编译

• 正常编译：替换整个方法的入口
• OSR：替换方法内部特定位置的栈帧，保留当前执行上下文

四、PrintCompilation 日志分析实战

4.1 开启编译日志

# 基础日志（时间戳、编译 ID、层级、方法名）
-XX:+PrintCompilation
# 详细日志（包含字节码大小、属性标记）
-XX:+PrintCompilation
-XX:+UnlockDiagnosticVMOptions
-XX:+PrintInlining

4.2 日志格式解析

基础格式：

时间戳 编译 ID 属性 层级 类名::方法名 (字节码大小)
1234 567 % 3 com.example.Main::main @ 10 (58 bytes)

字段详解：

4.3 实战日志分析

示例代码：

public class TieredCompilation {
    public static void main(String[] args) {
        for (int i = 0; i < 30000; i++) {
            process(i);
        }
    }

    private static void process(int value) {
        // 模拟业务逻辑
        int sum = value * 2 + value;
        System.out.println(sum);
    }
}

编译日志输出：

1023 788 1 com.example.Article::getName (5 bytes) ← Level 1 编译
1025 789 1 com.example.Article::getAuthor (5 bytes)
1032 800 3 com.example.JsonFormatter::<init> (5 bytes) ← Level 3 编译
1032 801 3 com.example.Article::<init> (15 bytes)
1041 820 3 com.example.JsonFormatter::format (8 bytes)
1122 903 4 com.example.JsonFormatter::<init> (5 bytes) ← Level 4 编译
1123 800 3 com.example.JsonFormatter::<init> (5 bytes) made not entrant ← 旧版本失效
1123 904 4 com.example.Article::<init> (15 bytes)
1124 801 3 com.example.Article::<init> (15 bytes) made not entrant
1132 932 % 3 com.example.TieredCompilation::main @ 2 (58 bytes) ← OSR 编译
1133 933 3 com.example.TieredCompilation::main (58 bytes)
1144 940 % 4 com.example.TieredCompilation::main @ 2 (58 bytes) ← OSR 升级到 Level 4
1145 932 % 3 com.example.TieredCompilation::main @ 2 (58 bytes) made not entrant

日志解读：

1. Level 1：getName/getAuthor 简单方法，编译后代码体积 5 字节
2. Level 3：构造函数 <init> 和业务方法 format，开始 Profiling
3. Level 4：C2 重新编译 <init>，Level 3 版本标记为 made not entrant（不可进入）
4. OSR 编译：main 方法因循环次数多触发 OSR，先 Level 3 后升级到 Level 4

made not entrant 含义：旧版本编译代码已被废弃，但可能仍有线程在执行，待执行完成后彻底回收

4.4 关键日志场景

场景 1：Deoptimization（逆优化）

1234 567 4 com.example.Service::process (100 bytes)
2345 567 4 com.example.Service::process (100 bytes) made not entrant

• 第二行表示假设失效，C2 优化被撤销，退回到解释执行

场景 2：编译失败

1234 567 ! 3 com.example.Service::process (100 bytes) # ! 表示方法有异常处理器，可能影响优化 

4.5 性能分析

高频编译问题：若某方法反复编译（Level 3→4→3→4），说明 Deoptimization 严重，需检查代码：

• 类型不稳定：方法入参实际类型多变
• 分支预测失败：热点分支数据不收敛

编译耗时估算：

• Level 1：<1ms
• Level 3：5-20ms
• Level 4：50-500ms（取决于方法复杂度）

优化建议：避免在应用启动初期调用复杂方法（如 main 中初始化），否则会导致启动慢，因为 C2 编译阻塞执行。

五、编译器调优参数

5.1 分层编译控制

# 禁用分层编译（不推荐，除非调试）
-XX:-TieredCompilation
# 强制 C2 编译阈值（默认 10000）
-XX:Tier4CompileThreshold=5000 # 更早触发 C2
# 强制 C1 编译阈值（默认 1500）
-XX:Tier3CompileThreshold=1000 # OSR 阈值调整
-XX:OnStackReplacePercentage=140 # 默认 140
-XX:CompileThreshold=10000 # OSR 触发 = CompileThreshold * (OnStackReplacePercentage / 100)

5.2 Code Cache 调优

# Code Cache 默认 240MB（32 位 JVM 48MB）
-XX:ReservedCodeCacheSize=512m # 大规模应用需增大
-XX:InitialCodeCacheSize=64m # 监控 Code Cache 使用率
jcmd <pid> Compiler.codecache 

Code Cache 溢出后果：无法编译新热点方法，性能回退到解释执行

5.3 编译线程调优

# C2 编译线程数（默认 CPU 核数）
-XX:CICompilerCount=4
# 编译队列大小
-XX:CompilerThreadPriority=10

线程拥堵表现：热点方法长时间停留在解释执行，吞吐量下降

六、最佳实践与避坑

6.1 启动性能优化

# 激进编译阈值，加快启动
-XX:Tier4CompileThreshold=5000
# 但可能导致过早编译，Profiling 数据不足

推荐：保持默认值，除非压测证明有益

6.2 避免去优化

// 错误：类型不稳定导致 Deopt
public void process(Object obj) {
    if (obj instanceof String) { // 90% 情况走这里
    } else if (obj instanceof Integer) { // 10% 情况
    }
}
// C2 内联 String 分支后，突然传入 Integer，触发 Deopt
// 优化：接口隔离
public void processString(String s) {}
public void processInteger(Integer i) {}

6.3 分析热点代码

# JITWatch 工具（基于 PrintCompilation 日志）
java -XX:+UnlockDiagnosticVMOptions
-XX:+TraceClassLoading
-XX:+LogCompilation
-XX:LogFile=/tmp/jit.log # 配合 JITWatch GUI 查看

6.4 编译诊断

# 查看编译队列
jcmd <pid> Compiler.queue
# 查看已编译方法
jcmd <pid> Compiler.codelist
# 查看编译器线程
jstack <pid> | grep "C1/C2 CompilerThread"

总结

核心要点

• C1 vs C2：快速启动 vs 峰值性能
• 分层编译：0→1→3→4 的渐进优化，自动平衡
• OSR：解决长循环优化问题，% 标记识别
• 日志分析：时间戳、层级、made not entrant 是关键

调优口诀

启动慢降阈值，性能差升层级
Deopt 要避免，类型需稳定
Cache 别溢出，线程莫拥堵

掌握 JIT 编译机制，能让你在性能调优时有的放矢，编写出更 JVM 友好的代码。