Java 常被描述为“编译型与解释型的结合体”——源代码被编译成字节码，字节码再由虚拟机解释执行。但实际过程远比这个二分法复杂。现代 JVM 中，字节码在运行过程中会再次被编译为机器码，而编译的时机、触发条件和优化策略，直接影响着 Java 程序的启动速度和峰值性能。

---

一、源码到字节码：编译器的前端工作

javac 将 .java 文件编译为 .class 文件，这个过程是词法分析、语法分析、语义分析和代码生成的经典编译流程。但与 C 语言的编译器不同，javac 做的优化很少——它只是把 Java 语法翻译成 JVM 能理解的字节码，大部分优化留给了运行时的 JIT 编译器。

字节码是 JVM 的指令集，每个指令由一个字节的操作码和若干操作数组成。aload_0、invokespecial、areturn 这类指令对人类来说不直观，但它们是 JVM 执行的原子单位。.class 文件包含常量池（存储类名、方法名、字符串字面量等符号信息）、方法字节码、属性表（行号表、异常表等调试信息）和元数据（类版本号、访问标志、字段描述等）。

Java 的跨平台性由此实现：.class 文件不绑定任何操作系统或硬件，只要目标平台有对应实现的 JVM，同样的字节码就能运行。这消除了一次性重写整个软件才能换平台的问题——和 C 语言的可移植性思路完全不同。

---

二、类加载：字节码进入 JVM 的第一步

.class 文件不会自动进入 JVM。类加载器负责将字节码读入内存，经过验证和初始化后，交给执行引擎运行。

加载：根据全限定类名查找 .class 文件，读取字节流，生成 Class 对象。这个阶段是定制类加载逻辑的扩展点。

连接：验证字节码的安全性和格式正确性（栈映射帧、类型推导、指令合法性）；为静态变量分配内存并设置默认值；将符号引用解析为直接引用（方法调用从符号变为实际地址）。

初始化：执行类构造器 <clinit>，初始化静态变量和静态代码块。<clinit> 由编译器自动生成，JVM 保证它在类首次被主动使用时执行，且线程安全。

双亲委派模型是 Java 类加载的核心机制：类加载器收到加载请求后，先委托父加载器处理，父加载器无法加载时再由自己尝试。这保证了核心类库的安全性，防止用户自定义的 java.lang.Object 污染系统类。

---

三、字节码执行：解释与编译的博弈

字节码是抽象的——iconst_2 和 istore_1 这类指令不直接对应 CPU 指令。JVM 必须把它翻译成硬件可执行的机器码，两种方式可用：

解释执行：逐条读取字节码，查表跳转到对应的本地代码片段并执行。启动快，但性能低下，每条字节码的翻译和分发都有固定开销。

即时编译（JIT） ：将整个方法或代码块的字节码编译为机器码，之后直接执行编译后的版本。编译有成本，一旦完成性能显著提升。JIT 的核心决策是：哪些代码值得编译。

分层编译从 JDK 7 开始引入，将编译分为 C1 和 C2 两个级别：

• C1（客户端编译器）：快速编译，优化有限，适合启动阶段

• C2（服务端编译器）：深度优化，编译耗时长，适合长期运行的峰值性能

方法在执行初期先由 C1 快速编译，随着执行次数的增加，热度达到阈值后 C2 重新编译生成更优化的机器码。这种方法让程序在启动速度和长期性能之间找到平衡。

---

四、热点检测与编译触发

JVM 不编译所有方法，只编译热点方法。判断依据是方法调用次数和循环回边次数。

方法调用计数器：每次调用检查方法是否达到编译阈值。阈值可通过 -XX:CompileThreshold 调整，与编译器的选择有关。

回边计数器：每执行一次循环跳转，回边计数器累加。循环 10000 次，即使方法只调用一次，回边计数器也会触发编译——这对计算密集型的短方法尤其重要。

热点检测的精度决定 JIT 优化的有效性。编译过少，关键路径仍是解释执行；编译过多，编译开销影响响应时间。分层编译中的自适应调整让 JVM 在启动时快速编译关键方法，运行一段时间后对真正热的方法进行深度优化。

---

五、JIT 优化策略

JIT 编译器的优化与静态编译器完全不同：它拥有运行时数据，可以基于实际执行情况做激进优化，并在假设失效时逆向优化。

方法内联：将目标方法的代码直接复制到调用处。消除方法调用开销只是表面收益，更重要的是为后续优化创造更大的代码范围——跨方法的常量传播和死代码消除依赖于内联后的整体分析。

内联的决策基于调用频率和方法体大小。-XX:MaxInlineSize（默认 35 字节）控制小方法的内联；-XX:FreqInlineSize 控制热点方法的扩展内联。

逃逸分析：判断对象是否只在当前方法或线程内可见。如果对象没有逃逸，JIT 可以：

• 将堆分配改为栈分配，减轻 GC 压力

• 消除不必要的同步（synchronized 锁在单线程场景下被消除）

• 用标量替换对象（对象的字段拆分为独立变量，对象本身不分配）

锁消除与锁粗化：检测到锁只被单线程访问时直接移除。连续对同一对象的锁操作合并为一次加锁解锁，减少同步开销。

去虚拟化：对于接口调用或虚方法调用，如果实际类型在运行时只有一种，JIT 将调用替换为直接调用，进一步触发内联。类层次分析帮助 JIT 确定哪些方法可以被去虚拟化。

分支预测优化：根据运行时的分支走向统计，将大概率执行的分支排在前面，减少指令流水线的停顿。

---

六、逆优化与反置

JIT 编译器的激进优化基于运行时假设。当假设被破坏时，JIT 必须撤销已经编译的优化版本，回退到解释执行或重新编译。

典型的触发场景是类加载：JIT 内联了一个方法的调用，假设该方法不会被覆盖。但后续某个子类被加载，覆盖了该方法，之前的编译版本就无效了——JVM 在栈上设置“陷阱”，下一次执行该方法时让程序退回到解释器，重新收集类型信息，再决定如何编译。

这种动态适应机制让 JIT 能够随着程序运行状态的变化持续优化，但也意味着优化不是一次性的——峰值性能是随着时间和负载变化逐渐演化出来的。

---

七、对比 C/C++：两种不同的编译哲学

C/C++ 是静态编译：编译后得到的是最终机器码，所有优化在开发阶段确定，运行时性能固定。启动快（无类加载、无 JIT 预热），但优化只能基于源代码本身，无法利用运行时信息。优化选项需要在开发阶段选好，无法在生产环境中动态调整。

Java 是动态编译：启动时解释执行，运行中持续优化。JIT 可以利用运行时的实际数据做更激进的优化（如根据分支概率重排代码），代价是启动慢、初期性能低于峰值。

Java 的性能调优本质上是在启动速度和峰值性能之间找平衡：-Xint 强制解释执行，启动最快但峰值最慢；-XX:TieredStopAtLevel=1 只做 C1 编译；默认分层编译。参数的选择取决于应用场景——命令行工具需要快速启动，长期运行的服务需要峰值吞吐量。

---

八、小结

Java 的执行模型与 C 语言的静态编译有本质不同。从 javac 生成字节码，到类加载器将字节码送入 JVM，再到解释器启动执行、JIT 逐步接管，这是一个动态适应、持续优化的过程。理解字节码结构、类加载机制、热点检测逻辑和 JIT 优化策略，才能在工具无法输出有效信息时定位到底层哪个环节出了问题。