学习笔记 一、深入理解Java虚拟机

前言

此文结合了《深入理解Java虚拟机》这本书以及CyC2018整理的资料，且标记了部分重点。

1.运行时数据区域

1.1. 程序计数器

程序计数器是一块较小的内存空间（线程私有），它可以看作是当前线程所执行的字节码的行号指示器。字节码解释器工作是就是通过改变这个计数器的值来选取下一条需要执行指令的字节码指令，分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖计数器完成。（Java虚拟机的多线程是通过线程轮流切换并分配处理器执行时间实现。）

注：如果线程正在执行的是一个Java方法，这个计数器记录的是正在执行的虚拟机字节码指令的地址：如果正在执行的是Native方法，这个计数器值则为空（Undefined）。此内存区域是唯一一个在Java虚拟机规范中没有规定任何OutOfMemoryError情况的区域。

1.2. Java虚拟机栈 ★

线程私有，生命周期与线程相同。描述的是 Java 方法执行的内存模型：每个方法在执行时都会床创建一个栈帧(Stack Frame)用于存储局部变量表、操作数栈、动态链接、方法出口等信息。每一个方法从调用直至执行结束，就对应着一个栈帧从虚拟机栈中入栈到出栈的过程。

注：局部变量表：存放了编译期可知的各种基本类型(boolean、byte、char、short、int、float、long、double)、对象引用(reference 类型)和 returnAddress 类型(指向了一条字节码指令的地址)。
两种异常情况：1、线程请求的栈深度大于虚拟机所允许的深度，将抛出StackOverflowError异常。
              2、虚拟机动态扩展，扩展时无法申请到足够的内存，就会抛出OutOfMemoryError异常。

1.3. 本地方法栈

区别于 Java 虚拟机栈的是，Java 虚拟机栈为虚拟机执行 Java 方法(也就是字节码)服务，而本地方法栈则为虚拟机使用到的 Native 方法服务。也会有 StackOverflowError 和 OutOfMemoryError 异常。

1.4. Java堆 ★

Java堆是被所有线程共享的一块内存区域（最大），在虚拟机启动时创建。唯一目的就是存放对象实例和数组。还可以细分为：新生代和老年代。再细分为Eden空间、From Survivor空间、To Survivor空间。内部会划分出多个线程私有的分配缓冲区(Thread Local Allocation Buffer, TLAB)。可以位于物理上不连续的空间，但是逻辑上要连续。

注：当前的虚拟机都是按照可扩展来实现的（通过-Xmx 和 -Xms控制）。如果在堆中没有内存完成实例分配，并且堆也无法再扩展时，将会抛出OutOfMemoryError异常。

1.5. 方法区 ★

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

注：此区域的内存回收目标主要是针对常量池的回收和对类型的卸载。

1.6. 运行时常量池

属于方法区一部分，用于存放编译期生成的各种字面量和符号引用。具备动态性，编译器和运行期(String 的 intern() )都可以将常量放入池中。内存有限，无法申请时抛出 OutOfMemoryError。

1.7. 直接内存

直接内存不是Java虚拟机规范中定义的内存区域，但是这部分内存也被频繁地使用，而且也可能导致OutOfMemoryError异常出现。在JDK1.4中新加入了NIO（New Input/Output）类，引入了一种基于通道（Channel）与缓冲区（Buffer）的I/O方式，它可以使用Native函数库直接分配堆外内存，然后通过一个存储在Java堆里面的DirectByteBuffer对象作为这块内存的引用 进行操作。这样能在一些场景中显著提高性能，因为避免了在Java堆和Native堆中来回复制数据。

---

2. 垃圾收集算法

2.1. 标记-清除算法

算法分为“标记”和“清除”两个阶段：首先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象。

缺点：
1、效率问题：标记和清除两个过程的效率都不高；
2、空间问题：标记清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致以后在程序运行过程中需要分配较大对象时，无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。
执行过程，如图所示：

2.2. 复制算法

（为了解决效率问题）复制算法将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另一块上面，然后再把已使用过的内存空间一次清理掉。

优点：实现简单，运行高效
缺点：将内存缩小为原来的一半，代价太高。

注：现在的商业虚拟机都采用这种收集算法来回收新生代，但是并不是将新生代划分为大小相等的两块，而是分为一块较大的 Eden 空间和两块较小的 Survivor 空间，每次使用 Eden 空间和其中一块 Survivor。在回收时，将 Eden 和 Survivor 中还存活着的对象一次性复制到另一块 Survivor 空间上，最后清理 Eden 和使用过的那一块 Survivor。

