Java JIT分层编译：C1和C2怎么配合

可视化演示

展示JIT五层编译体系代码热度晋升、C1快速编译与C2峰值优化性能对比，以及OSR栈上替换在循环执行中切换编译版本过程。

JIT基本认知——先从实习生说起

走进 HotSpot 餐厅的后厨，你会看到一名实习生正捧着菜谱，一个字一个字地念：“放油……热锅……下葱花……”。他每做一道菜都要现查菜谱，速度虽然慢，但胜在什么菜都能做、从不撂挑子。这个实习生，就是 JVM 里的解释器（Interpreter）：任何字节码它都能逐条翻译执行，灵活但缓慢。

可餐厅生意火爆，若让实习生包办一切，客人早就饿跑了。老板细心观察发现，翻台率高的其实就那么十来道招牌菜。于是他请来一位快餐主厨，把热门菜的做法提前背熟、提炼成快捷卡，点单时直接照着卡片出菜。这个“把菜谱预先变成标准动作”的过程，就是 JIT 编译（Just-In-Time Compilation，即时编译）。

具体到 JVM：方法以字节码形式存在，解释器负责“照本宣科”地执行；当某个方法被反复调用、成为热点方法（Hot Method）时，JIT 就把它的字节码整体编译成机器码并缓存。编译完成后，每次调用直接跑机器码，免去逐条翻译的开销。于是程序“先跑起来，再越跑越快”，整体耗时被拆成三块：

聪明的老板绝不会给每道菜都配快捷卡——墙上的卡片太多反而占地方；JVM 也一样，它只挑“点单率高”的方法做深度优化。解释器保证下限，JIT 拉高上限，这正是 JVM“先跑起来、再变快”的设计哲学，也是后面一切故事的起点。

C1与C2分工——快餐主厨与米其林主厨

如果只有一位快餐主厨，生意还能做得更大吗？老板的答案是：还不够。快餐主厨的快手做法虽然快，但为了速度牺牲了火候与摆盘；真正让老饕们排队的，是那位米其林主厨——他肯花一个下午研究食材的化学反应，把一道红烧肉做到入口即化。于是后厨有了两位大师傅：一位求快，一位求极致。

在 JVM 中，这两位对应两个编译器的角色。C1 编译器（Client Compiler）追求编译速度：它用简单保守的优化，几十毫秒就能把方法编译完，让程序尽快脱离解释器的慢速执行；C2 编译器（Server Compiler）追求执行极致：它做大量激进优化（如方法内联、循环展开、逃逸分析），单个方法可能编译几百毫秒甚至更久，但产出的机器码执行效率极高。

两者是典型的“用编译时间换运行时间”的权衡：

回到餐厅：如果每次点单都请米其林主厨亲自做，客人等得花儿都谢了；如果只让快餐主厨应付，又留不住老饕。所以老板立下规矩——普通菜让实习生快手应付，热门菜升级给快餐主厨，只有最火爆的招牌菜，才值得米其林主厨闭关修炼。这套“分级上菜”的制度，就是 JVM 的分层编译（Tiered Compilation）。

分层五层级——厨房里的五级晋升通道

餐厅后厨可以简单分成“实习生、快餐主厨、米其林主厨”三级，但真正的 JVM 分得更细——它把协作拆成了五个层级（Tier 0 到 Tier 4），每一层代表一种“编译深度”。层数越高，优化越激进，但代价也越高。

第 0 层是纯粹的解释执行，也就是实习生模式，任何方法都能跑。第 1 层是 C1 的简单编译（Simple C1），不带性能分析信息，适合“有点热但要求不高”的方法。第 2 层是受限的 C1 编译（Limited C1），启用部分性能分析，编译又快又能为后续升级留数据。第 3 层是完整的 C1 编译（Full C1），带完整的性能分析（Profiling），相当于快餐主厨边做菜边记录客人的口味偏好。第 4 层是 C2 编译，米其林主厨闭关，利用前几层收集的分析数据做最激进的优化。

这套五层模型是 HotSpot 分层编译的精华：C1 的三种模式让“快餐主厨”既能快速出菜，又能为“米其林主厨”收集食客口味数据；而带上完整画像的第 3 层，让 C2 一开始就知道该在哪些地方发力，不必盲目试探。可以说，C1 不只是 C2 的廉价替代品，更是 C2 的情报员。

