JIT即时编译技术在JVM中的应用及分析

 什么是JIT？

JIT（Just In Time），即时编译技术，它能够将Java中的字节码实时地编译成本地机器码并执行。JIT编译器并不止在Java中存在，在其他语言的VM中也可能存在JIT编译器。JIT的作用是将高级语言代码转换成本地机器码，以提高程序的执行效率和性能。通过解释执行与编译执行的结合，JIT编译器可以使得虚拟机更高效地运行代码。

 解释执行和编译执行
在详细理解JIT原理前，需要先理解解释执行和编译执行的概念。

- 解释执行（Interpreted Execution）：在解释执行中，代码会被逐行解释器（Interpreter）逐行解释并执行。解释器会读取源代码的一条语句，然后将其转换成机器指令并立即执行。每执行一条语句，都需要解释器进行一次转换和执行操作。它的优点是：跨平台性好，即时性高（例如Python的交互式开发界面）。缺点是性能较差，并且同一段代码存在多次解释浪费性能的问题。
- 编译执行（Compiled Execution）：在编译执行中，程序的源代码会先经过编译器（Compiler）的处理，将源代码转换成本地机器码或字节码（中间代码），再执行。编译执行性能较好，并且可以进行许多优化。但是缺点是编译时间长，平台依赖性高，需要针对不同硬件平台进行适配。

为了中和两种模式，JIT编译器应运而生。

!JIT介绍

 JIT的发展历史

在JDK 10之前，Java的Hotspot虚拟机中内置了两种编译器，分别是：C1和C2编译器。两款编译器均使用C++语言编写。

C1编译器是一个简单快速的编译器，只关心编译，几乎不做优化，适合执行时间较短或对启动性能有要求的程序。应用启动后不久C1就会开始工作。

C2编译器是为长期运行的服务器程序做性能优化的编译器，适合为长期运行的应用程序做性能调优。在应用启动后一段时间，C2编译器才开始工作。

由于C2编译器的代码超级复杂，已几乎无法继续维护。所以从JDK10开始，C2编译器被使用Java语言编写的Graal取代。

 Hotspot虚拟机的工作模式

无论采用的编译器是C1还是C2，解释器与编译器搭配使用的方式在虚拟机中称为“混合模式”。使用java -version指令能看到虚拟机当前所在的模式。

!混合模式

可通过参数 -Xint 强制虚拟机运行在“解释器模式”下，所有代码将解释执行，编译器不会工作。

-Xcomp参数则强制虚拟机运行在“编译器模式”下，这会使虚拟机优先采用编译的方式执行程序，但解释器在编译器无法编译的情况下仍然会介入执行。

 Hotspot热点探测技术
JIT会基于热点代码的信息来进行相关的优化，所以需要引入热点代码探测的技术。热点代码会在运行时被编译并缓存，以供下次调用。JVM提供了一个参数-XX:ReservedCodeCacheSize来设置CodeCache的大小，JDK7默认是为 32M-48M，JDK8默认值为240M。如果超过了这个缓存的大小，则JIT无法继续编译代码，会自动转为解释执行，性能就会下降。

目前，热点代码的探测方式主要有以下两种：

1. 基于采样方式的热点探测（Sample Based Hot Spot Detection）：周期性地扫描各线程的栈顶，若发现某方法出现在栈顶的频次很高，则认为该方法是热点方法。这样做的优点是：实现简单，缺点是无法精确地判定一个方法的热度，容易受到阻塞线程或其它外接因素干扰热点的探测。
2. 基于计数器的热点探测（Counter Based Hot Spot Detection）：虚拟机会为每个方法，甚至是代码块建立计数器，统计每个方法的执行次数，如果某个方法超过阈值则判定该方法为热点方法。

HotSpot虚拟机就是基于上述的第二种方法进行热点探测。它为每个方法准备了两类计数器：方法调用计数器和回边计数器。只需大于任意一个计数器的阈值，就能够触发JIT编译。

 方法调用计数器

方法调用计数器用于统计方法被调用的次数，若JVM运行在Client模式下，则默认阈值是1500次，而在Server模式下则是10000次。这个阈值也可通过XX:CompileThreshold参数来进行设定。

 回边计数器

JVM使用回边计数器来记录循环代码中的回边（即循环的迭代）。当一个回边被频繁执行时，它的计数值会增加。回边计数器在Server模式中的阈值是10700。

 分层编译

基于代码探测技术探测出来的代码热度数据，Hotspot能够将代码的执行过程分为多个阶段，每个阶段使用不同的编译策略，并根据代码热度来决定优化程度，以平衡编译时间和执行性能。

!分层编译

上图是一个JVM分层编译模型。

HotSpot虚拟机中的分层编译通常包含以下几个层次：

- 解释执行层：初始阶段，Java虚拟机会使用解释器逐行执行Java字节码。解释执行的优点是即时性，不需要等待编译过程，但执行性能较低。
- C1编译层：也称为Client编译器，对于热点代码会进行简单的优化，并将其编译为本地机器码。C1编译层编译速度快，适用于那些执行次数较少的代码段。
- C2编译层：也称为Server编译器，对于经常执行的热点代码会进行更深入的优化，生成高度优化的本地机器码。C2编译层的优点是执行性能高，适用于执行频率较高的代码段。

 JIT优化技术

 逃逸分析

- 全局逃逸（Global Escape）：全局逃逸发生在对象在方法内部创建后，被方法外的代码引用。例如，将对象传递给其他方法、返回对象作为方法的返回值、将对象存储在全局变量或成员变量中等情况。
- 线程逃逸（Thread Escape）：线程逃逸发生在一个线程中创建后，线程中的对象被另一个线程引用。在多线程环境中，对象可能在一个线程中创建，然后通过共享数据传递给其他线程，导致线程逃逸。

