JVM 知识点汇总

首先看看 JVM 的知识点汇总。

如上图所示，JVM 知识点有 6 个大方向，其中，内存模型、类加载机制、GC 垃圾回收是比较重点的内容。性能调优部分偏重实际应用，重点突出实践能力。编译器优化和执行模式部分偏重理论基础，主要掌握知识点。

各个部分需要了解的知识点如下。

• 内存模型：程序计数器、方法区、堆、栈、本地方法栈的作用，保存哪些数据。
• 类加载：双亲委派的加载机制，以及常用类加载器分别加载哪种类型的类。
• GC：分代回收的思想和依据，以及不同垃圾回收算法实现的思路、适合的场景。
• 性能调优：常用的 JVM 优化参数的作用，参数调优的依据，常用的 JVM 分析工具能分析哪类问题，以及使用方法。
• 执行模式：解释、编译、混合模式的优缺点，Java7 提供的分层编译技术。需要知道 JIT 即时编译技术和 OSR（栈上替换），知道 C1、C2 编译器针对的场景，其中 C2 针对 Server 模式，优化更激进。在新技术方面可以了解 Java10 提供的由 Java 实现的 Graal 编译器。
• 编译优化：前端编译器 javac 的编译过程、AST 抽象语法树、编译期优化和运行期优化。编译优化的常用技术包括公共子表达式的消除、方法内联、逃逸分析、栈上分配、同步消除等。明白了这些才能写出对编译器友好的代码。

详解 JVM 内存模型

JVM 内存模型主要指运行时的数据区，包括 5 个部分，如下图所示。

• 栈也叫方法栈，是线程私有的，线程在执行每个方法时都会同时创建一个栈帧，用来存储局部变量表、操作栈、动态链接、方法出口等信息。调用方法时执行入栈，方法返回时执行出栈。
  

• 本地方法栈与栈类似，也是用来保存线程执行方法时的信息，不同的是，执行 Java 方法使用栈，而执行 native 方法使用本地方法栈。

• 程序计数器保存着当前线程所执行的字节码位置，各线程之间独立存储，互不影响。程序计数器是一块很小的内存空间，主要用来记录各个线程执行的字节码的地址，例如，分支、循环、跳转、异常、线程恢复等都依赖于计数器。
  由于 Java 是多线程语言，当执行的线程数量超过 CPU 核数时，线程之间会根据时间片轮询争夺 CPU 资源。如果一个线程的时间片用完了，或者是其它原因导致这个线程的 CPU 资源被提前抢夺，那么这个退出的线程就需要单独的一个程序计数器，来记录下一条运行的指令。程序计数器也是JVM中唯一不会OOM(OutOfMemory)的内存区域
  程序计数器为执行 Java 方法服务，执行 native 方法时，程序计数器为空。

栈、本地方法栈、程序计数器这三个部分都是线程独占的。

• 堆是 JVM 管理的内存中最大的一块，堆被所有线程共享，目的是为了存放对象实例，几乎所有的对象实例都在这里分配。当堆内存没有可用的空间时，会抛出 OOM 异常。根据对象存活的周期不同，JVM 把堆内存进行分代管理，由垃圾回收器来进行对象的回收管理。

• 方法区也是各个线程共享的内存区域，又叫非堆区。用于存放已被虚拟机加载的类相关信息，包括类信息、静态变量、常量、运行时常量池、字符串常量池。JDK 1.7 中的永久代和 JDK 1.8 中的 元空间(Metaspace )都是方法区的一种实现，并且元空间的存储位置是本地。

两个要点：一个是各部分的功能，另一个是哪些线程共享，哪些独占。

• 运行时常量池（Run-Time Constant Pool）。这是方法区的一部分。如果仔细分析过反编译的类文件结构，你能看到版本号、字段、方法、超类、接口等各种信息，还有一项信息就是常量池。Java 的常量池可以存放各种常量信息，不管是编译器生成的各种字面量，还是需要在运行时决定的符号引用，所以它比一般语言的符号表存储的信息更加宽泛。

接下来，我们来看看什么是 OOM 问题，它可能在哪些内存区域发生？
除了程序计数器，其它区域都有可能会因为可能的空间不足发生OutOfMemoryError，简单总结如下：

