JVM

• 书籍 - 深入理解java虚拟机
• 资料 - 字节大佬面试宝典相关jvm内容
• 博客 - jvm部分

1. 线程

Hotspot JVM 中的java线程与原生操作系统线程有直接的映射关系。

2. Jvm内存模型

Jvm内存模型是Java虚拟机在运行时为Java进程对内存进行的逻辑划分，将其分为几个部分：

• 方法区（共享）
• 程序计数器（私有）
• Java虚拟机栈（私有）
• 本地方法栈（私有）
• 堆内存（共享）

这些区域分别在不同数据结构对申请到的内存进行不同的使用。

2.1 本地内存

虚拟机没有直接管理但是却使用的物理内存，这些被利用却不在虚拟机内存数据区的内存，称为本地内存。

• 本地内存并不是JVM运行时数据区的一部分，也不是虚拟机规范中定义的内存区域，但是这部分的内存也会被频繁地使用。而且也可能导致OutOfMemoryError异常出现。
• 一般用于直接使用Native函数库直接分配堆外内存，然后通过一个存储在 Java 堆中的 DirectByteBuffer 对象作为这块内存的引用进行操作，这样做可以避免了在 Java 堆和 Native 堆之间来回复制数据，从而提高性能。
• 本地内存的分配不会收到 Java 堆的限制，但是会受到本机物理内存大小以及处理器寻址空间的限制。

2.2 虚拟机内存

Java虚拟机在执行时将管理的内存分配成不同的区域，这些区域被称为虚拟机内存。

受虚拟机内存大小的参数控制，当大小超过参数设置的大小时就会报OOM。

2.2.1 方法区（共享）

「各个线程共享的内存区域」，它「用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据」。

2.2.2 程序计数器（私有）

「程序计数器占用的内存空间很小，主要用来记录执行代码指令的」。

程序计数器通俗的说就是：程序计数器记录当前线程所执行的字节码指令的行号，

「字节码解释器通过改变计数器的值来选取下一条需要执行的字节码指令。分支、循环、跳转、异常处理、线程恢复等功能都需要依赖程序计数器来完成」。

我们知道「Java多线程执行的时候是通过线程轮流切换并分配CPU的时间片的方式实现的，为了线程切换后能恢复到正确的位置继续执行，每条线程都需要有一个独立的程序计数器，各线程之间计数器互不影响，独立存储，因此程序计数器的内存区域为【线程私有】的内存」。

程序计数器的作用：：

• 「字节码解释器通过改变程序计数器来依次读取指令，从而实现代码的流程控制」。如：顺序执行、选择、循环、异常处理。
• 「在多线程的情况下，程序计数器用于记录当前线程执行的位置」，保证当线程被切换回来的时候能够知道自己上次运行到哪儿了。

「注意：程序计数器是唯一不会出现 OutOfMemoryError 的内存区域，它的生命周期随着线程的创建而创建，随着线程的结束而死亡」。

2.2.3 Java虚拟机栈（私有）

我们在写代码的时候，会定义方法，方法里面可能会有一些方法内的局部变量。比如

1
2
3

public static void main(String[] args) {
		int count  = 1;
}

以上这个main方法在运行的时候，会有一个线程来执行它，这个线程就会有一个程序计数器记录这个方法被执行到那一步。在上述案例的main方法中有个count变量，这个变量很显然是main方法的局部变量，那么这个count变量是放在哪里的呢？Java虚拟机栈这个时候就出来了。

「Java虚拟机栈是JVM为保存每个方法的局部变量而划分的内存区域，它是线程私有的，生命周期和线程相同，随着线程的创建而创建，随着线程的死亡而死亡」。先先来看个例子

1
2
3
4
5
6
7

public void funA(){
    System.out.println("funA");
    funB();
}
public void funB(){
    System.out.println("funB");
}

「比如一个线程在执行funA()时，就会将funA()，就会往当前线程的Java虚拟机栈中放一个栈帧，当执行到funB()时，又会往Java虚拟机栈放一个栈帧」。如下:

从上图可以看到，「funA栈帧与funB栈帧的出栈入栈的时机，先入后出」

• funA方法被封装成栈帧入栈
• funB方法被封装成栈帧入栈
• funB方法出栈
• funA方法出栈

「Java虚拟机栈中存放的是由一个个栈帧，【线程在执行一个方法时，便会向栈中放入一个栈帧】，每个栈帧中都拥有【局部变量表】、【操作数栈】、【动态链接】、【方法出口】等信息」。

Java 虚拟机栈会出现两种异常：

• 「StackOverFlowError」

  若Java虚拟机栈的内存大小不允许动态扩展，那么当线程请求栈的深度超过当前Java虚拟机栈的最大深度的时候，就抛出StackOverFlowError异常。

• 「OutOfMemoryError」

  若 Java 虚拟机栈的内存大小允许动态扩展，且当线程请求栈时内存用完了，无法再动态扩展了，此时抛出OutOfMemoryError异常。

2.2.4 本地方法栈（私有）

「看过Java的一些底层API的（IO相关、socket相关等）就会知道，底层已经不是走的Java代码了，而是通过Native 方法调用操作系统的一些方法。调用这些方法也需要一个方法栈，这就是本地方法栈」。它也是线程私有的。

本地方法栈和Java虚拟机栈基本类似，只不过「Java虚拟机栈是为Java代码（字节码）使用的，而本地方法栈则是虚拟机使用到的 Native 方法时使用的」。

• 本地方法被执行的时候，在本地方法栈也会创建一个栈帧，用于存放该本地方法的局部变量表、操作数栈、动态链接、出口信息。
• 方法执行完毕后相应的栈帧也会出栈并释放内存空间，也会出现 StackOverFlowError 和 OutOfMemoryError 两种异常。

2.2.5 堆内存（共享）

通过上述的描述，我们知道「每个线程都会有一个自己的【程序计数器】【Java虚拟机栈】【本地方法栈】，它们的生命周期与当前线程一样」。

前面我们说了，线程在执行一个方法的时候，会将这个方法的栈帧压入自己的虚拟机栈中。而在Java中，调用方法是通过对象去调的。比如：

1
2
3
4
5
6
7
8

public void funA(){
    User user= new User();
    user.queryUserById(id);
}

public void queryUserById(String id){
    System.out.println("queryUserById");
}

以上代码是一个很简答的示例，funA中有一个User对象，通过User对象调用了它的queryUserById方法。此时当前线程的虚拟机栈中就会有funA与queryUserById两个方法的栈帧。但是有个问题，new出来的User对象在哪里呢？