逃逸分析能够用于确定在代码中创建的对象是否会逃逸出当前方法的作用域，即是否会被方法外的代码引用。如果一个对象没有逃逸，JIT可以对其进行一些优化，例如栈上分配、标量替换等。逃逸分析还可以减少不必要的对象在堆上的分配和垃圾回收的开销。通过逃逸分析，编译器可以判断一个对象的生命周期，从而决定将其分配在栈上还是堆上。

下面通过一个代码示例查看逃逸分析对性能和GC的影响：

`java
package com.yeliheng.jit;

public class Escape {

    public static void test() {
        Aggregate a = new Aggregate("a", "b");
    }

    public static void main(String[] args) {
        long startTime = System.currentTimeMillis();
        for(int i = 0;i < 10000000; i++){
            test();
        }
        long endTime = System.currentTimeMillis();
        System.out.println("Time:" + (endTime - startTime));
    }

    static class Aggregate {
        private String s1;
        private String s2;

        public Aggregate(String s1, String s2) {
            this.s1 = s1;
            this.s2 = s2;
        }
    }
}

`

我们创建一个对象，对象中包含两个未初始化的字符串s1,s2，循环调用对象一千万次，通过计时器查看程序的执行时间。在测试前，我们需要添加两个JVM参数：-XX:+PrintGCDetails -XX:-DoEscapeAnalysis。

关闭逃逸分析的效果如下：

!逃逸分析关闭

可以看到，在循环调用的过程中，触发了若干次GC，并且执行时间为72毫秒。现在，我们去掉-XX:-DoEscapeAnalysis参数，再次查看效果。

!逃逸分析关闭

首先是频繁的GC没有出现，其次是执行时间只有4毫秒，快了整整18倍，优化的效果十分显著。

 栈上分配
在JVM中创建的对象都会在堆中进行分配，因为在堆内存上的对象是线程共享的，不同线程只需要拥有该对象的引用即可访问堆中存储的对象数据。但如果一个对象经过JIT的逃逸分析后发现其没有逃逸，那么就不需要将其分配到堆上。将该对象分配到栈上能够让它天然地随着出栈（也就是在方法执行完成后）而被销毁，无需被垃圾收集器进行标记从而浪费GC性能。

值得注意的是，在Hotspot虚拟机中，栈上分配并没有真正实现，而是作为一种思想，通过标量替换来真正实现栈上分配。

栈上分配的流程图如下所示：

!栈上分配

 标量替换
如果编译器经过逃逸分析后能够确定一个对象不会逃逸，而且它的成员变量也没有逃逸，那么可以将这个对象拆解为其各个成员变量，并将这些成员变量分别当作标量（scalar）处理，从而实现上文所说的“栈上分配”。在Java中原始数据类型如int、long等都属于标量。而其他可以继续分解的数据都称为聚合量(Aggregate)，对象就是典型的聚合量。

在这里我们使用真实代码查看JIT中的标量替换。
`java
package com.yeliheng.jit;

public class ScalarReplacement {
    public ScalarReplacement() {
    }

    public static void main(String[] args) {
        int x = getX();
        int y = getY();
        int sum = add(x, y);
        System.out.println("Sum: " + sum);
    }

    public static int getX() {
        return 10;
    }

    public static int getY() {
        return 20;
    }

    public static int add(int a, int b) {
        return a + b;
    }
}
`

以上的代码在开启标量替换后会被编译成下列代码：

`java
package com.yeliheng.jit;

public class ScalarReplacement {
    public ScalarReplacement() {
    }

    public static void main(String[] args) {
        int x = getX();
        int y = getY();
        int sum = add(x, y);
        System.out.println("Sum: " + sum);
    }

    public static int getX() {
        return 10;
    }

    public static int getY() {
        return 20;
    }

    public static int add(int a, int b) {
        return 30;
    }
}

`

 方法内联
方法内联的优化行为就是把目标方法的代码复制到发起调用的方法之中，避免发生真实的方法调用。
`java
    private int add(int a, int b, int c, int d) {
        return add(a, b) + add(c, d);
    }
    
    private int add(int a, int b) {
        return a + b;
    }
`
如上的add方法，计算a+b和c+d的和，会被方法内联优化为以下方式：
`java
    private int add(int a, int b, int c, int d) {
        return a + b + c + d;
    }
`

JVM识别热点方法会对它们进行内联优化，但如果热点方法的方法体过大（默认大于325字节），JVM就不会执行内联操作。可以通过-XX:FreqInlineSize=N来修改执行方法内联方法体大小的阈值。

 总结

本文分析了JIT（Just-In-Time）即时编译技术在Java虚拟机中的应用。JIT通过热点代码探测识别高频执行的代码，并进行优化以提高程序执行效率。文章介绍了解释执行和编译执行的概念，以及HotSpot虚拟机的工作模式和分层编译。最后，本文从JIT优化技术：逃逸分析、栈上分配、标量替换和方法内联进行分析，希望能在JIT的探索中对大家有所帮助。

JIT（Just In Time），即时编译技术，它能够将Java中的字节码实时地编译成本地机器码并执行。JIT编译器并不止在Java中存在，在其他语言的VM中也可能存在JIT编译器。JIT的作用是将高级语言代码转换成本地机器码，以提高程序的执行效率和性能。通过解释执行与编译执行的结合，JIT编译器可以使得虚拟机更高效地运行代码。

JIT即时编译技术在JVM中的应用及分析

Java堆 #

