JIT“点石成金”：你的Java代码到底是如何从“解释执行”的龟速，进化成“机器码直飙”的火箭的？

开篇语

哈喽，各位小伙伴们，你们好呀，我是喵手。运营社区：C站/掘金/腾讯云/阿里云/华为云/51CTO；欢迎大家常来逛逛

  今天我要给大家分享一些自己日常学习到的一些知识点，并以文字的形式跟大家一起交流，互相学习，一个人虽可以走的更快，但一群人可以走的更远。

  我是一名后端开发爱好者，工作日常接触到最多的就是Java语言啦，所以我都尽量抽业余时间把自己所学到所会的，通过文章的形式进行输出，希望以这种方式帮助到更多的初学者或者想入门的小伙伴们，同时也能对自己的技术进行沉淀，加以复盘，查缺补漏。

小伙伴们在批阅的过程中，如果觉得文章不错，欢迎点赞、收藏、关注哦。三连即是对作者我写作道路上最好的鼓励与支持！

前言：从“翻译官”到“架构师”的华丽转身

兄弟们，你们知道吗？我们写出来的 Java 代码，经过 javac 编译之后，会变成一堆 字节码（.class文件）。这字节码，JVM 可不是直接拿去运行的，它需要一个“翻译官”来把它翻译成操作系统能听懂的机器码。

刚开始，这个“翻译官”是解释器（Interpreter）。它就像个同声传译，来一句翻译一句，执行一句。优点是启动快，不需要预编译；缺点是慢，因为每次都要翻译。

但是，JVM 里面的“大聪明”们可不满足于此。它们想：“有没有一种办法，能让那些经常被调用的、非常重要的代码，直接变成机器码，以后就不用一遍遍翻译了呢？” 于是，JIT（Just-In-Time）编译器就横空出世了！

JIT 编译器就像一个非常聪明的“项目架构师”，它会默默地观察你的程序运行，找出那些最忙碌、最核心的代码（我们称之为“热点代码”），然后把它们精心优化并编译成高效的机器码，直接“缓存”起来。下次再遇到这段代码，就不用解释器慢悠悠地翻译了，直接飙车！🏎️💨

今天，咱们就来深扒一下这个 JIT 到底是怎么“变魔术”的，以及它都偷偷摸摸地做了哪些优化，让我们的 Java 程序跑得飞快！

一、 JIT 编译：从“旁观者”到“改造者”

JIT 编译过程可不是一蹴而就的，它是一个动态的过程。JVM 会在程序运行期间，根据代码的执行频率和热度，决定是否以及如何进行编译。这就像一个餐厅老板，他不会把所有菜谱都背下来（提前编译所有代码），而是会观察哪些菜点得最多，就把那些菜的制作流程优化到极致（热点代码编译）。

1. 编译的触发：什么是“热点代码”？🔥

JVM 怎么知道哪段代码是热点呢？它有两个主要的“侦查手段”：

* 基于采样的热点探测（Sampling-based Hot Spot Detection）： 简单粗暴，JVM 隔一段时间检查一下，哪些方法在被执行。
  * 基于计数器的热点探测（Counter-based Hot Spot Detection）： 这个更精准，JVM 会为每个方法（或循环体）维护两个计数器：

• 方法调用计数器（Method Invocation Counter）： 统计方法被调用的次数。
• 回边计数器（Back Edge Counter）： 统计方法内部循环体被执行的次数（回边可以理解为循环跳转到起点的指令）。

当这两个计数器的值达到一定的阈值时，JVM 就认为这段代码是“热点代码”了，会把它提交给 JIT 编译器进行编译。

举个栗子：
  你可以通过 java -XX:+PrintFlagsFinal -version 来查看这些默认阈值。比如 CompileThreshold （方法调用计数器阈值）和 OnStackReplaceRatio （回边计数器阈值）。

2. JIT 编译器的“两兄弟”：C1 和 C2 👨‍👦

在 HotSpot JVM 里，JIT 编译其实是由两个编译器协同完成的，它们就像一对“兄弟”，各有所长：