HotSpot 虚拟机的 Eden 和 Survivor 的大小比例默认为 8:1，保证了内存的利用率达到 90%。如果每次回收有多于 10% 的对象存活，那么一块 Survivor 空间就不够用了，此时需要依赖于老年代进行分配担保，也就是借用老年代的空间存储放不下的对象。

2.3. 标记-整理算法

该算法标记过程与“标记-清除”算法一样，但后续清理步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。

2.4. 分代收集算法 ★

现在的商业虚拟机采用分代收集算法，它根据对象存活周期将内存划分为几块，不同块采用适当的收集算法。
一般将堆分为新生代和老年代。

新生代使用：复制算法（每次垃圾收集时都发现有大批对象死去，只有少量存活，只需要付出少量存活对象的复制成本就可完成收集）
老年代使用：标记 - 清除 或者 标记 - 整理 算法（对象存活率高、没有额外空间对它进行分配担保）

---

3. 垃圾收集器

3.1. Serial 收集器

Serial 以串行的方式执行。

它是单线程的收集器，只会使用一个线程进行垃圾收集工作。它在进行垃圾收集时，必须暂停其他所有的工作线程，直到它收集结束。

它的优点是简单高效，对于单个 CPU 环境来说，由于没有线程交互的开销，因此拥有最高的单线程收集效率。

它是 Client 模式下的默认新生代收集器，因为在该应用场景下，分配给虚拟机管理的内存一般来说不会很大。Serial 收集器收集几十兆甚至一两百兆的新生代停顿时间可以控制在一百多毫秒以内，只要不是太频繁，这点停顿是可以接受的。

3.2. ParNew 收集器

它是 Serial 收集器的多线程版本。

是 Server 模式下的虚拟机首选新生代收集器，除了性能原因外，主要是因为除了 Serial 收集器，只有它能与 CMS 收集器配合工作。

默认开启的线程数量与 CPU 数量相同，可以使用 -XX:ParallelGCThreads 参数来设置线程数。

3.3. Parallel Scavenge 收集器

与 ParNew 一样是多线程收集器（复制算法）。

其它收集器关注点是尽可能缩短垃圾收集时用户线程的停顿时间，而它的目标是达到一个可控制的吞吐量，它被称为“吞吐量优先”收集器。这里的吞吐量指 CPU 用于运行用户代码的时间占总时间的比值。

即吞吐量=运行用户代码时间/（运行用户代码时间+垃圾收集时间）

停顿时间越短就越适合需要与用户交互的程序，良好的响应速度能提升用户体验。而高吞吐量则可以高效率地利用 CPU 时间，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务。

缩短停顿时间是以牺牲吞吐量和新生代空间来换取的：新生代空间变小，垃圾回收变得频繁，导致吞吐量下降。

可以通过一个开关参数打开 GC 自适应的调节策略（GC Ergonomics），就不需要手工指定新生代的大小（-Xmn）、Eden 和 Survivor 区的比例（默认8：1）、晋升老年代对象年龄等细节参数了。虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或者最大的吞吐量。

相关参数：
1、控制最大垃圾收集停顿时间的-XX：MaxGCPauseMills；
2、直接设置吞吐量大小的 -XX：GCTimeRatio；
3、开关参数 -XX：+UseAdaptiveSizePolicy。

3.4. Serial Old 收集器

是 Serial 收集器的老年代版本（单线程，标记-整理算法），也是给 Client 模式下的虚拟机使用。如果用在 Server 模式下，它有两大用途：
1、在 JDK 1.5 以及之前版本（Parallel Old 诞生以前）中与 Parallel Scavenge 收集器搭配使用。
2、作为 CMS 收集器的后备预案，在并发收集发生 Concurrent Mode Failure 时使用。

3.5. Parallel Old 收集器

是 Parallel Scavenge 收集器的老年代版本（多线程，标记-整理算法，jdk1.6开始提供）。

在注重吞吐量以及 CPU 资源敏感的场合，都可以优先考虑 Parallel Scavenge 加 Parallel Old 收集器。

3.6. CMS 收集器 ★★

CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。

应用于一些互联网站或者B/S系统的服务端上，这类应用尤其重视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验。

Mark Sweep，顾名思义，标记-清除算法。整个步骤分为以下四步：

• 初始标记：仅仅只是标记一下GC Roots能直接关联到的对象，速度很快，需要停顿。
• 并发标记：进行 GC Roots Tracing 的过程，它在整个回收过程中耗时最长，不需要停顿。
• 重新标记：为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，需要停顿且比初始标记稍长一些。（但停顿所花时间远小于并发标记的时间）
• 并发清除：不需要停顿。

在整个过程中耗时最长的并发标记和并发清除过程中，收集器线程都可以与用户线程一起工作，不需要进行停顿。

主要优点：

• 并发收集
• 低停顿