> Java 堆是垃圾收集器管理的主要区域，因此也被称作GC 堆（Garbage Collected Heap）。从垃圾回收的角度，由于现在收集器基本都采用分代垃圾收集算法，所以 Java 堆还可以细分为：新生代和老年代：再细致一点有：Eden 空间、From Survivor、To Survivor 空间等。进一步划分的目的是更好地回收内存，或者更快地分配内存。

下面我们来具体介绍Java堆中的分代。

 年轻代 

年轻代主要分为两个区，分别是Eden区和2个Survivor区。年轻代存在的意义是让GC尽可能快速地收集生命周期较短的对象。年轻代内存示意图如下：

> Tip: Eden即伊甸园，传说此处是人类的起源之地，故对象刚被创建出来被放入Eden区。

!年轻代

从图中可以看出年轻代内存分为一块Eden区和两块较小的Survivor空间，分别是8:1:1的比例。当进行垃圾回收时，将Eden和Survivor中存活的对象一次性复制到另一块Survivor空间中，最后清理Eden和用掉的Survivor空间。当Survivor空间都不够用时，则需要老年代进行分配收集。

大部分情况下，对象都会先在Eden区进行分配（除非如Eden区已满），在一次年轻代垃圾回收后，如果对象还存活，则对象会从Eden区进入 s0 或者 s1区域中，并且对象的年龄加 1，当它的年龄增长到阈值时（默认为大于 15 岁），就会被晋升到老年代中，可以通过参数 -XX:MaxTenuringThreshold 来设置该阈值。

常用的调优参数：

- -XX:SurvivorRatio：Eden和Survivor的比值，默认8:1。
- -XX:NewRatio：老年代和年轻代内存大小的比例。
- -XX:MaxTenuringThreshold：对象从年轻代晋升到老年代经过GC次数的最大阈值。

 老年代 

老年代存放生命周期较长的对象。以下对象会进入到老年代中：

- 经历一定Minor次数依然存活的对象，即默认年龄大于15（Minor我们下文会进行介绍）
- Survivor区中存放不下的对象
- 新生成的大对象

判断一个对象是否可被回收的方法 #

 引用计数法 

- 通过判断对象的引用次数来决定对象是否可被回收。
- 每个对象实例都有一个引用计数器，被引用则+1，完成引用则-1。
- 任何引用计数为0的对象实例可以被当作垃圾收集。

优点：执行效率高，程序执行受影响较小。

缺点：无法检测出循环引用的情况，容易导致内存泄露。循环引用例子如下：

`java
package com.yeliheng.gc;

public class ReferenceCountingGC {
    Object ref = null;
    public static void main(String[] args) {
        ReferenceCountingGC o1 = new ReferenceCountingGC();
        ReferenceCountingGC o2 = new ReferenceCountingGC();
        o1.ref = o2;
        o2.ref = o1;
    }
}
`

o1和o2两个对象互相引用对方，除此之外没有其他任何引用。但由于彼此之间循环引用，导致它们的引用计数器永远不会为0，所以使用引用计数法无法让GC对其进行回收。

 可达性分析算法 

通过判断对象的引用链是否可达来决定对象是否可以被回收。如下图所示，可达性分析算法以GC Root为起始点进行搜索，可达的对象都是存活的，不可达的对象可被回收。

!可达性分析

 可作为GC Root的对象 

- 虚拟机栈中引用的对象（栈帧中的本地变量表）。
- 方法区中的常量引用的对象。
- 方法区中的类静态属性引用的对象。
- 本地方法栈中JNI即Native方法的引用对象。
- 活跃线程的引用对象。

垃圾回收算法 #

 标记-清除算法(Mark and Sweep) 

- 标记：从根集合进行扫描，对存活的对象进行标记。
- 清除：对堆内存从头到尾进行线性遍历，回收不可达对象内存。

它是最基础的收集算法，后续的算法都是对其不足进行改进得到。

缺点：会产生大量内存碎片，导致无法给大对象分配内存。

 复制算法(Copying) 

复制算法将内存分为对象面和空闲面，对象在对象面上创建，把存活的对象从对象面复制到空闲面，再将对象面上所有的内存清除。此算法解决了碎片化的问题，按顺序分配内存，简单高效，适用于对象存活率低的场景。

!复制算法

 标记-整理算法(Compacting) 

标记整理算法会标记出所有存活的对象，然后让所有存活的对象向一端移动，并清理掉末端边界以外的内存。该算法做不会产生内存碎片，并且无需设置两块内存互换，适用于存活率极高的场景。但其需要移动大量对象，处理效率较低。

 分代收集算法（Generational Collector） 

按照对象的生命周期划分不同的区域，并采用不同的垃圾分类算法。可以理解成上述算法的综合。新生代对象存活率低，适合采用复制算法；老年代存活率高，复制大量对象成本较高，且无额外空间进行分配担保，所以一般采用标记-清除算法或标记-整理算法。

分代收集算法中GC的分类如下：

 GC分类 

- Minor GC：回收新生代，因为新生代对象存活时间很短，因此Minor GC会频繁执行，执行的速度一般也会比较快。
- Full GC：回收老年代和新生代，老年代对象存活时间长，因此Full GC很少执行，执行速度会比Minor GC慢得多。
- Major GC：只对老年代进行垃圾收集。需要注意的是 Major GC 在有的语境中也用于指代整堆收集，即Full GC。

 触发Full GC的条件 

- 调用System.gc()：只是建议虚拟机执行Full GC，虚拟机不一定会真正去执行。