此时就需要使用到JVM中另外一块内存区域了【Java堆内存】，「堆内存是JVM中所管理的最大的一块内存区域，并且是所有线程共享的一块内存区域，堆内存区域的目的就是存放对象实例，在1.7的时候将【字符串常量池】【静态变量】都放进了堆中，这在上面那种图中也有体现」。

看上述案例，在funA方法中创建了User对象，它们的引用关系大致可以用下图来体现：

通过这张图我们可以看到，「当创建一个User对象的时候，User对象实际上会被放到堆内存中，而方法funA中有一个局部变量user指向了这个对象在堆内存中的地址」。

因为堆内存中存放的是对象实例，因此一般我们会把堆内存设置的比较大，主要就是设置以下两个参数

• 「-Xmx：表示堆区的起始内存」
• 「-Xms：表示堆区的最大内存」

对象虽然放在堆内存中，但是它也不是随意乱放，我们都知道JVM是有GC的，为了高效的GC，堆内存是做了更细致的划分的，也就是常说的新生代，老年代，永久代，他们分别对应不同的GC，这部分我会在后续的文章中单独描述，这里就不展开了，反正首先知道对象实例是存放在堆中就可以了。

2.3 元空间

「从 JDK 1.8 开始，HotSpots取消了永久代，并把方法区移至元空间，元空间它位于本地内存中，而不是虚拟机内存中」。

永久代从某种意义上讲并不是去掉了，只是被元空间（「Metaspace」）取代了而已

2.3.1 元空间和永久代的不同

• 「存储位置不同」

  「1.7之前永久代在物理上是堆的一部分，和新生代、老年代的地址是连续的，而元空间属于本地内存」。

• 「存储内容不同」

  在原来的永久代划分中，永久代用来存放类的元数据信息、静态变量以及常量池等。

  「现在类的元信息存储在元空间中，静态变量和常量池等并入堆中，相当于原来的永久代中的数据，被元空间和堆内存给瓜分了。」

2.3.2 永久代有哪些缺点？

在之前的版本中，字符串常量池存在于永久代中，在大量使用字符串的情况下，非常容易出现OOM的异常。此外，「JVM加载的class的总数，方法的大小」等都很难确定，因此对永久代大小的指定难以确定。太小的永久代容易导致永久代内存溢出，太大的永久代则容易导致虚拟机内存紧张。

• 它的大小是在启动时固定好的——很难进行调优。-XX:MaxPermSize，设置成多少好呢？
• HotSpot的内部类型也是Java对象：它可能会在Full GC中被移动，同时它对应用不透明，且是非强类型的，难以跟踪调试，还需要存储元数据的元数据信息（meta-metadata）。
• 简化Full GC：每一个回收器有专门的元数据迭代器。
• 可以在GC不进行暂停的情况下并发地释放类数据。
• 使得原来受限于持久代的一些改进未来有可能实现

2.3.3 废除永久代的好处？

• 废除永久代，引入元空间后，类的元数据存储在本地内存中，「元空间的最大可分配空间就是系统可用内存空间」，大大降低OOM的出现。
• 将元数据从永久代剥离出来到Metaspace，提升对元数据的管理同时提升GC效率。

3. Jvm的分代模型

3.1 分代收集理论

分代收集理论的思想：「根据对象的生命周期将内存划分，然后进行分区管理」。

目前商业虚拟机的垃圾收集器，大多都遵循【分代收集理论】进行设计， 它建立在两个分代假说之上：

• 「弱分代假说」：绝大多数对象都是朝生夕灭的。
• 「强分代假说」：熬过越多次数垃圾回收过程的对象就越难消亡。

这两种设计原则共同奠定了大多数垃圾收集器的一致的设计原则：「应该将Java堆划分出不同的区域，然后将回收对象依据其年龄分配到不同的区域之中存储」。

把那些难以回收的对象放在一起，这个区域的垃圾回收频率就可以降低，减少垃圾回收的开销。

把那些朝生夕灭的对象放在单独的区域，可以用较高的频率去回收。

在Java堆划分出不同的区域之后，垃圾回收器就可以每次只回收自己负责的那一部分区域，因此也就有了我们常说的几种GC：

• 「部分收集（Partial GC）」 ：指收集的不是整个Java堆的垃圾收集， 其中又分为：

  • 「新生代收集（Minor GC/Young GC）」：处理新生代（Eden \ S0,S1）的垃圾回收。

  • 「老年代收集（Major GC/Old GC）」：只处理老年代的垃圾回收，目前只有CMS收集器会有单独收集老年代的行为。

  • 「混合收集（Mixed GC）」：整个新生代以及部分老年代的垃圾收集回收。目前只有G1收集器会有这种行为。

• 「整堆收集（Full GC）」 ：整个Java堆和方法区的垃圾收集。

基于此分代收集理论，JVM将堆内存进行了进一步的划分，分为【新生代】【老年代】，每个区域由不同的GC清理。

Java7：

Java8：

3.2 新生代

在Java程序中，大多数对象的存活时间都是很短的，就比如以下这段代码

1
2
3
4
5
6
7
8

public void funA(){
    User user= new User();
    user.queryUserById(id);
}

public void queryUserById(String id){
    System.out.println("queryUserById");
}

当线程执行了funA后，会「创建一个User对象实例存放在Java堆内存中，此时funA栈帧中局部变量user会指向该对象实例的地址」。

而「当funA 方法执行完成后，funA栈帧会出栈，局部变量也就不存在了，此时User对象实例就没有被引用」了，如下：

此时在JVM后台运行的垃圾回收线程一旦发现了没有被引用的对象实例，它就会将其回收掉，释放堆内存。

以上这个过程，我们的User对象被创建出来就放在堆中，使用完了就立刻销毁，这种对象一般就会在堆内存的第一个区域年轻代中。

「新生代（Young Generation）」：创建之后会优先放在被存放在堆内存的年轻代中，当年轻代放不下的时候才会放在老年代，由于新生代的对象创建销毁频繁，所以Young GC也是执行的非常频繁的。

从上面的图中可以看出来，「新生代内又分三个区：一个Eden区，两个Survivor区（幸存者区）」。

• 「大部分对象在Eden区中生成，当Eden区满时，还存活的对象将被复制到两个Survivor区（其中的一个）中」。
• 「而当某个Survivor区满时，此区存活且不满足【晋升老年代】条件的对象将被复制到另外一个Survivor区」。
• 「这些对象每经历一次Minor GC，它们的年龄会加1，当年龄达到【晋升老年代阈值】后，会被被放到老年代，这个过程就是对象的晋升过程」。

「晋升老年代阈值直接影响着对象在新生代中的停留时间，默认为15」

3.3 老年代