• 堆内存不足时最常见的 OOM 原因之一，抛出的错误信息是“java.lang.OutOfMemoryError:Java heap space"，原因可能千奇百怪，例如，可能存在内存泄漏问题；也有可能就是堆的大小不合理，比如我们要处理比较可观的数据量，但是没有显示指定 JVM 堆大小或者指定数值偏小；或者出现 JVM 处理引用不及时，导致堆积起来，内存无法释放等。
• 对于 Java 虚拟机栈和本地方法栈，如果我们写一段程序不断的进行递归调用，而且没有退出条件，就会导致不断的压栈。类似这种情况，JVM 实际会抛出 StackOverFlowError；如果 JVM 试图去扩展栈空间的的时候失败，则会抛出 OutOfMemoryError。

参考：

可能是把Java内存区域讲的最清楚的一篇文章

详解 JMM 内存可见性

JMM 是 Java 内存模型，与刚才讲到的 JVM 内存模型是两回事，JMM 的主要目标是定义程序中变量的访问规则，如下图所示，所有的共享变量都存储在主内存中共享。每个线程有自己的工作内存，工作内存中保存的是主内存中变量的副本，线程对变量的读写等操作必须在自己的工作内存中进行，而不能直接读写主内存中的变量。

在多线程进行数据交互时，例如线程 A 给一个共享变量赋值后，由线程 B 来读取这个值，A 修改完变量是修改在自己的工作区内存中，B 是不可见的，只有从 A 的工作区写回主内存，B 再从主内存读取自己的工作区才能进行进一步的操作。由于指令重排序的存在，这个写—读的顺序有可能被打乱。因此 JMM 需要提供原子性、可见性、有序性的保证。

详解 JMM 保证

如下图所示，来看 JMM 如何保证原子性、可见性，有序性。

原子性

JMM 保证对除 long 和 double 外的基础数据类型的读写操作是原子性的。另外关键字 synchronized 也可以提供原子性保证。synchronized 的原子性是通过 Java 的两个高级的字节码指令 monitorenter 和 monitorexit 来保证的。

可见性

JMM 可见性的保证，一个是通过 synchronized，另外一个就是 volatile。volatile 强制变量的赋值会同步刷新回主内存，强制变量的读取会从主内存重新加载，保证不同的线程总是能够看到该变量的最新值。

有序性

对有序性的保证，主要通过 volatile 和一系列 happens-before 原则。volatile 的另一个作用就是阻止指令重排序，这样就可以保证变量读写的有序性。

happens-before 原则包括一系列规则，如：

• 程序顺序原则，即一个线程内必须保证语义串行性；
• 锁规则，即对同一个锁的解锁一定发生在再次加锁之前；
• happens-before 原则的传递性、线程启动、中断、终止规则等。

详解类加载机制

类的加载指将编译好的 Class 类文件中的字节码读入内存中，将其放在方法区内并创建对应的 Class 对象。类的加载分为加载、链接、初始化，其中链接又包括验证、准备、解析三步。如下图所示。

1. 加载是文件到内存的过程。通过类的完全限定名查找此类字节码文件，并利用字节码文件创建一个 Class 对象。
2. 验证是对类文件内容验证。目的在于确保 Class 文件符合当前虚拟机要求，不会危害虚拟机自身安全。主要包括四种：文件格式验证，元数据验证，字节码验证，符号引用验证。
3. 准备阶段是进行内存分配。为类变量也就是类中由 static 修饰的变量分配内存，并且设置初始值。这里要注意，初始值是 0 或者 null，而不是代码中设置的具体值，代码中设置的值是在初始化阶段完成的。另外这里也不包含用 final 修饰的静态变量，因为 final 在编译的时候就会分配。
4. 解析主要是解析字段、接口、方法。主要是将常量池中的符号引用替换为直接引用的过程。直接引用就是直接指向目标的指针、相对偏移量等。
5. 初始化，主要完成静态块执行与静态变量的赋值。这是类加载最后阶段，若被加载类的父类没有初始化，则先对父类进行初始化。

只有对类主动使用时，才会进行初始化，初始化的触发条件包括在创建类的实例时、访问类的静态方法或者静态变量时、Class.forName() 反射类时、或者某个子类被初始化时。