- 老年代空间不足：大对象直接进入老年代、长期存活的对象进入老年代，导致老年代空间不足时，会触发Full GC。解决方法：避免创建过大的对象或者增大新生代晋升老年代的年龄。
- JDK1.7及之前永久代空间不足：永久代存放的是一些类信息、常量和静态变量等数据，当系统中加载的类、反射的类和调用方法较多时，永久代空间不足就会触发Full GC。所以JDK1.8用元空间取代永久代可以降低Full GC的频率，减少GC负担。
- 空间分配担保失败：使用复制算法的Minor GC需要老年代的内存空间作担保，如果担保失败会执行一次Full GC。
- Concurrent Mode Failure：执行CMS GC的过程中同时有对象要放入老年代，而此时老年代空间不足，便会报Concurrent Mode Failure 错误，并触发Full GC。

 空间分配担保 

>  空间分配担保是为了确保在 Minor GC 之前老年代本身还有容纳新生代所有对象的剩余空间。

在发生Minor GC之前，虚拟机先检查老年代最大可用的连续空间否大于新生代所有对象总空间，如果大于，那Minor GC可以确认是安全的。如果不大于，虚拟机会查看HandlePromotionFailure的值是否允许担保失败发生，如果允许那么就会继续检查老年代最大可用的连续空间是否大于历次晋升到老年代对象的平均大小，如果大于，将尝试着进行一次Minor GC；如果小于，或者HandlePromotionFailure的值不允许冒险，那么就要进行一次Full GC。

 Stop-the-world 

Stop-the-world指JVM由于要执行GC而停止了应用程序的执行，它在任何一种GC算法中都会发生。多数GC优化是通过减少Stop-the-world发生的时间来提高程序性能。

 Safepoint 

Safepoint即垃圾收集器中的安全点，用于分析过程中对象引用关系不会发生变化的点。一般出现在方法调用、循环跳转和异常跳转等位置。安全点的数量选取要适中，选取太少会让GC等待太久，选取太多会增加程序运行负荷。

常见的垃圾收集器 #

前置知识：JVM运行模式。

JVM运行模式有以下两种：

- Server：Server模式采用重量级JVM，优化更多，启动慢但稳定后效率高。
- Client：Client模式采用轻量级JVM，启动的速度快。

---

我们先来了解一下新生代垃圾收集器。

 Serial收集器 

用于新生代垃圾回收，采用复制算法，单线程收集，必须暂停所有工作线程。由于没有线程交互的开销，简单高效，是Client模式下默认的新生代垃圾收集器。

> 参数：-XX:+UseSerialGC

 ParNew收集器 

用于新生代垃圾回收，采用复制算法，多线程收集，其他特点与Serial收集器基本相同。ParNew收集器在单核CPU的执行效率不如Serial收集器，因为存在线程交互带来的开销，其在多核心CPU上执行才有优势。

> 参数：-XX:+UseParNewGC

 Parallel Scavenge收集器 

用于新生代垃圾回收，采用复制算法，也是多线程收集。Parallel Scavenge收集器更注重系统的吞吐量，ParNew收集器更注重减少用户线程停顿时间。Parallel Scavenge是Server模式下默认的新生代垃圾收集器。

> 参数：-XX:+UseParallelGC

> 吞吐量 = 运行用户代码时间 / (运行用户代码时间 + 垃圾收集时间)

---

接下来是老年代垃圾收集器。

 Serial Old收集器 

Serial Old用于老年代垃圾回收，采用标记-整理算法。它是Serial收集器的老年代版本，除了采用的算法不同，其余特点与Serial收集器基本相同。Serial Old收集器是Client模式下默认的老年代垃圾收集器。在Parallel Old收集器诞生前，它与Parallel Scavenge收集器搭配使用。在CMS收集器发生Concurrent Mode Failure时，也会使用Serial Old收集器。

> 参数：-XX:+UseSerialOldGC

 Parallel Old收集器 

Parallel Old收集器用于老年代垃圾回收，采用标记-整理算法。Parallel Scavenge收集器的老年代版本，多线程，注重吞吐量。

> 参数：-XX:+UseParallelOldGC

 CMS收集器 

CMS（Concurrent Mark Sweep）收集器用于老年代垃圾回收，采用标记-清除算法，收集器线程可以和用户线程并发工作。CMS适合使用在对用户体验要求较高以及JVM中存在较多存活时间较长的对象的场景。它的垃圾回收过程分为以下六步：

1. 初始标记：stop-the-world仅标记与GC Roots直接关联的对象，速度很快。
2. 并发标记：进行GC Roots追溯标记，它在整个回收过程中耗时最长。由于并发标记的线程与应用程序的线程并发执行，所以用户不会感到停顿。
3. 并发预清理：并发预清理会查找执行并发标记阶段从新生代晋升到老年代的对象。
4. 重新标记：会暂停虚拟机，扫描CMS堆中的剩余对象，相对较慢。
5. 并发清理：清理垃圾对象，程序不会停顿。
6. 并发重置：重置CMS收集器的数据结构，等待下一次垃圾回收。

这6个步骤中，初始标记和重新标记需要短暂地stop-the-world。

CMS收集器的缺点：

- 吞吐量低，降低停顿时间是以牺牲吞吐量为代价的，导致CPU利用率不够高。

- 无法处理浮动垃圾。浮动垃圾是在并发清除时，由于用户线程继续运行而产生的垃圾。这部分垃圾只能等到下一次GC才能进行回收，浮动垃圾存在需要预留一部分内存，如果预留的内存不够存放浮动垃圾，就会出现Concurrent Mode Failure，这时虚拟机将临时启用Serial Old 收集器来替代CMS收集器。

- 采用的是标记-清除算法，会存在内存碎片，所以可能导致没有足够大的连续空间来分配大对象，不得不提前触发一次Full GC。

 G1收集器 