既然上面说了对象被创建后，就会优先放在年轻代中，当年龄到达晋升阈值后才会晋升，那么什么样的对象会被晋升到老年代呢？下面我们改造一下上面的案例

1
2
3
4
5
6
7
8
9
10
11
12
13
14

privatestatic Order order= new Order();
public void funA(){
    User user= new User()
    user.queryUserById(id);
    order.queryOrderById(id);
}

public void queryUserById(String id){
    System.out.println("queryUserById");
}

public void queryOrderById(String id){
    System.out.println("queryOrderById");
}

上面的伪代码中，有一个静态变量order执行了order实例，user变量是存在方法区的（类的静态变量，类信息等是存在方法区的），画一下这个伪代码的图：

注意！！！

「不要被这张图误导，order对象一开始也是存在于新生代的，但是由于它是静态变量，一般而言静态变量，只要类没有销毁都会存在于方法区中，所以它会在新生代存在一段时间，最终会晋升到老年代中」。

那么方法区里面的类啥时候会被销毁呢，这个静态变量是不是会一直存在呢？答案是否定的，方法区里面的类满足以下几种情况下会被销毁。

• 「该类所有的实例对象都已经被回收」
• 「加载这个类的ClassLoader对象被回收了」
• 「该类的Class对象没有任何引用」

满足以上几种情况，方法区的类会被回收，那么它的静态变量自然也就会被回收了，老年代的对象实例也就会被清理了

回来继续看以上伪代码，当我们的funA执行完毕后，funA栈帧出栈，局部变量user被清理，此时User的实例对象就失去了引用，但是此时静态变量order还在引用着Order实例对象。如下:

由以上案例可以得出一个结论：

「年老代主要存放JVM认为生命周期比较长的对象（经过几次的Young Gen的垃圾回收后仍然存在），内存大小相对会比较大，垃圾回收也相对没有那么频繁」。

3.4 为啥要分新生代和老年代？

通过上述的描述，我们已经大致清楚了，Java的堆内存的新生代与老年代分别是存储了什么，那JVM 为啥要这么分呢？这么分有什么好处呢？

其实很好理解，堆虽然是JVM中最大的一块内存区域，但是再大也是有上限的，因此jvm提供了垃圾回收算法来清理那些已经失去引用的对象，而垃圾回收需要判断对象是否已经失去了引用，就需要检查每个对象，这无疑是一笔很大的资源开销。

将堆内存进一步划分，「将那些创建之后很快就会被销毁的对象存放在新生代区域，将那些需要长期存在的对象存放在老年代区域，针对新生代/老年代分别使用不同对策垃圾回收策略，这样就不需要每次进行GC的时候都扫描所有的对象了，减小资源开销」。

3.5 新生代和老年代堆内存占比

堆的内存大小是可以人为设置的，主要受物理内存大小的限制

• 「-Xmx：表示堆区的起始内存」
• 「-Xms：表示堆区的最大内存」

堆被分为新生代和老年代堆，新生代又被分为了三个区。这些内区域是怎么划分的呢？先来看一张图，看图说话：

通过这张图，可以很清晰的看到新生代和老年代在堆中的占比

• 「新生代和老年代占比」

  新生代在堆中的大小由参数【-XX:NewRatio】控制，默认-XX:NewRatio = 2，表示新生代占1 , 老年代占2，新生代占整个堆的1/3

• 「新生代三个区的内存占比」

  新生代的三个区占比默认情况下：「Eden空间和另外两个Survivor空间占比分别为8:1:1」，受参数【-XX:SurvivorRatio】控制，默认-XX:SurvivorRatio = 8，表示Eden::S0:S1= 8:1:1

  几乎所有的java对象都在Eden区创建, 但80%的对象生命周期都很短,创建出来就会被销毁.

「JVM 每次只会使用 Eden 和其中的一块 Survivor 区域来为对象服务，所以无论什么时候，总是有一块 Survivor 区域是空闲着的。因此，新生代实际可用的内存空间为 9/10 的新生代空间」。

4. 对象

4.1 对象的创建过程

明白了堆内存的区域划分和各个区域的内存大小，只是明白了JVM的内存如何分配，在哪里分配而已，但是我们的对象的创建于销毁还与内存回收算法有关系，因此对对象的创建后具体是怎么分配的也要有考虑，中间是否产生了内存碎片等问题。

• 「当我们创建一个对象的时候，这个对象会优先放在Eden区」。

• 「当Eden区放不下了，此时又需要创建新的对象，jvm的垃圾回收器就会对Eden区进行垃圾回收（Minor GC）」

  • 将Eden区没有被引用的对象进行下销毁，有引用的的对象移动到S0区，并将其年龄加1
  • 释放内存，给新的对象分配内存

• 后面再次再次触发垃圾回收，也会做两件事

  • 「清理Eden 和 两个Survivor区中没有被引用的对象」

  • 「将S0区还有引用的对象移动到S1区，年龄加1，将S1区还有引用的对象移动到S0区，年龄加1」：这个过程其实就是在互换S0与S1区的对象，以达到其增加年龄，并整理内存碎片的目的

• 「当S1或者S0区的对象年龄达到阈值后，就会被移动到老年代中」：阈值可以通过参数 -XX:MaxTenuringThreshold设置，比如 -XX:MaxTenuringThreshold = 10

• 「当对象移动到老年代区时，老年代内存不足，也会触发GC（Minor GC）进行老年代的清理」：如果老年代清理之后，新的对象还是放不进去，就会OOM异常

4.2 对象的内存分布

4.2.1 对象头

• 对象自身运行数据

  MarkWord用于存储对象自身的运行时数据， 如哈希码（HashCode）、GC分代年龄、同步锁信息、偏向锁标识等等。Mark Word在32位JVM中的长度是32bit，在64位JVM中长度是64bit。

  通常我们都是使用的64位的JVM，Mark Word 在64位 JVM 中内部结构如下图：

  

• 类型指针

  类型指针指向对象的类元数据，虚拟机通过这个指针确定该对象是哪个类的实例。Java对象的类数据保存在方法区。

• 数组长度（如果有）

  如果对象是一个数组，那么对象头还需要有额外的空间用于存储数组的长度。如果对象是数组类型，因为JVM虚拟机可以通过Java对象的元数据信息确定Java对象的大小，但是无法从数组的元数据来确认数组的大小，所以用一块来记录数组长度。

4.2.2 实例数据

实例数据部分存放类的属性数据信息，包括父类的属性信息。

通过示例说明每个区域具体存放哪些内容：

1
2
3
4
5
6
7
8
9
10
11
12