用一句话收束：餐厅的晋升通道里，实习生管全面、快餐主厨管速度、米其林主厨管极致；而五层阶梯，就是这套协作的精细化制度设计。理解了层级，队列、OSR、参数调优这些都成了制度的配套设施。

热度计数机制——点单本上的正字与颠勺次数

后厨凭什么决定一道菜该由谁来做？答案藏在两本账里。第一本是前台点单本：每被客人点一次，就在菜名后面画一笔正字——这是“方法调用计数”（Invocation Counter）。第二本是后厨的工序记录：厨师炒菜时来回颠锅的次数——这是“回边计数”（Back Edge Counter），对应方法内部循环体执行完一圈又跳回循环头的次数。

JVM 为每个方法维护这两个计数器。每当方法被调用，调用计数加一；每执行完一次循环回边，回边计数加一。二者的总和就是该方法的“热度”（Hotness）。当热度超过某个阈值，JVM 就触发对应层级的编译。

这里有一个易被忽略的细节：如果热点藏在循环里——方法本身只被调用一次，但循环跑了百万遍——调用计数根本不够看。为此 JVM 引入了回边计数的补偿机制：当回边计数达到阈值时，会在方法执行到一半时启动“OSR 编译”（On-Stack Replacement，栈上替换），即把执行状态迁移到编译好的新版本上继续跑，无须等整个方法结束。

类比后厨：一道炖菜正炖到一半，实习生接到指令临时换米其林主厨接手。麻烦的是菜不能倒掉重做——OSR 的妙处恰恰是“锅不换，人换”：编译器在后台把菜谱升级好，运行中的方法在下一次循环回边时无缝切到新版本。这样，长循环方法也能享受到 C2 的极致优化。

预热与启动——开业酬宾的学问

新餐厅开业前，老板总要办几场“试营业”：请亲友团来点菜，让后厨系统运转起来，等大家熟悉流程后再正式迎客。Java 程序也有同样的“试营业”——预热（Warmup）。程序刚启动时，热点方法还没来得及被编译，吞吐低得出奇；跑一段时间后，JIT 逐渐把热点方法升到高层级，性能才进入稳态。

预热的快慢取决于三件事：热点方法的数量、编译阈值的高低、编译线程的多少。如果把每个方法从解释执行到完成编译看作一次“升级流程”，预热总耗时大致可以估算：

对启动敏感的场景（如无服务器函数、容器弹性扩缩容），通常的策略是“牺牲一点峰值，换启动速度”——比如把分层编译停在 C1 层，或用 AOT 提前把常用方法编译好。对长期运行的在线服务，则反过来：耐心等待预热，甚至主动在发布流量进来前用压测流量“预热”一遍，让 C2 提前进入状态。

回到餐厅：开业酬宾那天，老板不会让米其林主厨把整本菜单都研发一遍——那得等到打烊。他只会挑估计会爆火的菜提前备好快捷卡，其他的等真正被点爆了再说。预热的本质，就是用最合理的编译资源，让“上菜速度”尽快追上客流。

参数调优实战——后厨排班表怎么改

老板掌管后厨，手里有几张可以随时改的“排班表”——JVM 也提供了一批和分层编译相关的参数。最核心的是编译阈值：-XX:CompileThreshold 决定方法热度达到多少才触发编译（默认约 10000 次）；而回边数触发的 OSR 编译阈值，则由它乘以一个百分比得出：

其他常用旋钮：-XX:TieredStopAtLevel=1 表示把编译停在 1 层，即只用轻量 C1、不做 C2 优化，适合格外在意启动速度的场景；-XX:CICompilerCount 设置 C1 与 C2 的编译线程总数，默认约为 CPU 核数的一半；-XX:+PrintCompilation 打开后，JVM 会打印每一条编译记录，是诊断 JIT 行为最直接的“监控探头”。

调优最忌讳“盲改”。正确姿势是：先用 PrintCompilation 或 JFR（Java Flight Recorder）观察热点方法的编译层级与时间线，确认瓶颈是“热得不够快”还是“热了没编译到位”，再针对性调整阈值与线程数。改完一定要在真实流量下复测启动时长和稳态吞吐，因为这两个指标常常此消彼长。