* Client Compiler (C1 编译器)： 速度快，优化相对保守。主要进行一些简单的优化，比如局部变量的优化、循环展开等。它的目标是快速启动，在程序运行初期就能把一部分热点代码编译掉，减少解释执行的开销。就像一个“快枪手”，瞄准就打，不管打得是不是要害。

* Server Compiler (C2 编译器)： 速度慢，但优化激进，甚至会进行一些预测性优化。它会花更多的时间去分析代码，进行更复杂的优化，比如逃逸分析、内联、循环优化等。它的目标是追求极致的运行性能。就像一个“狙击手”，慢慢瞄准，一击毙命。

在**分层编译（Tiered Compilation）**模式下（JDK 7 默认开启），它们会协同作战：
  解释执行 -> C1 编译 -> C2 编译

程序刚启动时，用解释器快速启动。然后，部分热点代码会被 C1 编译器快速编译成机器码，提升初期性能。再然后，那些更热点的代码，会被 C2 编译器进行深度优化。这就像练武功，先学个三脚猫功夫（解释器），然后练套拳法（C1），最后修炼内功心法（C2）！

二、 JIT 的“黑魔法”：热点代码优化策略 🧙‍♂️

JIT 编译器可不是简单地把字节码翻译成机器码就完事了，它还会使出各种“黑魔法”来优化你的代码，让它跑得飞快。这些优化手段，有时候甚至能达到你手动优化都难以企及的高度。

1. 方法内联（Method Inlining）：“化零为整”的艺术

这是 JIT 最重要、最基础的优化之一，重要性怎么强调都不为过！
  想象一下，你有这么一段代码：

public class Calculator {
    public int add(int a, int b) {
        return a + b;
    }

    public int calculateSum(int x, int y) {
        // 假设这里被频繁调用
        return add(x, y) * 2; 
    }
}

每次调用 add 方法，都会涉及方法栈帧的创建、参数传递、返回值处理等等开销。JIT 看到 add 方法很小，而且 calculateSum 方法频繁调用 add，它就会偷偷地把它“内联”进去：

// 经过JIT内联优化后，逻辑上可能变成这样：
public int calculateSum(int x, int y) {
    // return add(x, y) * 2;
    return (x + y) * 2; // 直接把 add 方法体搬过来了，省去了方法调用的开销
}

内联的意义在于，它为后续更多的优化打开了大门！没有内联，很多跨方法边界的优化根本无从谈起。

2. 逃逸分析（Escape Analysis）：对象的生死劫

这个优化听起来就很玄乎，但它能极大地减少堆内存的压力和 GC 的负担。
  核心思想： JIT 分析一个对象是否“逃逸”出了它被创建的方法或线程。
  * 不逃逸： 如果一个对象只在方法内部使用，方法执行完就没用了，那它就是“不逃逸”的。
  * 逃逸： 如果一个对象被外部方法引用，或者被其他线程访问，那它就是“逃逸”的。

优化手段：
  * 栈上分配（Stack Allocation）： 如果一个对象不逃逸，JIT 可能会把它直接分配到栈上而不是堆上。栈上的对象随着方法执行结束就自动销毁了，根本不用 GC 操心，效率杠杠的！
  * 标量替换（Scalar Replacement）： 如果一个对象连引用都没逃逸，甚至可以把它分解成基本类型（标量）来存储。比如 Point p = new Point(1, 2);，如果 p 不逃逸，JIT 可能直接用两个 int 变量 x = 1, y = 2 来代替这个对象。这连对象头都省了，直接在寄存器或栈上操作基本类型，极致性能！

代码示例（感受逃逸与不逃逸）：

public class EscapeAnalysisDemo {

    public void methodA() {
        // 对象局部创建，局部使用，不逃逸
        // 极有可能被栈上分配或标量替换
        MyObject obj = new MyObject("Local Object"); 
        System.out.println(obj.getName());
    }

    public MyObject methodB() {
        // 对象被返回，逃逸到方法外部
        MyObject obj = new MyObject("Escaped Object");
        return obj; 
    }

    private static class MyObject {
        private String name;
        public MyObject(String name) { this.name = name; }
        public String getName() { return name; }
    }