G1收集器（Garbage First）采用多线程收集，且可以和用户线程并发进行。它既可回收新生代，也可回收老年代，采用的是复制+标记-整理算法，不会产生内存碎片。使用G1收集器可以实现可预测的停顿，它能够让使用者指定在一个长度为M 毫秒的时间片段内，消耗在GC上的时间不得超过N毫秒。

G1收集器将整个Java堆内存划分为多个大小相等的Region，新生代和老年代不再物理隔离。通过记录每个Region垃圾回收时间以及回收所获得的空间，维护一个优先列表，每次可根据允许收集的时间，优先回收价值最大的Region。而且每个Region中还有一个Remembered Set，用来记录该Region中对象的引用对象所在的Region，在做可达性分析的时候就可以避免全堆扫描。

G1收集器工作流程包含以下四个步骤：

- 初始标记：和CMS收集器类似。
- 并发标记：和CMS收集器类似。
- 最终标记：为了修正在并发标记期间因用户程序继续运作而导致标记产生变动的那一部分标记记录，这阶段需要停顿线程。
- 筛选回收：会对各个Region中的回收价值和成本进行排序，根据用户所期望的GC停顿时间，来回收价值最大的一部分Region。

 补充 

JDK11中还有一种ZGC，它与 CMS 中的 ParNew 和 G1 类似，ZGC 也采用标记-复制算法。不过 ZGC 对该算法做了重大改进，可以实现非常低的线程停顿时间，它通过使用着色指针和读屏障来实现。感兴趣的同学可以自行查阅相关资料。

面试题 #

 Object的finalize()方法的作用是否与C++的析构函数作用相同？ 

答：与C++的析构函数不同，析构函数调用时间确定，而finalize()方法的调用时间是不确定的。

进阶：当对象进行可达性分析时发现没有和GC Roots相连接会判断是否使用了finalize()方法。如果对象覆盖了finalize()方法，并且没使用过这个方法，对象就会被放在F-Queue中，然后稍后由JVM创建一个低优先级的finalize线程去执行触发finalize()方法。由于finalize线程优先级比较低，所以finalize()方法执行随时可能被终止。finalize()方法是为对象创建最后一次重生的机会，如果在finalize()方法中对象又再次和GC Roots相连，就不会被垃圾回收器回收。

此处我们通过一个例子直观理解：

`java
package com.yeliheng.gc;

public class Finalization {
    public static Finalization finalization;

    @Override
    protected void finalize() throws Throwable {
        System.out.println("Finalized");
        finalization = this;
    }

    public static void main(String[] args) {
        Finalization f = new Finalization();
        //第一次打印
        System.out.println("1: " + f);
        //将f置为空
        f = null;
        System.gc();
        // 第二次打印
        System.out.println("2: " + f);
        //调用
        System.out.println(f.finalization);
    }
}

`

运行以上demo会得到如下输出：

`
1: com.yeliheng.gc.Finalization@29453f44
2: null
null
Finalized

Process finished with exit code 0
`

我们会发现，最后调用f.finalization时，finalization = this;的效果并没有显现出来。这就体现了finalize在gc调用时间上的不确定性。

由于finalize方法运行的不确定性较大，无法保证各对象的调用顺序，同时运行代价也是相当高昂的，故不建议在生产环境中使用这个方法！

 Java中的强引用，软引用，弱引用，虚引用了解吗？ 

强引用：是最普遍的引用，JVM宁愿抛出OutOfMemoryError终止程序也不会回收具有强应用的对象，通过将对象设置为null来弱化引用，可以使其被回收。强

`java
Object obj = new Object(); // 强引用
`

软引用：对象处在有用但非必须的状态，只有当内存空间不足时，GC会回收该引用的对象的内存，可以用来实现内存敏感的高速缓存，不用担心OutOfMemory的问题，而且内存一般也是充足的，引用的对象会一直存在方便复用，可以和引用队列联合使用。

`java
String str = new String(“abc”);
SoftReference<String> softRef = new SoftReference<String>(str);
`

弱引用：非必须的对象，比软引用更弱一些。无论内存是否充足，GC都会回收弱引用对象。另外由于GC线程优先级比较低，被及时回收的概率也不大。适用于引用偶尔被使用且不影响垃圾回收的对象，可以和引用队列联合使用。

`java
String str = new String(“abc”);
WeakReference<String> weakRef = new WeakReference <String>(str);
`

虚引用：不会决定对象的生命周期，任何时候都可能被垃圾收集器回收。主要作用是跟踪对象被垃圾收集器回收的活动，起哨兵作用。必须和引用队列ReferenceQueue联合使用。

`java
String str = new String(“abc”);
ReferenceQueue queue = new ReferenceQueue();
PhantomReference ref = new PhantomReference(str, queue);
`

引用的级别由高到低分别为：强引用 -> 软引用 -> 弱引用 -> 虚引用

下面我用一个表格总结引用：

| 引用类型 |  被垃圾回收时间  |      作用      |     生命周期      |
| :------: | :--------------: | :------------: | :---------------: |
|  强引用  |   从来不会回收   | 对象的一般状态 | JVM停止运行时终止 |
|  软引用  | 在内存不足时回收 |    对象缓存    |  内存不足时终止   |
|  弱引用  | 在垃圾回收时回收 |    对象缓存    |   gc运行后终止    |
|  虚引用  | 任何时候都有可能 |   标记、哨兵   |     无法确定      |

补充：Java中引用的类层次结构，如下图所示。

!类结构