如上图所示，浅绿的两个部分表示类的生命周期，就是从类的加载到类实例的创建与使用，再到类对象不再被使用时可以被 GC 卸载回收。这里要注意一点，由 Java 虚拟机自带的三种类加载器加载的类在虚拟机的整个生命周期中是不会被卸载的，只有用户自定义的类加载器所加载的类才可以被卸载。

详解类加载器

如上图所示，Java 自带的三种类加载器分别是：BootStrap 启动类加载器、扩展类加载器和应用加载器（也叫系统加载器）。图右边的桔黄色文字表示各类加载器对应的加载目录。启动类加载器加载 java home 中 lib 目录下的类，扩展加载器负责加载 ext 目录下的类，应用加载器加载 classpath 指定目录下的类。除此之外，可以自定义类加载器。

Java 的类加载使用双亲委派模式，即一个类加载器在加载类时，先把这个请求委托给自己的父类加载器去执行，如果父类加载器还存在父类加载器，就继续向上委托，直到顶层的启动类加载器，如上图中蓝色向上的箭头。如果父类加载器能够完成类加载，就成功返回，如果父类加载器无法完成加载，那么子加载器才会尝试自己去加载。如图中的桔黄色向下的箭头。

这种双亲委派模式的好处，可以避免类的重复加载，另外也避免了 Java 的核心 API 被篡改。

详解分代回收

Java 的堆内存被分代管理，为什么要分代管理呢？分代管理主要是为了方便垃圾回收，这样做基于2个事实，第一，大部分对象很快就不再使用；第二，还有一部分不会立即无用，但也不会持续很长时间。

虚拟机划分为年轻代、老年代、和永久代，如下图所示。

• 年轻代主要用来存放新创建的对象，年轻代分为 Eden 区和两个 Survivor 区。大部分对象在 Eden 区中生成。当 Eden 区满时，还存活的对象会在两个 Survivor 区交替保存，达到一定次数的对象会晋升到老年代。
• 老年代用来存放从年轻代晋升而来的，存活时间较长的对象。
• 永久代，主要保存类信息等内容，这里的永久代是指对象划分方式，不是专指 1.7 的 PermGen，或者 1.8 之后的 Metaspace。

根据年轻代与老年代的特点，JVM 提供了不同的垃圾回收算法。垃圾回收算法按类型可以分为引用计数法、复制法和标记清除法。

• 引用计数法是通过对象被引用的次数来确定对象是否被使用，缺点是无法解决循环引用的问题。
• 复制算法需要 from 和 to 两块相同大小的内存空间，对象分配时只在 from 块中进行，回收时把存活对象复制到 to 块中，并清空 from 块，然后交换两块的分工，即把 from 块作为 to 块，把 to 块作为 from 块。缺点是内存使用率较低。
• 标记清除算法分为标记对象和清除不在使用的对象两个阶段，标记清除算法的缺点是会产生内存碎片。

Java 内存回收算法

JVM 中提供的年轻代回收算法 Serial、ParNew、Parallel Scavenge 都是复制算法，而 CMS、G1、ZGC 都属于标记清除算法。

详解 CMS 算法

基于分代回收理论，详细介绍几个典型的垃圾回收算法，先来看 CMS 回收算法。CMS 在 JDK1.7 之前可以说是最主流的垃圾回收算法。CMS 使用标记清除算法，优点是并发收集，停顿小。

CMS 算法如下图所示。

1. 第一个阶段是初始标记，这个阶段会 stop the world，标记的对象只是从 root 集最直接可达的对象；

2. 第二个阶段是并发标记，这时 GC 线程和应用线程并发执行。主要是标记可达的对象；

3. 第三个阶段是重新标记阶段，这个阶段是第二个 stop the world 的阶段，停顿时间比并发标记要小很多，但比初始标记稍长，主要对对象进行重新扫描并标记；

4. 第四个阶段是并发清理阶段，进行并发的垃圾清理；

5. 最后一个阶段是并发重置阶段，为下一次 GC 重置相关数据结构。

详解 G1 算法

G1 在 1.9 版本后成为 JVM 的默认垃圾回收算法，G1 的特点是保持高回收率的同时，减少停顿。

G1 算法取消了堆中年轻代与老年代的物理划分，但它仍然属于分代收集器。G1 算法将堆划分为若干个区域，称作 Region，如下图中的小方格所示。一部分区域用作年轻代，一部分用作老年代，另外还有一种专门用来存储巨型对象的分区。