后厨排班同理：客人少时多排实习生省钱，客流高峰前临时加派主厨。离开了对客流（热点）的判断，任何排班表都是纸上谈兵。调优的本质，是让编译资源跟着真实热度走，而不是拍脑袋调参数。

现代编译器展望——新派主厨 Graal

米其林主厨再厉害，也有厨艺上限。在 JVM 的世界里，C2 编译器已经服役二十多年，代码庞大而难以维护。于是 Oracle 与社区联手培养了一位“新派主厨”——Graal 编译器。它用 Java 语言编写、以 JIT 形式运行，通过标准接口 JVMCI（JVM Compiler Interface）与 HotSpot 对接，可以整体替换 C2。

Graal 的亮点在于更现代的优化管线：更好的逃逸分析、更智能的内联决策，以及更活跃的实验特性。不过它并不是默认开启——需要显式加上 -XX:+UseJVMCICompiler。对大多数线上系统，默认的 C2 依然是最稳的选择；而对追求极限性能、愿意冒险换“新主厨”的团队，Graal 提供了另一条路。

此外，Java 也在尝试“备菜前置”的 AOT 编译（如 GraalVM Native Image 与 Leyden 项目）：与其开业后慢慢备菜，不如在开业前就把招牌菜做成半成品，运行时直接加热。这会大幅缩短启动与预热时间，代价是失去部分基于运行时反馈的动态优化能力。

从实习生到快餐主厨，从米其林主厨到新派主厨——JVM 的性能故事，始终是“用最合适的人，做最合适的活”。理解分层编译，你就拿到了理解这套体系的总钥匙：无论未来编译器怎么换，热度采样、层级递进、编译分工的思想都不会过时。

AI 应用场景

Python 演示

import random  class HotMethod:    """模拟一个被反复调用的热点方法（餐厅的招牌菜）"""     def __init__(self, name, c1_threshold=30, c2_threshold=80):        self.name = name        self.c1_threshold = c1_threshold        self.c2_threshold = c2_threshold        self.invoke_count = 0        self.loop_edges = 0        self.tier = 0        self.samples = []     def call(self, loop_iterations=1000):        """调用一次：同时增加调用计数和回边计数"""        self.invoke_count += 1        self.loop_edges += loop_iterations        self._update_tier()        self.samples.append(self._measure())     def _update_tier(self):        """根据热度（调用 + 回边）决定当前编译层级"""        hotness = self.invoke_count + self.loop_edges // 1000        if hotness >= self.c2_threshold:            self.tier = 4          # 米其林主厨 C2 接管        elif hotness >= self.c1_threshold:            self.tier = 3          # 快餐主厨 C1 完整版接管     def _measure(self):        """不同层级下每次调用的耗时（毫秒），层级越高越快"""        base = [5.0, 3.0, 2.0, 1.2, 0.3]        return base[self.tier] + random.uniform(0, 0.1)     def simulate(self, n_calls):        for _ in range(n_calls):            self.call()        return self.samples  def main():    dish = HotMethod("getUserById", c1_threshold=30, c2_threshold=80)    samples = dish.simulate(200)     first_avg = sum(samples[:20]) / 20    last_avg = sum(samples[-20:]) / 20    print(f"方法: {dish.name}")    print(f"调用次数: {dish.invoke_count}, 回边计数: {dish.loop_edges}")    print(f"最终编译层级: 第 {dish.tier} 层 (4 表示 C2)")    print(f"前 20 次平均耗时: {first_avg:.2f} ms")    print(f"后 20 次平均耗时: {last_avg:.2f} ms")    print(f"峰值加速比: {first_avg / last_avg:.1f} 倍")  if __name__ == "__main__":    main()

1. hotness = self.invoke_count + self.loop_edges // 1000复现“热度 = 调用计数 + 回边计数”的核心公式
2. if hotness >= self.c2_threshold: self.tier = 4热度达标后 C2 接管，相当于米其林主厨出手
3. elif hotness >= self.c1_threshold: self.tier = 3次高热度先由完整版 C1 顶住
4. base = [5.0, 3.0, 2.0, 1.2, 0.3]五个层级对应不同单位耗时，层级越高越快
5. random.uniform(0, 0.1)模拟真实世界中每次执行的微小抖动
6. first_avg / last_avg用前 20 次与后 20 次耗时之比，量化预热带来的峰值加速比

常见误区

面试题