    public static void main(String[] args) {
        EscapeAnalysisDemo demo = new EscapeAnalysisDemo();
        for (int i = 0; i < 1000000; i++) { // 循环调用，使其成为热点
            demo.methodA();
        }
        // methodB 返回的对象可能会被 GC
        MyObject o = demo.methodB();
        System.out.println(o.getName());
    }
}

你运行这段代码，在 methodA 里的 MyObject，在 JIT 优化下，可能根本就不会在堆上产生对象，大大减少了 GC 压力。

3. 循环优化（Loop Optimizations）：加速器！🚀

JIT 对循环的优化也是重头戏，毕竟很多热点代码都在循环里。
  * 循环展开（Loop Unrolling）： 把循环体复制多份，减少循环次数和条件判断的开销。比如 for (int i = 0; i < 4; i++) { doSomething(); } 可能会被优化成 doSomething(); doSomething(); doSomething(); doSomething();。
  * 循环不变式外提（Loop Invariant Code Motion）： 把循环内不变的计算提到循环外面去执行。

• for (int i = 0; i < arr.length; i++) { int x = calculateStaticValue(); doSomething(x); }
• 优化后：int x = calculateStaticValue(); for (int i = 0; i < arr.length; i++) { doSomething(x); }

4. 消除死代码（Dead Code Elimination）：“减肥瘦身”

如果 JIT 发现你的代码里有些部分永远不会被执行（比如 if (false) { ... }），或者结果不会被使用，它就会毫不留情地把这些代码从编译后的机器码中剔除，就像健身教练帮你去掉赘肉一样！💪

5. 窥孔优化（Peephole Optimization）：局部微调

这是一种非常局部的优化，JIT 会检查很小一段连续的机器指令序列，看有没有更短、更快的等价指令序列可以替换。就像在显微镜下，把细微的瑕疵都修复掉。

三、 避坑指南：给JIT点时间，别“一梭子”打死 🔫

了解了 JIT 的神奇之处，我们也要知道一些“避坑指南”。JIT 的优化是动态的，需要时间“学习”你的程序，所以：

* 预热很重要（JVM Warm-up）： 你的程序刚启动时，性能通常不是最好的，因为 JIT 还没来得及把热点代码编译好。所以在做性能测试或基准测试时，一定要给 JVM 足够长的预热时间，让 JIT 充分发挥作用。
  * 别过度优化： 有时候我们手动的一些“微优化”，反而会干扰 JIT 的判断，甚至可能因为引入额外的分支或复杂性，导致 JIT 无法进行更高级的优化。相信 JIT，它比你想象的更聪明。
  * 关注 GC： JIT 优化能减少 GC 频率，但如果 GC 成了瓶颈，那还得从 GC 本身（比如选对 GC 算法）着手。JIT 和 GC 是 Java 性能的两大支柱，相辅相成。

四、 写在最后： JVM 的“灵魂”所在

JIT 编译器和热点代码优化，可以说是 JVM 能够达到高性能的“灵魂”所在。它让 Java 从一个“解释执行”的慢郎中，一跃成为企业级应用的主力军。

每次当你看到你的 Java 服务在高峰期依然稳定如狗的时候，除了你自己写得好（当然！），也要给默默在背后“肝”优化的 JIT 编译器点个赞！👍 它就像一个不知疲倦的幕后英雄，总是在不断学习、不断进化，让我们的代码跑得更快、更稳。

所以，下次再有人说 Java 慢的时候，你可以给他科普一下 JIT 的这些“黑魔法”了！咱们 Javaer，就是这么自信！😎

好了，今天的 JVM 内部探险就到这里。如果觉得有意思，或者学到了新东西，别忘了给我个“三连”啊！咱们评论区接着唠！👋

… …

文末

好啦，以上就是我这期的全部内容，如果有任何疑问，欢迎下方留言哦，咱们下期见。

… …

学习不分先后，知识不分多少；事无巨细，当以虚心求教；三人行，必有我师焉！！！

wished for you successed ！！！

⭐️若喜欢我，就请关注我叭。

⭐️若对您有用，就请点赞叭。
⭐️若有疑问，就请评论留言告诉我叭。

版权声明：本文由作者原创，转载请注明出处，谢谢支持！