G1 也和 CMS 一样会遍历全部的对象，然后标记对象引用情况，在清除对象后会对区域进行复制移动整合碎片空间。

G1 回收过程如下。

1. G1 的年轻代回收，采用复制算法，并行进行收集，收集过程会 STW。
2. G1 的老年代回收时也同时会对年轻代进行回收。主要分为四个阶段：
   a. 依然是初始标记阶段完成对根对象的标记，这个过程是STW的；
   b. 并发标记阶段，这个阶段是和用户线程并行执行的；
   c. 最终标记阶段，完成三色标记周期；
   d. 复制/清除阶段，这个阶段会优先对可回收空间较大的 Region 进行回收，即 garbage first，这也是 G1 名称的由来。

G1 采用每次只清理一部分而不是全部的 Region 的增量式清理，由此来保证每次 GC 停顿时间不会过长。

总结如下，G1 是逻辑分代不是物理划分，需要知道回收的过程和停顿的阶段。此外还需要知道，G1 算法允许通过 JVM 参数设置 Region 的大小，范围是 1～32MB，可以设置期望的最大 GC 停顿时间等。有兴趣读者也可以对 CMS 和 G1 使用的三色标记算法做简单了解。

详解 ZGC

ZGC 特点

ZGC 是最新的 JDK1.11 版本中提供的高效垃圾回收算法，ZGC 针对大堆内存设计可以支持 TB 级别的堆，ZGC 非常高效，能够做到 10ms 以下的回收停顿时间。

这么快的响应，ZGC 是如何做到的呢？这是由于 ZGC 具有以下特点。

1. ZGC 使用了着色指针技术，我们知道 64 位平台上，一个指针的可用位是 64 位，ZGC 限制最大支持 4TB 的堆，这样寻址只需要使用 42 位，那么剩下 22 位就可以用来保存额外的信息，着色指针技术就是利用指针的额外信息位，在指针上对对象做着色标记。
2. 第二个特点是使用读屏障，ZGC 使用读屏障来解决 GC 线程和应用线程可能并发修改对象状态的问题，而不是简单粗暴的通过 STW 来进行全局的锁定。使用读屏障只会在单个对象的处理上有概率被减速。
3. 由于读屏障的作用，进行垃圾回收的大部分时候都是不需要 STW 的，因此 ZGC 的大部分时间都是并发处理，也就是 ZGC 的第三个特点。
4. 第四个特点是基于 Region，这与 G1 算法一样，不过虽然也分了 Region，但是并没有进行分代。ZGC 的 Region 不像 G1 那样是固定大小，而是动态地决定 Region 的大小，Region 可以动态创建和销毁。这样可以更好的对大对象进行分配管理。
5. 第五个特点是压缩整理。CMS 算法清理对象时原地回收，会存在内存碎片问题。ZGC 和 G1 一样，也会在回收后对 Region 中的对象进行移动合并，解决了碎片问题。

虽然 ZGC 的大部分时间是并发进行的，但是还会有短暂的停顿。来看一下 ZGC 的回收过程。

ZGC 回收过程

如下图所示，使用 ZGC 算法进行回收，从上往下看。初始状态时，整个堆空间被划分为大小不等的许多 Region，即图中绿色的方块。

开始进行回收时，ZGC 首先会进行一个短暂的 STW，来进行 roots 标记。这个步骤非常短，因为 roots 的总数通常比较小。

然后就开始进行并发标记，如上图所示，通过对对象指针进行着色来进行标记，结合读屏障解决单个对象的并发问题。其实，这个阶段在最后还是会有一个非常短的 STW 停顿，用来处理一些边缘情况，这个阶段绝大部分时间是并发进行的，所以没有明显标出这个停顿。

下一个是清理阶段，这个阶段会把标记为不在使用的对象进行回收，如上图所示，把橘色的不在使用的对象进行了回收。

最后一个阶段是重定位，重定位就是对 GC 后存活的对象进行移动，来释放大块的内存空间，解决碎片问题。

重定位最开始会有一个短暂的 STW，用来重定位集合中的 root 对象。暂停时间取决于 root 的数量、重定位集与对象的总活动集的比率。

最后是并发重定位，这个过程也是通过读屏障，与应用线程并发进行的。