JIT 如何优化 Java 代码？从方法内联到逃逸分析与去优化
Java 源码先编译成字节码，但生产运行时真正执行的并不总是解释器。HotSpot 会观察程序行为，把热点方法编译为针对当前运行状态优化的机器码；当曾经成立的假设失效时，它还会撤销优化，回到解释执行或重新编译。这套“基于运行时证据的推测优化”正是 JIT 的核心。
1. 为什么不能一启动就做最高级优化
启动阶段 JVM 不知道哪些方法最热、接口调用的真实实现是谁、分支通常走哪一边。立即对所有代码做昂贵优化，会拖慢启动并浪费代码缓存。
HotSpot 因此采用分层编译：解释器快速启动并收集计数与类型画像，C1 编译器较快地产生机器码，C2 对足够热的代码做更激进优化。不同 JDK 和运行模式的层级细节可能变化，但“先收集画像，再优化热点”的思想不变。
观察编译事件可以使用：
-XX:+PrintCompilation
-Xlog:compilation*=debug生产分析更推荐 JFR、JITWatch 或目标 JDK 支持的统一日志，避免海量输出影响服务。
2. 方法内联是许多优化的入口
假设循环中调用一个很小的方法：
static int square(int x) {
return x * x;
}
for (int i = 0; i < values.length; i++) {
sum += square(values[i]);
}内联后，调用边界被消除，JIT 可以继续做常量传播、范围检查消除和循环优化。内联的价值不只是省一次方法调用，而是扩大优化视野。
但并非越大越好。机器码膨胀会占用 Code Cache、降低指令缓存命中率，并增加编译时间。HotSpot 会根据方法大小、调用热度、调用点类型画像和编译层级决定是否内联。
3. 虚调用也可能被优化
面向接口编程看似意味着每次都要动态查找实现：
interface PriceRule { long apply(long price); }
long calculate(PriceRule rule, long price) {
return rule.apply(price);
}如果运行画像显示某调用点长期只出现一种实现，JIT 可以推测它是单态调用，插入类型检查后内联目标实现。若后来加载或传入新实现，假设失效，JVM 会触发去优化。
因此性能测试必须包含真实实现分布。微基准永远只传一种实现，可能得到比生产多态场景乐观得多的结果。
4. 逃逸分析与标量替换
对象创建不一定意味着真实堆分配：
static int distance(int x, int y) {
Point p = new Point(x, y);
return p.x() * p.x() + p.y() * p.y();
}若 JIT 证明 p 不会逃出当前编译范围，便可能把它拆成两个标量值，完全消除对象分配。这叫标量替换。常说的“栈上分配”容易造成误解：最终结果可能是对象根本不存在，而不只是从堆搬到栈。
逃逸分析还可能支持锁消除。若同步对象只在当前线程可见，其监视器没有并发意义，JIT 可以移除锁操作。
不过分析有边界：复杂控制流、无法内联的调用、对象写入字段、返回给调用者或传给未知代码，都可能阻止优化。不能把“理论上可消除”当成 JVM 保证。
5. 循环与范围检查优化
Java 数组访问必须做边界检查，但 JIT 可以证明某些循环索引始终合法，从而把重复检查移出循环或消除：
for (int i = 0; i < data.length; i++) {
total += data[i];
}如果循环结构复杂、长度在循环中变化或访问模式不规则，证明可能失败。手工“优化”成更晦涩的代码并不一定更快，甚至可能破坏 JIT 已能识别的标准模式。
6. 去优化不是异常，而是设计能力
JIT 生成代码时会记录恢复解释器状态所需的信息。当类层次变化、类型推测失败或遇到不常见分支时，执行可以从优化机器码退回解释器，这称为 deoptimization。
解释执行并收集画像
-> 热点编译
-> 基于单态调用等假设优化
-> 新类型出现，假设失效
-> 去优化
-> 收集新画像并重新编译偶发去优化很正常；持续反复编译与去优化则可能造成 CPU 抖动和延迟尖峰，需要结合 JFR、编译日志与代码缓存指标分析。
7. 为什么普通计时容易测错
下面的测试不可靠：
long start = System.nanoTime();
for (int i = 0; i < 1_000_000; i++) {
calculate();
}
System.out.println(System.nanoTime() - start);它混入类加载、解释执行和编译过程；若结果未被使用，整个计算还可能被死代码消除。正确做法是使用 JMH，让框架处理预热、分叉进程、结果消费与统计：
@Benchmark
public int calculateBenchmark() {
return service.calculate(input);
}JMH 也无法自动保证场景真实。参数分布、对象生命周期、线程竞争和多态程度仍需由测试设计者还原。
8. 观察优化证据
可按风险从低到高使用：
- JFR：观察编译、Code Cache、对象分配和锁事件；
-XX:+PrintCompilation：查看方法何时进入不同编译层级；- JITWatch：关联字节码、内联决策与汇编；
-XX:+PrintInlining等诊断参数：仅在受控环境使用；- Linux
perf、async-profiler：确认 CPU 最终消耗在哪段机器码。
查看汇编通常需要额外反汇编库。即使能看到汇编，也应先有性能现象和假设，否则容易在无关指令上过度解读。
9. 常见性能误区
- 把短方法全部手工合并，反而降低可读性，JIT 本就可能内联。
- 认为创建对象一定昂贵；TLAB 中分配很快，真正代价常来自存活与回收。
- 仅凭一次微基准宣布某种写法“快几倍”。
- 关闭分层编译追求稳定，结果启动和峰值性能同时受损。
- 将 JIT 优化视为语言语义，依赖对象一定被消除或锁一定被移除。
- 忽略冷启动服务和长时间运行服务的优化目标不同。
10. 工程检查清单
- 先用采样分析器确认热点，再考虑代码级优化。
- 基准测试预热充分，并使用多进程 fork。
- 确保测试结果可观察，避免死代码消除。
- 使用与生产一致的 JDK、参数和 CPU 架构。
- 对接口调用还原生产中的实际类型分布。
- 同时观察吞吐、尾延迟、分配率和编译事件。
- 升级 JDK 后重新验证，不依赖历史实现细节。
理解 JIT 最重要的不是背诵某个阈值，而是认识它的工作方式：根据画像做推测，通过内联打开优化空间，在假设失效时安全撤销。优化 Java 性能也应遵循同样方法——测量、提出假设、获得证据，再修改。