class Student {
    private String name;
    public Student(String name) {
        this.name = name;
    }
}
public class Demo {
    public static void main(String[] args) {
        Student studentA = new Student("zhangsan");
        Student studentB = new Student("lisi");
    }
}

4.2.3 对齐填充

由于虚拟机要求对象起始地址必须是8字节的整数倍，所以后面有几个字节用于把对象的大小补齐至8字节的整数倍，没有特别的功能，对齐填充不是必须存在的，仅仅是为了字节对齐。

为什么必须是8个字节？

根据“计算机组成原理”，8个字节是计算机读取和存储的最佳实践。

4.3 对象的访问定位

需要说明的是，HotSpot 采用第二种方式，即直接指针方式来访问对象，只需要一次寻址操作，所以在性能上比句柄访问方式快一倍。它需要额外的策略来存储对象在方法区中类信息的地址。

• 使用句柄

  堆中需要有一块叫做“句柄池”的内存空间，句柄中包含了对象实例数据与类型数据各自的具体地址信息。

  引用类型的变量存放的是该对象的句柄地址（reference）。访问对象时，首先需要通过引用类型的变量找到该对象的句柄，然后根据句柄中对象的地址找到对象。

• 直接指针

  引用类型的变量直接存放对象的地址，从而不需要句柄池，通过引用能够直接访问对象。但对象所在的内存空间需要额外的策略存储对象所属的类信息的地址。

5. 垃圾回收算法

1. 什么是GC?

   GC 是 Garbage Collection 的简称，中文称为“垃圾回收”。GC ，是指程序把不用的内存空间视为垃圾并回收掉的整套动作。

   GC 要做的有两件事：

   1. 找到内存空间里的垃圾；
   2. 回收垃圾，让程序能再次利用这部分空间。

   满足这两项功能的程序就是 GC。

2. 为什么要有GC

   在没有 GC 的世界里，程序员必须自己手动进行内存管理，必须清楚地确保必要的内存空间，释放不要的内存空间。

   程序员在手动进行内存管理时，申请内存尚不存在什么问题，但在释放不要的内存空间时，就必须一个不漏地释放。这非常麻烦，容易发生下面三种问题：内存泄露，悬垂指针，错误释放引发 BUG。

   1. 如果忘记释放内存空间，该内存空间就会发生内存泄露（内存空间在使用完毕后未释放），即无法被使用，但它又会持续存在下去。如果将发生内存泄露的程序放着不管，总有一刻内存会被占满，甚至还可能导致系统崩溃。
   2. 在释放内存空间时，如果忘记初始化指向已经回收的内存地址（对象已释放）的指针，这个指针就会一直指向释放完毕的内存空间。此时，这个指针处于一种悬挂的状态，我们称其为“悬垂指针”（dangling pointer）。如果在程序中错误地引用了悬垂指针， 就会产生无法预期的 BUG。
   3. 一旦错误释放了使用中的内存空间，下一次程序使用此空间时就会发生故障。大多数情况下会发生段错误，运气不好的话还可能引发恶性 BUG，甚至引发安全漏洞。

   为了省去上述手动内存管理的麻烦，人们钻研开发出了 GC。如果把内存管理交给计算机， 程序员就不用去想着释放内存了。

   当然，技术领域的不变法则就是万事皆有代价，GC 也会带来一些麻烦，比如后台程序需要耗费一定的 CPU 和内存资源去释放内存，在系统繁忙的情况下会对业务程序性能造成一定的不利影响。为了解决 GC 带来的问题，最近几年出现了一门新的没有 GC 的 Rust 语言，大有替代 C 语言的趋势，不过学习曲线比较陡峭，感兴趣的同学可以自行钻研。

3. GC相关的基本术语

   1. 对象、指针、活动对象、非活动对象、堆、根

      GC 操作的基本单元可以叫做对象。对象是内存空间的某些数据的集合。在本文中，对象由头(header)和域(field)构成。

      对象的头，主要包含对象的大小、种类信息。对象中可访问的部分称为“域”，可以认为是 C 语言中结构体的成员变量。

      

      指针是指向内存空间中某块区域的值。GC 是根据对象的指针指向去搜寻其他对象的。

      

      我们将内存空间中被其他对象通过指针引用的对象成为活动对象，没有对象引用的对象是非活动对象，也就是 GC 需要回收的垃圾。

      

      根(root)是“根基”“根底”。在 GC 的世界里，根是指向对象的指针的“起点” 部分。堆指的是用于动态（也就是执行程序时）存放对象的内存空间。当应用程序申请存放对象时， 所需的内存空间就会从这个堆中被分配给应用程序。

      

   2. GC算法性能的评价标准

      • 吞吐量

        GC 的吞吐量是：运行用户代码时间 / (运行用户代码时间 + 垃圾收集时间)。

      • 最大暂停时间

        因执行 GC 而暂停执行应用程序的最长时间

      • 堆使用效率

        程序在运行过程中，单位时间内能使用的堆内存空间的大小。

        堆使用效率和吞吐量，以及最大暂停时间不可兼得。简单地说就是：可用的堆越大，GC 运行越快；相反，越想有效地利用有限的堆，GC 花费的时间就越长。

      • 访问的局部性

        计算机上有 4 种存储器，分别是寄存器、缓存、内存、辅助存储器。

        

        众所周知，越是可实现高速存取的存储器容量就越小。计算机会尽可能地利用较高速的存储器，但由于高速的存储器容量小，不可能把所有要利用的数据都放在寄存器和高速缓存里。一般我们会把所有的数据都放在内存里，当 CPU 访问数据时，仅把要使用的数据从内存读取到缓存。由于数据是分块读取，我们还将它附近的所有数据都读取到高速缓存中， 从而压缩读取数据所需要的时间。这种内存空间中相邻的数据很可能存在连续访问因而带来访问效率提升的情况，称为“访问的局部性”。

        部分 GC 算法会利用这种局部性原理，把具有引用关系的对象安排在堆中较近的位置，就能提高在缓存 Cache 中读取到想要的数据的概率，令应用程序高速运行。

5.1 如何确定垃圾？

• 引用计数法

  在 Java 中，引用和对象是有关联的。如果要操作对象则必须用引用进行。因此，很显然一个简单的办法是通过引用计数来判断一个对象是否可以回收。简单说，即一个对象如果没有任何与之关联的引用，即他们的引用计数都不为 0，则说明对象不太可能再被用到，那么这个对象就是可回收对象。