引用队列：存储关联的且被GC的软引用，弱引用以及虚引用。用处只是为了提醒程序员非强引用型变量所引用的对象已经具有不可达性了，再也不能获得堆中的那个对象了。

 CMS收集器和G1收集器的区别 

- 使用范围不同：CMS收集器是老年代的收集器，可以配合新生代的Serial收集器和ParNew收集器一起使用；G1收集器收集范围是老年代和新生代，不需要结合其他收集器使用。
- stop-the-world时间不同：CMS收集器是以最小的停顿时间为目标的收集器；G1收集器可预测指定垃圾回收的停顿时间。
- CMS收集器产生的内存碎片比G1收集器多：CMS收集器是使用“标记-清除”算法进行的垃圾回收，容易产生内存碎片；G1收集器使用的是“标记-整理”算法，进行了空间整合，降低了内存空间碎片。
- 垃圾回收过程不同：
  - CMS收集器：初始标记、并发标记、重新标记、并发清除；
  - G1收集器：初始标记、并发标记、最终标记、筛选回收；

GC垃圾回收是JVM的一个重要部分，掌握GC有利于调试排查各种内存溢出问题。当系统遇到性能瓶颈时，我们也许能够通过JVM内部的技术细节来解决棘手的问题。

JVM基础之GC垃圾回收机制详解

JVM内存模型是JVM中的一个重要知识点，掌握内存模型有助于了解Java内存分配机制以及后续的GC机制，在实际项目中能够对常见OOM错误进行排查。

!JVM内存模型

此处JVM内存模型与Java内存模型（JMM）是两个不同的概念。关于Java内存模型JMM的介绍，请前往我的这篇文章。

Java运行时数据区 #

从图中可以看出：

线程私有：程序计数器、虚拟机栈、本地方法栈

线程共享：堆、元空间

注：元空间（MetaSpace）是JDK1.8之后加入的。在JDK1.8之前，它是方法区。具体将在下文介绍。

接下来我们具体来看运行时数据区的内容。

 程序计数器 

程序计数器记录当前线程执行的位置，是唯一一个不会出现OutOfMemoryError的内存区域。它的生命周期：随着线程的创建而创建，随着线程的结束而死亡。

- 当前线程所执行的字节码行号指示器（物理上不存在，是逻辑上的）。
- 改变计数器的值来选取下一条需要执行的字节码指令。
- 和线程是一对一的关系即：线程私有。
- 对Java方法计数，如果是native方法则计数器值为undefined。
- 不会发生内存泄露（唯一一个不会出现OutOfMemoryError的内存区域）。

 虚拟机栈 

虚拟机栈由一个个栈帧(Stack Frame)组成，每个栈帧中包含局部变量表、操作数栈、动态链接、返回地址。虚拟机栈是线程私有的。局部变量表主要存放的就是基本数据类型和对象引用。虚拟机栈可能会出现StackOverflowError和OutOfMemoryError错误。它的生命周期与程序计数器相同：随着线程的创建而创建，随着线程的结束而死亡。

栈是JVM运行时数据区域的一个核心，除了一些native方法的调用是通过本地方法栈实现的，其他所有的Java方法调用都是通过栈配合实现的。

调用方法会有一个对应的栈帧被压入栈中，每一个方法调用结束后，会将栈帧弹出。

栈的结构示意图如下：

!栈

>  局部变量表： 主要存放基本数据类型（boolean、byte、char、short、int、float、long、double...）、对象引用（reference 类型，它不同于对象本身，可能是一个指向对象起始地址的引用指针，也可能是指向一个代表对象的句柄或其他与此对象相关的位置）。

> 操作数栈： 用于存放方法执行过程中产生的中间计算结果，它充当中转站的作用。另外，计算过程中产生的临时变量也会放在操作数栈中。

> 动态链接： 主要服务一个方法需要调用其他方法的场景。在 Java 源文件被编译成字节码文件时，所有的变量和方法引用都作为符号引用（Symbilic Reference）保存在 Class 文件的常量池里。当一个方法要调用其他方法，需要将常量池中指向方法的符号引用转化为其在内存地址中的直接引用。动态链接的作用就是为了将符号引用转换为调用方法的直接引用。

 本地方法栈 

本地方法栈与虚拟机栈类似，虚拟机栈为执行Java方法提供服务，本地方法栈为执行native本地方法提供服务。本地方法栈也是线程私有的。

本地方法在执行时也会在本地方法栈处创建一个栈帧，方法执行完毕后响应的栈帧会弹出栈释放内存空间。本地方法栈也会出现StackOverflowError和OutOfMemoryError错误。

 堆 

堆是虚拟机管理内存中最大的一块，它是线程的共享区域，随着虚拟机的启动而创建。堆是对象实例的分配区域，GC管理的主要区域。在垃圾回收时，堆会被划分为新生代和老年代，其中新生代又被划分为Eden、From Survivor、To Survivor、Old区域。此处我们将在GC机制的文章中详细进行分析。

 方法区 

用于存放已被加载的类信息、常量、静态变量等。JDK1.6之前方法区的实现是永久代，JDK1.8时方法区实现是元空间。

关于永久代和元空间我们将在下文进行介绍。

 运行时常量池 

运行时常量池的功能类似于传统的编程语言的符号表。在Class文件的常量池中，存放着用于保存编译时生成的字面量和符号引用。在类加载后，Class文件常量池会放在运行时常量池中。运行时常量池也是方法区的一部分，它受方法区内存的限制，当常量池无法再申请到内存时会抛出OutOfMemoryError。

 字符串常量池 