• 可达性分析算法

  为了解决引用计数法的循环引用问题，Java 使用了可达性分析的方法。通过一系列的“GC roots”对象作为起点搜索。如果在“GC roots”和一个对象之间没有可达路径，则称该对象是不可达的。

  要注意的是，不可达对象不等价于可回收对象，不可达对象变为可回收对象至少要经过两次标记过程。两次标记后仍然是可回收对象，则将面临回收。

  GC Roots的对象包括：

  • 栈帧中的局部变量表中的reference引用所引用的对象
  • 方法区中static静态引用的对象
  • 方法区中final常量引用的对象
  • 本地方法栈中JNI(Native方法)引用的对象
  • Java虚拟机内部的引用， 如基本数据类型对应的Class对象， 一些常驻的异常对象（比如 NullPointExcepiton、 OutOfMemoryError） 等，
  • 系统类加载器。所有被同步锁（synchronized关键字） 持有的对象。

5.2 GC 标记-清除算法(Mark-Sweep)

最基础的垃圾回收算法，分为两个阶段，标注和清除。标记阶段标记出所有需要回收的对象，清除阶段回收被标记的对象所占用的空间。如图：

从图中我们就可以发现，该算法最大的问题是内存碎片化严重，后续可能发生大对象不能找到可利用空间的问题。

5.3 复制算法(Copying)

为了解决 Mark-Sweep 算法内存碎片化的缺陷而被提出的算法。按内存容量将内存划分为等大小的两块。每次只使用其中一块，当这一块内存满后将尚存活的对象复制到另一块上去，把已使用的内存清掉，如图：

这种算法虽然实现简单，内存效率高，不易产生碎片，但是最大的问题是可用内存被压缩到了原本的一半。且存活对象增多的话，Copying 算法的效率会大大降低。

5.4 标记-压缩算法(Mark-Compact)

结合了以上两个算法，为了避免缺陷而提出。标记阶段和 Mark-Sweep 算法相同，标记后不是清理对象，而是将存活对象移向内存的一端。然后清除端边界外的对象。如图：

5.5 分代收集算法

分代收集法是目前大部分 JVM 所采用的方法，其核心思想是根据对象存活的不同生命周期将内存划分为不同的域，一般情况下将 GC 堆划分为老生代(Tenured/Old Generation)和新生代(Young Generation)。老生代的特点是每次垃圾回收时只有少量对象需要被回收，新生代的特点是每次垃圾回收时都有大量垃圾需要被回收，因此可以根据不同区域选择不同的算法。

• 优缺点

  • 优点：

    “很多对象年纪轻轻就会死”这一经验适合大多数情况，新生代 GC 只将刚生成的对象当成对象，这样一来就能减少时间上的消耗。分代垃圾回收可以改善 GC 所花费的时间(吞吐量)。“据实验表明，分代垃圾回收花费的时间是 GC 复制算法的 1/4。”

  • 缺点：

    “很多对象年纪轻轻就会死”这个法则毕竟只适合大多数情况，并不适用于所有程序。对对象会活得很久的程序执行分代垃圾回收，就会产生以下两个问题。

    • 新生代 GC 所花费的时间增多。
    • 老年代 GC 频繁运行。

• 改进

  • 多代垃圾回收

    分代垃圾回收将对象分为新生代和老年代，通过尽量减少从新生代晋升到老年代的对象， 来减少在老年代对象上消耗的垃圾回收的时间。

    基于这个理论，大家可能会想到分为 3 代或 4 代岂不更好？这样一来能晋升到最老一代的对象不就更少了吗？这种方法就叫作多代垃圾回收(Multi-generational GC)。

    

    在这个方法中，除了最老的那一代之外，每代都有一个记录集。X 代的记录集只记录来自比 X 老的其他代的引用。

    分代数量越多，对象变成垃圾的机会也就越大，所以这个方法确实能减少活到最老代的对象。

    但是我们也不能过度增加分代数量。分代数量越多，每代的空间也就相应地变小了，这样一来各代之间的引用就变多了，各代中垃圾回收花费的时间也就越来越长了。

5.5.1 新生代与复制算法

目前大部分 JVM 的 GC 对于新生代都采取 Copying 算法，因为新生代中每次垃圾回收都要回收大部分对象，即要复制的操作比较少，但通常并不是按照 1：1 来划分新生代。一般将新生代划分为一块较大的 Eden 空间和两个较小的 Survivor 空间(From Space, To Space)，每次使用Eden 空间和其中的一块 Survivor 空间，当进行回收时，将该两块空间中还存活的对象复制到另一块 Survivor 空间中。

5.5.2 老年代与标记复制算法

而老年代因为每次只回收少量对象，因而采用 Mark-Compact 算法。

1. JAVA 虚拟机提到过的处于方法区的永生代(Permanet Generation)，它用来存储 class 类，常量，方法描述等。对永生代的回收主要包括废弃常量和无用的类。
2. 对象的内存分配主要在新生代的 Eden Space 和 Survivor Space 的 From Space(Survivor 目前存放对象的那一块)，少数情况会直接分配到老生代。
3. 当新生代的 Eden Space 和 From Space 空间不足时就会发生一次 GC，进行 GC 后，Eden Space 和 From Space 区的存活对象会被挪到 To Space，然后将 Eden Space 和 From Space 进行清理。
4. 如果 To Space 无法足够存储某个对象，则将这个对象存储到老生代。
5. 在进行 GC 后，使用的便是 Eden Space 和 To Space 了，如此反复循环。
6. 当对象在 Survivor 区躲过一次 GC 后，其年龄就会+1。默认情况下年龄到达 15 的对象会被移到老生代中。

5.5.3 分代垃圾回收的基本原理

分代垃圾回收算法把对分成了四个空间，分别是生成空间、2 个大小相等的幸存空间以及老年代空间。新生代对象会被分配到新生代空间，老年代对象则会被分配到老年代空间里。

应用程序创建的新对象一般会放到新生代空间里，当生成空间满了的时候，新生代 GC 就会启动，将生成空间中的所有活动对象复制，这跟 GC 复制算法是一个道理，复制的目标空间是幸存空间。

2 个幸存空间和 GC 复制算法里的 From 空间、To 空间很像，我们经常只利用其中的一个。在每次执行新生代 GC 的时候，活动对象就会被复制到另一个幸存空间里。在此我们将正在使用的幸存空间作为 From 幸存空间，将没有使用的幸存空间作为 To 幸存空间。

新生代 GC 也必须复制生成空间里的对象。也就是说，生成空间和 From 幸存空间这两个空间里的活动对象都会被复制到 To 幸存空间里去——这就是新生代 GC。

只有从一定次数的新生代 GC 中存活下来的对象才会得到晋升，也就是会被复制到老年代空间去。

在执行新生代 GC 时需要注意，需要考虑到从老年代空间到新生代空间的引用。新生代对象不只会被根和新生代空间引用，也可能被老年代对象引用。因此，除了一般 GC 里的根，还需要将从老年代空间的引用当作根(像根一样的东西)来处理。

这里，使用记录集用来记录从老年代对象到新生代对象的引用。这样在新生代 GC 时就可以不搜索老年代空间的所有对象，只通过搜索记录集来发现从老年代对象到新生代对象的引用。

通过新生代 GC 得到晋升的对象把老年代空间占满后，就要执行老年代 GC 了。老年代 GC 没什么难的地方，它只用到了GC 标记-清除算法。

6. GC垃圾收集器

6.1 Serial垃圾收集器(单线程、复制算法)

Serial（英文连续）是最基本垃圾收集器，使用复制算法，曾经是JDK1.3.1 之前新生代唯一的垃圾收集器。Serial 是一个单线程的收集器，它不但只会使用一个 CPU 或一条线程去完成垃圾收集工作，并且在进行垃圾收集的同时，必须暂停其他所有的工作线程，直到垃圾收集结束。

Serial 垃圾收集器虽然在收集垃圾过程中需要暂停所有其他的工作线程，但是它简单高效，对于限定单个 CPU 环境来说，没有线程交互的开销，可以获得最高的单线程垃圾收集效率，因此 Serial垃圾收集器依然是 java 虚拟机运行在 Client 模式下默认的新生代垃圾收集器。

6.2 ParNew垃圾收集器(Serial+多线程)

ParNew 垃圾收集器其实是 Serial 收集器的多线程版本，也使用复制算法，除了使用多线程进行垃圾收集之外，其余的行为和 Serial 收集器完全一样，ParNew 垃圾收集器在垃圾收集过程中同样也要暂停所有其他的工作线程。

ParNew 收集器默认开启和 CPU 数目相同的线程数，可以通过-XX:ParallelGCThreads 参数来限制垃圾收集器的线程数。【Parallel：平行的】

ParNew虽然是除了多线程外和Serial 收集器几乎完全一样，但是ParNew垃圾收集器是很多 java虚拟机运行在 Server 模式下新生代的默认垃圾收集器。

6.3 Parallel Scavenge收集器(多线程复制算法、高效)

Parallel Scavenge 收集器也是一个新生代垃圾收集器，同样使用复制算法，也是一个多线程的垃圾收集器，它重点关注的是程序达到一个可控制的吞吐量（Thoughput，CPU 用于运行用户代码的时间/CPU 总消耗时间，即吞吐量=运行用户代码时间/(运行用户代码时间+垃圾收集时间)），

高吞吐量可以最高效率地利用 CPU 时间，尽快地完成程序的运算任务，主要适用于在后台运算而不需要太多交互的任务。自适应调节策略也是 ParallelScavenge 收集器与 ParNew 收集器的一个重要区别。

6.4 Serial Old收集器(单线程标记整理算法)

Serial Old 是 Serial 垃圾收集器年老代版本，它同样是个单线程的收集器，使用标记-整理算法，这个收集器也主要是运行在 Client 默认的 java 虚拟机默认的年老代垃圾收集器。

在 Server 模式下，主要有两个用途：

1. 在 JDK1.5 之前版本中与新生代的 Parallel Scavenge 收集器搭配使用。

2. 作为年老代中使用 CMS 收集器的后备垃圾收集方案。

新生代 Serial 与年老代 Serial Old 搭配垃圾收集过程图：

新生代 Parallel Scavenge 收集器与 ParNew 收集器工作原理类似，都是多线程的收集器，都使用的是复制算法，在垃圾收集过程中都需要暂停所有的工作线程。新生代 Parallel Scavenge/ParNew 与年老代 Serial Old 搭配垃圾收集过程图：

6.5 Parallel Old收集器(多线程标记整理算法)

Parallel Old 收集器是Parallel Scavenge的年老代版本，使用多线程的标记-整理算法，在 JDK1.6才开始提供。

在 JDK1.6 之前，新生代使用 ParallelScavenge 收集器只能搭配年老代的 Serial Old 收集器，只能保证新生代的吞吐量优先，无法保证整体的吞吐量，Parallel Old 正是为了在年老代同样提供吞吐量优先的垃圾收集器，如果系统对吞吐量要求比较高，可以优先考虑新生代 Parallel Scavenge和年老代 Parallel Old 收集器的搭配策略。

新生代 Parallel Scavenge 和年老代 Parallel Old 收集器搭配运行过程图：

6.6 CMS收集器(多线程标记清除算法)

Concurrent mark sweep(CMS)收集器是一种年老代垃圾收集器，其最主要目标是获取最短垃圾回收停顿时间，和其他年老代使用标记-整理算法不同，它使用多线程的标记-清除算法。

最短的垃圾收集停顿时间可以为交互比较高的程序提高用户体验。

CMS 工作机制相比其他的垃圾收集器来说更复杂，整个过程分为以下 4 个阶段：

1. 初始标记

   只是标记一下 GC Roots 能直接关联的对象，速度很快，仍然需要暂停所有的工作线程。

2. 并发标记

   进行 GC Roots 跟踪的过程，和用户线程一起工作，不需要暂停工作线程。

3. 重新标记

   为了修正在并发标记期间，因用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，仍然需要暂停所有的工作线程。

4. 并发清除

   清除 GC Roots 不可达对象，和用户线程一起工作，不需要暂停工作线程。由于耗时最长的并发标记和并发清除过程中，垃圾收集线程可以和用户现在一起并发工作，所以总体上来看CMS 收集器的内存回收和用户线程是一起并发地执行。

CMS 收集器工作过程：

6.7 G1收集器

Garbage first 垃圾收集器是目前垃圾收集器理论发展的最前沿成果，相比与 CMS 收集器，G1 收集器两个最突出的改进是：

1. 基于标记-整理算法，不产生内存碎片。

2. 可以非常精确控制停顿时间，在不牺牲吞吐量前提下，实现低停顿垃圾回收。

G1 收集器避免全区域垃圾收集，它把堆内存划分为大小固定的几个独立区域，并且跟踪这些区域的垃圾收集进度，同时在后台维护一个优先级列表，每次根据所允许的收集时间，优先回收垃圾最多的区域。区域划分和优先级区域回收机制，确保 G1 收集器可以在有限时间获得最高的垃圾收集效率。

7. Java从编译到执行的过程

1
2
3
4
5
6

<dependency>
   <groupId>org.openjdk.jol</groupId>
   <artifactId>jol-core</artifactId>
   <version>0.9</version>
</dependency>

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

public class ObjectHeaderTest {