字符串常量池是JVM为了提升性能和减少内存消耗针对String类专门开辟的一块区域，主要是为了避免字符串的重复创建造成资源的浪费。在JDK1.7之前，字符串常量池存放在永久代，JDK1.7后字符串常量池和静态变量移动到Java堆中。JDK1.8永久代的实现变成元空间。

面试题 #

 为什么递归会导致StackOverFlowError？ 

答：递归过深会造成栈帧中被压入过多的栈而占用太多空间，导致栈空间过深，而线程请求栈的深度是有限的，当线程请求栈深度超过当前Java虚拟机的最大深度时，就会引发java.lang.StackOverFlowError异常。补充：当虚拟机栈过多则会引发java.lang.OutOfMemoryError异常。

 元空间(MetaSpace)和永久代(PermGen)的区别 

答：元空间使用本地内存，而永久代使用的是JVM内存。

> 整个永久代有一个 JVM 本身设置的固定大小上限，无法进行调整，而元空间使用的是直接内存，受本机可用内存的限制，虽然元空间仍旧可能溢出，但是比原来出现的几率会更小。

 元空间替代永久代的优势 

答：

-  字符串常量池存在永久代中，容易出现性能问题和内存溢出。而元空间使用直接内存，只受到本机可用内存限制，溢出概率小。
- 由于类和方法的信息大小难以确定，元空间将根据运行时应用程序需求动态调整大小，而永久代不会，确定大小十分困难。
- 元空间有利于减轻GC负担，而永久代会为GC带来不必要的复杂性。当系统中加载的类、反射的类和调用方法较多时，永久代空间不足就会触发Full GC。用元空间可以降低Full GC频率，减少GC负担。
- 元空间方便与HotSpot和其他JVM如Jrockit进行集成。（Jrockit没有永久代）

  JVM内存模型中堆和栈的区别 

答：

- 管理方式：栈自动释放，堆需要通过GC来释放。
- 空间大小：栈比堆小。JVM管理的内存中，堆是最大的一块。
- 碎片相关：栈产生的内存碎片远小于堆。
- 分配方式：栈支持静态分配和动态分配，堆仅支持动态分配。
- 效率：栈的效率比堆高。

 JDK1.7为什么要将字符串常量池移动到堆中？ 

答：因为永久代的GC回收效率太低，只有当Full GC时才会执行。这就造成Java程序中有大量被创建的字符串等待被回收。将字符串移动到堆中，能够及时地回收字符串内存。

 不同JDK版本之间的intern()方法有什么区别？ 

- JDK1.6：当调用intern()方法时，如果字符串常量池中已经存在该字符串的对象，则直接返回池中该字符串的引用。否则将此字符串对象添加到字符串常量池中，并返回该字符串的引用。
- JDK1.6+：当调用intern()方法时，如果字符串常量池中已经存在该字符串的对象，则直接返回池中该字符串的引用（此处与JDK1.6相同）。否则，如果该字符串对象已经存在于Java堆中，则将堆中此对象的引用添加到字符串常量池中，并返回该引用；如果堆中不存在，则在池中创建该字符串并返回其引用。

JVM内存模型是JVM中的一个重要知识点，掌握内存模型有助于了解Java内存分配机制以及后续的GC机制，在实际项目中能够对常见OOM错误进行排查。

JVM基础之JVM内存模型详解

开始 #

本文我整理了一些JVM类加载器相关的面试高频知识点，方便同学们复习。

在详细了解JVM知识点之前，我们先引入以下基础的经典面试题：

 谈谈你对Java的理解 

- 平台无关性，一次编译到处运行。

- GC垃圾回收机制：Java无需像C++一样手动管理内存。

- Java的语言特性：泛型、反射、lambda表达式等。

- 面向对象：包括封装、继承、多态。

- Java自身类库如：集合、并发库、网络库以及IO流。

- 异常处理。

 Java 和 C++的区别 

- Java不提供指针直接访问内存，程序的内存更加安全。
- Java的类是单继承，而C++的类是多继承（Java的接口是可以多继承的）。
- Java有自动垃圾回收机制，无需手动释放内存。
- Java可实现平台无关性，一次编译，不同系统平台都能运行。

 Java平台无关性是如何实现的？ 

Java源码首先被编译成字节码，再由不同平台的JVM进行解析，Java语言在不同的平台上运行时不需要重新编译，Java虚拟机在执行字节码的时候会将字节码转换成具体平台上的机器指令。所以Java也是一种编译与解释并存的语言。它即具备编译型语言的特征，也具备解释型语言的特征。

引用维基百科的介绍：

> 为了改善编译语言的效率而发展出的即时编译技术，已经缩小了这两种语言间的差距。这种技术混合了编译语言与解释型语言的优点，它像编译语言一样，先把程序源代码编译成字节码。到执行期时，再将字节码直译，之后执行。Java与LLVM是这种技术的代表产物。

 为什么JVM不直接将源码解析成机器码？ 

- 准备工作：每次执行前都需要进行各种检查。
- 兼容性：这样做使得其他语言也能够按照JVM的标准解析成字节码。

 JVM的主要组成部分 

- Class Loader：依据特定格式，加载class文件到内存。
- Execution Engine：对命令进行解析。
- Native Interface：融合不同开发语言的原生库为Java所用。
- Runtime Data Area：JVM内存空间结构模型。

前置知识-反射 #

 谈谈什么是反射？ 

Java反射机制是在运行状态中，对于任意一个类，都能知道这个类的所有属性和方法；对于任意一个对象，都能调用它的任意方法和属性；这种动态获取信息以及动态调用对象方法的功能称为Java语言的反射机制。

 用过反射吗？ 

Java反射的三种方法：

- 调用对象的getClass()方法。
- Class.forName("xxx.xxx.xxx")。
- 类名.class。