    public static void main(String[] args) {
        System.out.println("=========打印Object对象的大小========");
        ClassLayout layout = ClassLayout.parseInstance(new Object());
        System.out.println(layout.toPrintable());


        System.out.println("========打印数组对象的大小=========");
        ClassLayout layout1 = ClassLayout.parseInstance(new int[]{});
        System.out.println(layout1.toPrintable());


        System.out.println("========打印有成员变量的对象大小=========");
        ClassLayout layout2 = ClassLayout.parseInstance(new ArtisanTest());
        System.out.println(layout2.toPrintable());
    }

    /**
     * ‐XX:+UseCompressedOops 表示开启压缩普通对象指针
     * ‐XX:+UseCompressedClassPointers 表示开启压缩类指针
     *
     */
    public static class ArtisanTest {

        int id;        //4B
        String name;   //4B
        byte b;        //1B
        Object o;      //4B
    }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

=========打印Object对象的大小========
java.lang.Object object internals:
 OFFSET  SIZE   TYPE DESCRIPTION                               VALUE
      0     4        (object header)                           01 00 00 00 (00000001 00000000 00000000 00000000) (1)
      4     4        (object header)                           00 00 00 00 (00000000 00000000 00000000 00000000) (0)
      8     4        (object header)                           e5 01 00 f8 (11100101 00000001 00000000 11111000) (-134217243)
     12     4        (loss due to the next object alignment)
Instance size: 16 bytes
Space losses: 0 bytes internal + 4 bytes external = 4 bytes total

========打印数组对象的大小=========
[I object internals:
 OFFSET  SIZE   TYPE DESCRIPTION                               VALUE
      0     4        (object header)                           01 00 00 00 (00000001 00000000 00000000 00000000) (1)
      4     4        (object header)                           00 00 00 00 (00000000 00000000 00000000 00000000) (0)
      8     4        (object header)                           6d 01 00 f8 (01101101 00000001 00000000 11111000) (-134217363)
     12     4        (object header)                           00 00 00 00 (00000000 00000000 00000000 00000000) (0)
     16     0    int [I.<elements>                             N/A
Instance size: 16 bytes
Space losses: 0 bytes internal + 0 bytes external = 0 bytes total

========打印有成员变量的对象大小=========
com.example.myspringboot001.test.ObjectHeaderTest$ArtisanTest object internals:
 OFFSET  SIZE               TYPE DESCRIPTION                               VALUE
      0     4                    (object header)                           01 00 00 00 (00000001 00000000 00000000 00000000) (1)
      4     4                    (object header)                           00 00 00 00 (00000000 00000000 00000000 00000000) (0)
      8     4                    (object header)                           61 e0 00 f8 (01100001 11100000 00000000 11111000) (-134160287)
     12     4                int ArtisanTest.id                            0
     16     1               byte ArtisanTest.b                             0
     17     3                    (alignment/padding gap)                  
     20     4   java.lang.String ArtisanTest.name                          null
     24     4   java.lang.Object ArtisanTest.o                             null
     28     4                    (loss due to the next object alignment)
Instance size: 32 bytes
Space losses: 3 bytes internal + 4 bytes external = 7 bytes total

7.1 Java的运行过程

「一个Java程序从.Java文件被加载到jvm中，直到被编译成指令码被系统执行的全过程。」

7.1.1 编译

一个java文件要被计算机识别，第一步编译：「要将java源码文件编程成JVM可以解释的class文件。在编译过程中程会对源代码程序做【词法分析】【语法分析】【语义分析】【编译优化】最后生成字节码文件」。

【词法分析】

.java文件本质上只是一段字符，要识别这串字符，就需要把字符进行读取处理，将这串字符里面的单词和标点符号等进行识别，「我们在写程序的时候会使用到关键字、标识符、字面量、操作符号等，这些在程序中被称之为token，将一串字符字符串转换为 Token 的过程，就叫做词法分析」。

空白字符代表空格、tab、换行符。EOF是结束符

【语法分析】

当将一串字符解析出 Token后，就需要理解它的语法结构，「将其转换成成一个体现语法规则的、树状的数据结构」，这个数据结构叫做「抽象语法树」（AST，Abstract Syntax Tree）。

比如我们定义了一个函数，定义了函数的返回值类型，函数名称，参数以及函数体等，那么它通过语法分析得到的抽象语法树如下:

可以看到这棵 AST 一共四层， 反映了函数的语法结构。分为四层，将函数体里面包含的多个语句，如变量声明语句、返回语句，拆分成函数体的子节点，直到不可拆分的叶子节点。「叶子节点就是词法分析阶段生成的 Token（带方框的部分），当对这棵 AST 做深度优先的遍历，就能依次得到所需要的 Token」。

【语义分析】

负责检查抽象语法树的上下文相关属性

• 变量使用前，需要事先定义
• 变量运算时，类型需要匹配
• 变量的作用域问题
• 还有一些优化等等

【编译优化】

比如「对泛型的擦除」和经常使用的「Lombok的解析」等等。

通过上述四个步骤之后，我们的Java文件就会编译成一个class文件，提供给下一个阶段加载。

7.1.2 加载

加载阶段就是「将编译后的class文件加载到JVM中」。在加载阶段又可以细为【装载】【连接】【初始化】三个步骤。

7.1.2.1 装载

也就是我们常说的类加载，那么是什么是装载呢？

比如说：在程序执行过程中，「JVM在执行某段代码时，需要使用到class A，而此时在内存中没有找到class A的相关信息，于是JVM就会到相应的Class文件中查找class A的类信息，然后将其加载到内存中，这个过程就是类加载过程」。

通过上面的过程我们可以总结出类加载过程

• 「装载时机」

  「JVM不是一开始就把所有的类都加载进内存中」，而是只有第一次需要运行某个类时才会加载，且「只加载一次」。

  比如new和反射的时候加载

• 「装载过程」

  Java虚拟机通过【类加载器】将class文件装载到jvm中的，并对数据进行校验、转换解析和初始化，最终形成可以被虚拟机使用的Java类型。

• 「装载方式」

  在装载过程中为了防止内存中重复加载，使用了双亲委派机制。

  JDK 中的本地方法类一般由启动类加载器（Bootstrp loader）装载

  JDK 中内部实现的扩展类一般由扩展加载器（ExtClassLoader ）实现装载，

  程序中的类文件则由系统加载器（AppClassLoader ）实现装载。

• 「总结」

  「加载是一个读取calss文件，将其转化为某种静态数据结构存储在方法区内，并在JVM堆中生成一个便于用户调用的java.lang.Class类型的对象的过程」。

• • 字节码来源：本地class文件、jar包class文件、远程网络、动态代理
  • 类加载器：启动类加载器、扩展类加载器、应用类加载器、自定义类加载器

7.1.2.2 连接

主要是「对class的信息进行验证、为「类变量」分配内存空间并对其赋默认值，将类的字节码连接到JVM的运行状态之中」。这个过程一般又被分为【验证】【准备】【解析】。

• 「验证」

  验证Class类是否符合 Java 规范和 JVM 规范，验证主要包括以下几个方面的验证：

  • 文件格式的验证，验证字节流是否符合Class文件的规范，是否能被当前版本的虚拟机处理
  • 元数据验证，对字节码描述的信息进行语义分析，确保符合java语言规范。
  • 字节码验证，通过数据流和控制流分析，确定语义是合法的，符合逻辑的。
  • 符号引用验证，这个校验在解析阶段发生，对class静态结构进行语法和语义上的分析，保证其不会产生危害jvm的行为。

• 「准备」：「为类的静态变量在方法区分配内存，初始化为【系统】的初始值」。

  这里要注意，「在准备阶段的赋值不是我们代码中写的初始值，而是Java虚拟机根据不同变量类型的默认初始值」。

  比如：

  1 2	public static int a=7 // 这里在准备阶段过后a的初始值为0，而不是7

• 「解析」：「将【常量池】中的符号引用替换为直接引用（内存地址）的过程（如物理内存地址指针），这个阶段有时候会在初始化之后执行」，分为两种情况：

  1. 「将符号引用替换为直接引用」

     有两个类A中引用了B，在编译阶段A是无法知道B有没有被编译的，此时A无法获取B准确的地址，如果A要找到B，就需要在A中「通过一个字符串来代替B的地址，这个字符串就是符号引用」。

     当运行的时候A被加载了，到解析的时候发现被A引用的B还没有被加载，此时就会触发B的类加载，「当B被加载到JVM中后，此时A的符号引用就会被替换为B的内存地址，也就是直接引用」。

  2. 「java多态，实现后期绑定」：第一种方式是A引用B的时候，B是一个确定的实现类，是唯一的，这种方式称为静态解析。但是当A调用的B是一个抽象类或接口，它又多个实现的时候，怎么知道引用那个具体的实现呢？

     如果A引用的B是一个拥有多个实现类的抽象类或者接口，这种情况解析阶段并不知道应该引用B的那个实现类，此时就只能先不解析，「等到在运行过程中发生具体的调用的时候，java虚拟机栈得到具体的类信息，此时再进行解析，就可以明确A引用的B用那个实现类的地址了，这也是前面说的解析阶段有时候会在初始化之后执行的原因」。

7.1.2.3 初始化

「为类的静态变量赋予正确的初始值」。

对class的成员变量、静态变量、静态代码块的赋值，如果有【实例化对象】，则会调用方法对实例变量进行初始化，并执行对应的构造方法内的代码。

比如：

1

public static int a=7

在准备阶段，a被赋值了系统默认的初始值0，此时初始化阶段就会将其重新赋值为7。到这里就完成了加载阶段。

「也就是说在初始化过程中，jvm才真正开始执行类中定义的java代码。」

• 初始化阶段主要是执行类构造器clinit()方法的过程。类构造器clinit()方法是由编译器自动收集类中的所有类变量的赋值动作和静态代码块中的语句合并产生的。
• 当初始化一个类的时候，如果发现其父类还没有进行过初始化、则需要先触发其父类的初始化。
• 虚拟机会保证一个类的clinit()方法在多线程环境中被正确加锁和同步。

7.1.3 解释

「解释阶段：把字节码转换为操作系统识别的指令」。

java文件通过「javac」编译成class文件，这种中间码被称为字节码。然后由JVM加载字节码，

初始化完成之后，当我们尝试执行一个类的方法时，会找到对应方法的字节码的信息，然后解释器会把字节码信息解释成一行行系统能识别的指令码来执行。

这个过程「会通过【字节码解释器】【即时编译器(JIT)】相互配合，使java程序几乎能达到和编译型语言一样的执行效率」。

• 「字节码解释器」

  通俗讲：就是将字节码拿过来，翻译成指令码，给系统执行。就跟中英文翻译官一样。

• 「即时编译器(JIT)」

  通俗讲：其实跟解释器做的事情差不多。也是将字节码拿过来，翻译成指令码，只不过会将指令码保存起来，下次不用翻译了，直接用就行。

在程序运行时，「当JVM发现某个方法或代码块的运行特别频繁的时候，就会把将其认定为【热点代码】，即时编译器(JIT)会将【热点代码】的字节码编译成指令码并保存起来，下次执行的时候就无需重复的进行解释，直接执行缓存的机器语言」。

那么问题来了，怎么界定是不是热点代码呢???

在JVM中有个【热点探测】的机制，就是用来检查是否为热点代码的。主要有两种方式：

• 「基于采样的热点探测」

  「采用采样探测的虚拟机，会周期性的检查每个线程的虚拟机栈栈顶，记录每个方法出现在栈顶的次数，达到阈值后就会认为是热点方法」。

  这种方式「简单高效，但是不准确」，因为可能由于线程阻塞而导致某个方法一直在栈顶

• 「基于计数器的热点探测」

  「采用计数器探测的虚拟机，会为每个方法或者代码块建立一个计数器，统计方法的执行次数。达到阈值后就会认为是热点方法」。

  这种方式要维护计数器「，实现相对采用复杂一些，但是结果相对精准」。

到这里我们就知道了，上述两种探测方式都有一个阈值，「当到达阈值后就会认为是热点代码，从而触发JIT编译，将编译后的指令码保存起来，下次直接无需解释，直接使用」。

7.1.4 执行

「操作系统把解释器解析出来的指令码，调用系统的硬件执行最终的程序指令」。

7.2 clinit和init

「在编译生成class文件时，编译器会产生两个方法加于class文件中，一个是类的初始化方法clinit, 另一个是实例的初始化方法init」。

7.2.1 类的初始化方法clinit

• 「如果类中没有静态变量或静态代码块，则clinit方法将不会被生成」。
• 在执行clinit方法时，必须先执行父类的clinit方法。
• clinit方法只执行一次。
• static变量的赋值操作和静态代码块的合并顺序由源文件中出现的顺序决定

7.2.2 实例的初始化方法init

「init指的是实例构造器，主要作用是在类实例化过程中执行，执行内容包括非静态成员变量初始化和代码块的执行」。

• 「如果类中没有成员变量和代码块，那么init方法将不会被生成」。
• 在执行init方法时，必须先执行父类的init方法。
• init方法每实例化一次就会执行一次。
• init方法先为实例变量分配内存空间，再执行赋默认值，然后根据源码中的顺序执行赋初值或代码块。