常用方法: 

- newInstance()：创建对象实例。
- getMethod()：可以获取所有public的方法（包含继承和实现的方法）。
- getDeclaredMethod()：获取指定对象的方法（不包含继承和实现方法）。
- setAccessible()：传入true/false，当设为true时可访问私有方法。
- Class.getField()：获取类中字段属性。
- Invoke()：可以用于执行指定的方法。

ClassLoader #

ClassLoader在Java中有着非常重要的作用，它主要工作在Class装载的加载阶段，其主要作用是从系统外部获得Class的二进制数据流。它是Java的核心组件，所有的Class都是由ClassLoader进行加载的。ClassLoader负责将Class文件里的二进制数据流装载进系统，然后交由Java虚拟机进行连接，初始化等操作。

 ClassLoader的种类 

- BootStrapClassLoader：它由C++编写，加载核心库java.*。
- ExtClassLoader：Java编写，加载扩展库Javax.*。
- AppClassLoader：Java编写，加载程序所在目录。
- 自定义ClassLoader：Java编写，定制化加载。

 自定义ClassLoader的实现 

自定义ClassLoader的实现有两个关键函数：

- findClass()

`java
    protected Class<?> findClass(String name) throws ClassNotFoundException {
        throw new ClassNotFoundException(name);
    }
`

- defineClass()

`java
    protected final Class<?> defineClass(String name, byte[] b, int off, int len)
        throws ClassFormatError
    {
        return defineClass(name, b, off, len, null);
    }

`

 类加载器的双亲委派机制 

!双亲委派机制

在加载一个类时，会通过递归的方法，自底向上，首先看自定义类加载器中是否已经加载过相关类，若没有加载过，则调用父类加载器App ClassLoader的loadClass()方法看是否加载过，若还是没有就继续调用父类加载器Extension ClassLoader看是否加载过，直到检查到BootStrap ClassLoader。若都没加载过，就考虑自己是否具备加载的条件，如果不能加载，就自顶向下交给子类加载器进行加载。若还是无法加载，则抛出ClassNotFoundExcepiton异常。

 源码分析 

`java
protected Class<?> loadClass(String name, boolean resolve)
        throws ClassNotFoundException
    {
        // 类加载是线程安全的
        synchronized (getClassLoadingLock(name)) {
            // 首先，检查类是否已经被加载
            Class<?> c = findLoadedClass(name);
            if (c == null) {
                long t0 = System.nanoTime();
                try {
                    if (parent != null) {
                        // 递归调用检查父类加载器
                        c = parent.loadClass(name, false);
                    } else {
                        // 查找Bootstrap ClassLoader中是否加载了有关类
                        // 其中调用了findBootstrapClass 为native方法
                        // 因为Bootstrap类加载器是c++中实现的
                        c = findBootstrapClassOrNull(name);
                    }
                } catch (ClassNotFoundException e) {
                    // ClassNotFoundException thrown if class not found
                    // from the non-null parent class loader
                }

                if (c == null) {
                    //如果依然没找到，那么就调用自定义类加载器的findClass进行查找
                    long t1 = System.nanoTime();
                    c = findClass(name);

                    // this is the defining class loader; record the stats
                    sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
                    sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
                    sun.misc.PerfCounter.getFindClasses().increment();
                }
            }
            if (resolve) {
                resolveClass(c);
            }
            return c;
        }
    }
`

 为什么要使用双亲委派机制去加载类 

答：使用双亲委派机制能够避免多份同样的字节码重复加载。双亲委派机制能够保证同一份字节码文件只会被加载一次，并且可以保证一些核心的类不会被篡改替换，保证安全性。

 类的加载方式 

- 隐式加载：new，new后的对象实例无需再调用newInstance()方法来获取对象实例，new支持带参数的构造器生成对象实例。
- 显式加载：loadClass，forName。显式加载得到class对象后都需要调用newInstance()方法来获取对象实例。

 类的装载过程 

1. 加载

   - 通过ClassLoader加载class文件字节码，生成Class对象。

2. 链接

   - 校验：检查加载的class的正确性和安全性。
   - 准备：为类变量分配存储空间并设置类变量的初始值。
   - 解析：JVM将常量池内的符号引用转换为直接引用。

3. 初始化

   - 执行类变量赋值和静态代码块。

 loadClass和forName的区别 

- Class.forName()得到的class是已经初始化完成的。
- ClassLoader.loadClass()得到的class是还没有链接的。

Class.forName()代码实现：

`java
    public static Class<?> forName(String className)
                throws ClassNotFoundException {
        Class<?> caller = Reflection.getCallerClass();
        // 第二个参数被设为true，这个类将被初始化
        return forName0(className, true, ClassLoader.getClassLoader(caller), caller);
    }
`

我们在实际场景中两种方法都会使用到。

例如在使用jdbc的mysql驱动时，我们需要使用Class.forName()方法来指定Driver。

`java
Class.forName("com.mysql.jdbc.Driver");
`

而在Spring IoC中，要读取一些Bean的配置文件时，如果以classpath方式来加载，则需要使用ClassLoader.loadClass()方式进行加载。这与Spring IoC容器的懒加载方式有关。Spring IoC为了加快初始化速度，大量使用懒加载方式来加速。而ClassLoader.loadClass()方法则可以对类进行延迟初始化，从而提升Spring的启动速度。

本文我整理了一些JVM类加载器相关的面试高频知识点，方便同学们复习。

标签：JVM

JIT即时编译技术在JVM中的应用及分析

JVM基础之GC垃圾回收机制详解

JVM基础之JVM内存模型详解

JVM基础之类加载器详解