深入了解JVM

1、什么是JVM

定义：Java Virtual Machine - Java虚拟机（Java字节码的运行环境），其分为三大组成部分，包括：类加载器、内存结构以及执行引擎。

字节码：我们通常所说的Java字节码，是指Java语言编译成的字节码。准确的说任何能在jvm平台上执行的字节码格式都是一样的。所以应该统称为：jvm字节码。不同的编译器，可以编译出相同的字节码文件，字节码文件也可以在不同的jvm上运行。

Java虚拟机与Java语言并没有必然的联系，它只与特定的二进制文件格式：Class文件格式所关联，Class文件中包含了java虚拟机指令集和符号表,还有一些其他辅助信息。

JVM整体结构图：

2、JVM内存结构

内存是非常重要的系统资源，是硬盘和CPU的中间仓库及桥梁，承载着操作系统和应用程序的实时运行。JVM内存布局规定了Java在运行过程中内存申请、分配、管理的策略。保证了JVM的高效稳定运行。

Java虚拟机定义了若干种程序运行期间会使用到的运行时数据区，其中有一些会随着虚拟机启动而创建，随着虚拟机退出而销毁。另外一些则是与线程一一对应的，这些与线程对应的数据区域会随着线程开始和结束而创建和销毁。

  • 每个线程独立的结构包括：程序计数器、虚拟机栈、本地方法栈
  • 线程间共享的结构包括：堆、堆外内存(永久代或元空间、代码缓存)
  • 我们所谓的优化基本都是对堆和方法区的优化，因为栈结构不需要回收垃圾

2.1、程序计数器

程序计数器是对物理PC寄存器的一种抽象模拟，用来存储指向下一条指令的地址。也就是将要执行的指令代码。由执行引擎读取下一条指令。它是一块很小的内存空间。几乎可以忽略不计，也是运行速度最快的存储区域。

作用：因为CPU需要不停的切换各个线程、当从另一个线程切换回来以后，就得知道当前线程接着从哪开始继续执行，而程序计数器就记录了将要执行的指令的地址，方便CPU继续执行下去。

特点：

  • 是线程私有的
  • 生命周期与线程的生命周期保持一致
  • 内存中唯一一个不会出现内存溢出（OOM）的区域

2.2、虚拟机栈

栈是运行时的单位，而堆是存储的单位。栈解决程序的运行问题，即程序如何执行，或者说如何处理数据，堆解决的是数据存储的问题，即数据怎么放、放在哪里。

栈的内部详细结构：

  • 设置栈的大小可以使用-Xss size来设置。
  • 每个栈由多个栈帧（Frame）组成，对应着每次方法调用所占内存。
  • 每个线程只能有一个活动栈帧，对应着当前正在执行的方法，称为当前栈帧，执行引擎运行的所有字节码指令只针对当前栈帧进行操作。
  • 栈帧内部结构包括：局部变量表、操作数栈、动态链接、方法返回地址以及一些附加信息。

栈的大小并不是越大越好，因为物理机的内存是一定的，当设置的栈的空间越大，虚拟机的线程数反而会越少。此时反而会影响程序的运行效率。

特点：

  • 栈是一种快速有效的分配存储方式，访问速度仅次于程序计数器。
  • JVM直接对Java栈的操作只有两个：
    • 每个方法执行，伴随着一个栈帧入栈
    • 执行结束后的栈帧出栈
  • 对于栈来说不存在垃圾回收问题，但是栈存在溢出问题。

局部变量的线程安全问题：因为栈是线程私有的，每个线程都拥有一个私有的栈，线程中每次方法调用都会产生一个新的栈帧，因此，方法内的局部变量不会存在线程安全问题。但是，当一个局部变量逃离了当前方法的作用范围，比如return了出去，那么就有可能出现线程安全问题。

2.2.1、局部变量表

  • 局部变量表也被称之为局部变量数组或本地变量表
  • 定义为一个数字数组，主要用于存储方法参数和定义在方法体内的局部变量，这些数据类型包括各类基本数据类型、对象引用（reference），以及returnAddress类型。
  • 由于局部变量表是建立在线程的栈上，是线程的私有数据，因此不存在数据安全问题
  • 局部变量表所需的容量大小是在编译期确定下来的，在方法运行期间是不会改变局部变量表的大小的。
  • 方法嵌套调用的次数由栈的大小决定。一般来说，栈越大，方法嵌套调用次数越多。对一个函数而言，它的参数和局部变量越多，使得局部变量表膨胀，它的栈帧就越大，以满足方法调用所需传递的信息增大的需求。进而函数调用就会占用更多的栈空间，导致其嵌套调用次数就会减少。
  • 局部变量表中的变量只在当前方法调用中有效。在方法执行时，虚拟机通过使用局部变量表完成参数值到参数变量列表的传递过程。当方法调用结束后，随着方法栈帧的销毁，局部变量表也会随之销毁。

2.2.2、操作数栈

  • 操作数栈，主要用于保存计算过程的中间结果，同时作为计算过程中变量临时的存储空间。
  • 在方法执行过程中，根据字节码指令，往操作数栈中写入数据或提取数据，即入栈（push）和 出栈（pop）
    • 某些字节码指令将值压入操作数栈，其余的字节码指令将操作数取出栈。使用它们后再把结果压入栈
    • 比如：执行复制、交换、求和等操作
  • 如果被调用的方法带有返回值的话，其返回值将会被压入当前栈帧的操作数栈中，并更新PC寄存器中下一条需要执行的字节码指令。
  • 我们说Java虚拟机的解释引擎是基于栈的执行引擎，其中的栈指的就是操作数栈。

栈顶缓存技术：由于操作数是存储在内存中的，因此频繁地执行内存读/写操作必然会影响执行速度。为了解决这个问题，HotSpot JVM的设计者们提出了栈顶缓存技术，将栈顶元素全部缓存在物理CPU的寄存器中，以此降低对内存的读/写次数，提升执行引擎的执行效率。

2.2.3、动态链接

  • 每一个栈帧内部都包含一个指向运行时常量池中该栈帧所属方法的引用。包含这个引用的目的就是为了支持当前方法的代码能够实现动态链接（Dynamic Linking）。
  • 在Java源文件被编译到字节码文件中时，所有的变量和方法引用都作为符号引用（Symbolic Reference）保存在class文件的常量池里。比如：描述一个方法调用了另外的其他方法时，就是通过常量池中指向方法的符号引用来表示的，那么动态链接的作用就是为了将这些符号引用转换为调用方法的直接引用。

一些词的理解：

  1. 动态链接和静态链接：
    • 静态链接和动态链接不是名词，而是动词。
    • 当一个字节码文件被装载进JVM内部时，如果被调用的目标方法在编译期可知，且运行期保持不变时，这种情况下降调用方法的符号引用转换为直接引用的过程称之为静态链接。
    • 如果被调用的方法在编译期无法被确定下来，只能够在程序运行期将调用的方法的符号转换为直接引用，由于这种引用转换过程具备动态性，因此也被称之为动态链接。
  2. 早期绑定和晚期绑定：
    • 动态链接和静态链接所对应的方法的绑定机制为：早期绑定（Early Binding）和晚期绑定（Late Binding）。绑定是一个字段、方法或者类在符号引用被替换为直接引用的过程，这仅仅发生一次。
    • 早期绑定就是指被调用的目标方法如果在编译期可知，且运行期保持不变时，即可将这个方法与所属的类型进行绑定，这样一来，由于明确了被调用的目标方法究竟是哪一个，因此也就可以使用静态链接的方式将符号引用转换为直接引用。
    • 如果被调用的方法在编译期无法被确定下来，只能够在程序运行期根据实际的类型绑定相关的方法，这种绑定方式也就被称之为晚期绑定。
  3. 虚方法和非虚方法：
    • 如果方法在编译期就确定了具体的调用版本，这个版本在运行时是不可变的。这样的方法称为非虚方法。静态方法、私有方法、final方法、实例构造器、父类方法都是非虚方法。其他方法称为虚方法。
  4. 动态类型语言和静态类型语言：
    • 动态类型语言和静态类型语言两者的区别就在于对类型的检查是在编译期还是在运行期，满足前者就是静态类型语言，反之是动态类型语言。
    • 说的再直白一点就是，静态类型语言是判断变量自身的类型信息；动态类型语言是判断变量值的类型信息，变量没有类型信息，变量值才有类型信息，这是动态语言的一个重要特征。
    • Java是静态类型语言(尽管lambda表达式为其增加了动态特性)，js、python是动态类型语言

2.2.4、方法返回地址

  • 存放调用该方法的pc寄存器的值。一个方法的结束，有两种方式：
    • 正常执行完成
    • 出现未处理的异常，非正常退出
  • 无论通过哪种方式退出，在方法退出后都返回到该方法被调用的位置。方法正常退出时，调用者的pc计数器的值作为返回地址，即调用该方法的指令的下一条指令的地址。而通过异常退出的，返回地址是要通过异常表来确定，栈帧中一般不会保存这部分信息。
  • 本质上，方法的退出就是当前栈帧出栈的过程。此时，需要恢复上层方法的局部变量表，操作数栈，将返回值压入调用者栈帧的操作数栈，设置PC寄存器值等，让调用方法继续执行下去。
  • 正常完成出口和异常完成出口的区别在于：通过异常完成出口退出的不会给他的上层调用者产生任何的返回值。

2.3、本地方法栈

Java虚拟机用于管理Java方法的调用、而本地方法栈用于管理本地方法的调用。

  • 本地方法栈也是线程私有的。
  • 允许被实现成固定或者是可动态拓展的内存大小。
  • 本地方法是使用C语言实现的。
  • 当某个线程调用一个本地方式，它就进入了一个全新的并且不在受虚拟机限制的世界。它和虚拟机拥有同样的权限。

并不是所有的JVM都支持本地方法，因为Java虚拟机规范并没有明确要求本地方法栈的使用语言、具体实现方式、数据结构等。如果JVM产品不打算支持native方法、也可以无需实现本地方法栈。

2.4、堆

通过new关键字，创建对象都会使用堆内存。堆针对一个JVM进程来说是唯一的，也就是一个进程只有一个堆空间，但是进程包含多个线程，他们是共享同一堆空间的。

特点：

  • 它是线程共享的，堆中的对象都需要考虑线程安全问题。
  • 有垃圾回收机制，也是垃圾回收的重点区域。
  • 堆可以处于物理上不连续的内存空间中，但在逻辑上它应该被视为连续的。
  • Java堆区在JVM启动的时候就被创建了，其空间大小也就被确定了（堆是jvm管理的最大的内存空间）java堆的大小是可以调节的。
  • 用-Xms 设置堆空间的最小空间，用-Xmxs设置堆的最大空间。默认情况下初始化大小是电脑内存空间的64分之1。最大空间为电脑内存空间的4分之1。为了不让其频繁改变大小，可以将两个值设为相等。

堆内存图示：

为什么还要分年轻代和老年代：

  • 存储在JVM中的Java对象可以被划分为两类，一类是生命周期较短的瞬时对象，这类对象的创建和消亡都非常迅速。另外一类对象的声明周期却非常长，在某些极端的情况下还能够与jvm的声明周期保持一致。
  • Java堆区进一步细分的话，可以划分为年轻代（YoungGen）和老年代（OldGen）其中年轻代又可以划分为Eden空间（伊甸园区）Survivor0空间和Survivor1空间（幸存者0/1区有时候也叫做from区、to区）
  • 几乎所有Java对象都是在eden区被new出来的。（对象比eden区还要大，就要在老年区new出来）绝大部分java对象的销毁都在新生代。（IBM的研究表明新生代中有90%以上的对象都是朝生夕死的）

对象分配过程：

  1. new的对象存放在伊甸园区（大对象伊甸园区存不下，直接放老年代）

  2. 伊甸园区被填满时，程序再次创建对象时。jvm垃圾回收器将对伊甸园区进行垃圾回收（叫做YGC或者Minor GC）将伊甸园区中的不再被引用的对象销毁。

  3. 将伊甸园区剩余对象移动到幸存者0区

  4. 再次触发垃圾回收时，将伊甸园区和幸存者0区中不被引用的对象销毁。将剩余对象移放到幸存者1区。

  5. 再次触发垃圾回收时操作相同，但是要将剩余对象放入幸存者0区。

  6. 每次移动进入幸存者区都要增加年龄（默认15次时放入老年区即第16次）可以通过-XX:MaxTenuringThreshold=10修改，此时为10

    注意：如果survivor区中相同年龄的所有对象大小的总和大于survivor空间的一半，年龄大于或等于该年龄的对象可以直接进入老年代，无需等到Max。

  7. 在养老区内存不足时，再次出发GC(Major GC)

  8. 若养老区执行了Major Gc之后发现依然无法进行对象的保存，就会发生OOM。

Minor GC、Major GC、Full GC的说明：

  • 整堆收集（Full GC）：
    • 收集整个java堆和方法区的垃圾收集。
  • 年轻代GC（Minor GC）：
    • 当年轻代（Eden区）空间不足时，就会触发Minor GC。会清理这个年轻代的内存空间。
    • 因为大部分对象生命周期都比较短，因此Minor GC发生的非常频繁，一般回收速度也比较快。
    • Minor GC会触发STW（Stop The World）暂停其他用户线程，等垃圾回收结束，用户线程才恢复运行。
  • 老年代GC（Major GC/Full GC）：
    • 出现Major GC经常伴随至少一次的Minor GC，也就是在老年代空间不足时会先尝试触发Minor GC。如果之后空间还不足，则触发Major GC。
    • Major GC速度一般比Minor GC慢10倍以上 STW的时间更长。
    • 如果Magor GC后，内存还不足就OOM
    • 触发Full GC的情况：
      1. 调用System.gc()时，系统建议执行Ful GC但是不必然执行。
      2. 老年代空间不足或方法区空间不足。
      3. 通过Minor GC后进入老年代的对象大小大于老年代的可用内存。
      4. 由Eden区survivor space0（From Space）区向survivor space1（To Space）区复制时，对象大小大于To Space可用内存，则把该对象转到老年代，且老年代的可用内存小于该对象大小。
      5. 说明：Full GC是开发或调优中尽量要避免的。这样暂停时间会短一些。可以通过-XX:+PrintGCDetails参数查看GC信息。

2.5、方法区

方法区可以看作是独立于Java堆的一部分，并且也是和堆一样是整个JVM实例共用一份。主要存放的是Class，而堆中主要存放的是实例化的对象。

  • 方法区与java堆一样，是各个线程共享的内存区域。
  • 方法区在jvm启动的时候创建，并且他的实际的物理内存空间中与java堆区一样都可以是不连续的。
  • 方法区的大小跟堆空间一样，可以选择固定大小或者可扩展。
  • 方法区的大小决定了系统可以保存多少个类，如果系统定义了太多的类，导致方法区溢出，虚拟机同样会抛出OutOfMemoryError

HotSpot中方法区的演进：

  • 在jdk7及以前，习惯上把方法区，称为永久代。jdk8开始，使用元空间取代了永久代。
  • 元空间的本质和永久代类似，都是对JVM规范中方法区的实现。不过元空间与永久代最大的区别在于：元空间不在虚拟机设置的内存中，而是使用本地内存。

因此方法区、元空间、永久代三者的区别在于：

  • 方法区：是JVM的一个规范，所有虚拟机必须要遵守的。方法区逻辑上属于堆的一部分，但是为了与堆区分，通常又叫非堆区。
  • 永久代：是JDK7及之前， HotSpot虚拟机基于JVM规范对方法区的一个落地实现。在JDK8被移除。
  • 元空间：元空间则是JDK1.8及之后，HotSpot虚拟机对方法区的新实现。元空间与永久代之间最大的区别在于元空间并不在虚拟机中，而是使用本地内存。

内部结构：

《深入理解Java虚拟机》书中对方法区（Method Area）存储内容描述如下：它用于存储已被虚拟机加载的类型信息、常量、静态变量、即时编译器编译后的代码缓存等。

类型信息：对每个加载的类型（类class、接口interface、枚举enum、注解annotation），JVM必须在方法区中存储以下类型信息：

  1. 这个类型的完整有效名称（全名=包名.类名）
  2. 这个类型直接父类的完整有效名（对于interface或是java.lang.object，都没有父类）
  3. 这个类型的修饰符（public，abstract，final的某个子集）
  4. 这个类型直接接口的一个有序列表

域信息：JVM必须在方法区中保存类型的所有域的相关信息以及域的声明顺序。

域的相关信息包括：域名称、域类型、域修饰符（public，private，protected，static，final，volatile，transient的某个子集）。

方法信息：JVM必须保存所有方法的以下信息，同域信息一样包括声明顺序：

  1. 方法名称
  2. 方法的返回类型（或void）
  3. 方法参数的数量和类型（按顺序）
  4. 方法的修饰符（public，private，protected，static，final，synchronized，native，abstract的一个子集）
  5. 方法的字节码、操作数栈、局部变量表及大小（abstract和native方法除外）
  6. 异常表（abstract和native方法除外）：即每个异常处理的开始位置、结束位置、代码处理在程序计数器中的偏移地址、被捕获的异常类的常量池索引。

non-final的类变量：静态变量和类关联在一起，随着类的加载而加载，他们成为类数据在逻辑上的一部分。类变量被类的所有实例共享，即使没有类实例时，你也可以访问它。

全局常量：全局常量就是使用 static final 进行修饰。被声明为final的类变量的处理方法则不同，每个全局常量在编译的时候就会被分配了。

运行时常量池：

  • 要理解运行时常量池首先要知道常量池，一个有效的字节码文件中除了包含类的版本信息、字段、方法以及接口等描述符信息外，还包含一项信息就是常量池表（Constant Pool Table），包括各种字面量和对类型、域和方法的符号引用。虚拟机指令根据这张常量表找到要执行的类名、方法名、参数类型、字面量等类型。
  • 运行时常量池（Runtime Constant Pool）是方法区的一部分。
  • 常量池表（Constant Pool Table）是Class文件的一部分，用于存放编译期生成的各种字面量与符号引用，这部分内容将在类加载后存放到方法区的运行时常量池中。
  • 运行时常量池，在加载类和接口到虚拟机后，就会创建对应的运行时常量池。
  • JVM为每个已加载的类型（类或接口）都维护一个常量池。池中的数据项像数组项一样，是通过索引访问的。
  • 运行时常量池中包含多种不同的常量，包括编译期就已经明确的数值字面量，也包括到运行期解析后才能够获得的方法或者字段引用。此时不再是常量池中的符号地址了，这里换为真实地址。

方法区详细演进：

总结：

3、执行引擎

JVM的主要任务是负责装载字节码到其内部，但字节码并不能够直接运行在操作系统之上，因为字节码指令并非等价于本地机器指令，它内部包含的仅仅只是一些能够被JVM所识别的字节码指令、符号表，以及其他辅助信息。

那么，如果想要让一个Java程序运行起来，执行引擎(Execution Engine)的任务就是将字节码指令解释/编译为对应平台上的本地机器指令才可以。简单来说，JVM中的执行引擎充当了将高级语言翻译为机器语言的译者。

  • 执行引擎在执行的过程中究竟需要执行什么样的字节码指令完全依赖于PC寄存器。
  • 每当执行完一项指令操作后，PC寄存器就会更新下一条需要被执行的指令地址。
  • 当然方法在执行的过程中，执行引擎有可能会通过存储在局部变量表中的对象引用准确定位到存储在Java堆区中的对象实例信息，以及通过对象头中的元数据指针定位到目标对象的类型信息。

Java代码编译和执行过程：

在执行Java代码的时候，通常会将解释执行和编译执行二者结合起来进行，这也解释了Java为什么会被称为半编译半解释型语言。

  • 解释器：当Java虚拟机启动时会根据预定义的规范对字节码采用逐行解释的方式执行，将每条字节码文件中的内容“翻译”为对应平台的本地机器指令执行。
  • JIT (Just In Time Compiler)编译器：就是虚拟机将源代码直接编译成和本地机器平台相关的机器语言。JIT编译器将热点代码翻译成机器指令缓存在方法区中。这样之后执行的时候效率将大大提高

热点代码：什么时候用解释器，什么时候用JIT编译器需要根据代码被执行的频率而定。被JIT编译成机器码的代码叫做热点代码。JIT在运行时会针对那些频繁被调用的热点代码做出深度优化，将其直接编译为对应平台的本地机器指令，以此提升Java程序的执行性能。
一个被多次调用的方法，或者是一个方法体内部循环次数较多的循环体都可以被称之为热点代码。因此都可以通过JIT编译器编译为本地机器指令。由于这种编译方式发生在方法的执行过程中，因此也被称之为栈上替换。

那么既然有JIT编译器了，为什么还要存在解释器来”拖累“程序的执行性能呢？

  • 当虚拟机启动的时候，解释器可以首先发挥作用，而不必等待即时编译器全部编译完成再执行，这样可以省去许多不必要的编译时间。并且随着程序运行时间的推移，即时编译器逐渐发挥作用，根据热点探测功能，将有价值的字节码编译为本地机器指令，以换取更高的程序执行效率。

4、垃圾收集算法

什么是垃圾：

运行程序中没有任何指针指向的对象就是垃圾。如果不进行垃圾回收，内存迟早都会被消耗完，就会导致内存溢出。

除了释放没用的对象，垃圾回收也可以清除内存里的内存碎片。碎片整理将所占用的堆内存移到堆的一端，以便JVM将整理出的内存分配给新的对象。

随着应用程序所应付的业务越来越庞大，没有GC就不能保证应用程序的正常进行。而经常造成STW（Stop The World）的GC又跟不上实际的需求，所以需要不断地对GC进行优化。

自动内存管理：

无需开发人员手动参与内存的分配与回收，这样降低内存泄露和内存溢出的风险。自动内存管理机制，将程序员从繁重的内存管理中释放出来，可以更专心地专注于业务开发。

但是如果过度地依赖自动内存管理，可能会弱化Java开发人员在程序出现内存溢出时定位问题和解决问题的能力。

当需要排查内存溢出、内存泄漏问题时，或者垃圾收集称为系统达到更高并发量的瓶颈时，我们就必须对这些”自动化”技术实施必要的监控和调节。

Java堆是垃圾收集器的工作重点。从次数上讲，频繁收集年轻代较少收集老年代，基本不动方法区（永久代/元空间）

4.1、标记阶段

在堆里存放着几乎所有的Java对象实例，在GC执行垃圾回收之前，首先需要区分出内存中哪些是存活对象，哪些是已经死亡的对象。只有被标记为己经死亡的对象，GC才会在执行垃圾回收时，释放掉其所占用的内存空间，因此这个过程我们可以称为垃圾标记阶段。

那么在JVM中究竟是如何标记一个死亡对象呢? 简单来说，当一个对象已经不再被任何的存活对象继续引用时，就可以宣判为已经死亡。

判断对象存活一般有两种方式：**引用计数算法 **和 可达性分析算法。

4.1.1、引用计数算法

对每个对象保存一个整型的引用计数器属性。用于记录对象被引用的情况。

对于一个对象A，只要有任何一个对象引用了A，则A的引用计数器就加1；当引用失效时，引用计数器就减1。只要对象A的引用计数器的值为0，即表示对象A不可能再被使用，可进行回收。

优点：实现简单，垃圾对象便于辨识。判定效率高，回收没有延迟性。（发现引用次数为0后直接删除，而不用等待一起GC）
缺点:

  • 它需要单独的字段存储计数器，会增加存储空间开销。
  • 每次复制都需要更新计数器，伴随着加法和减法操作，这增加了时间开销。
  • 引用计数器有一个严重的问题，即无法处理循环引用的情况，这是致命缺陷。因此Java的垃圾回收器中没有使用这类算法。

4.1.2、可达性分析算法

相对于引用计数算法而言，可达性分析算法不仅同样具备实现简单和执行高效等特点，更重要的是该算法可以有效地解决在引用计数算法中循环引用的问题，防止内存泄漏的发生。

相较于引用计数算法，这里的可达性分析就是Java、C#选择的。这种类型的垃圾收集通常也叫作追踪性垃圾收集。

基本思路:

  • 可达性分析算法是以根对象集合(GC Roots)为起始点，按照从上至下的方式搜索被根对象集合所连接的目标对象是否可达。
  • 使用可达性分析算法后，内存中的存活对象都会被根对象集合直接或间接连接着，搜索所走过的路径称为引用链(Reference Chain)
  • 如果目标对象没有任何引用链相连，则是不可达的，就意味着该对象己经死亡，可以标记为垃圾对象。
  • 在可达性分析算法中，只有能够被根对象集合直接或者间接连接的对象才是存活对象。

所谓”GC Roots”根集合就是一组必须活跃的引用。在Java语言中，GC Roots 包括以下几类元素：

  • 虚拟机栈中引用的对象
    • 比如：各个线程被调用的方法中使用到的参数、局部变量等。
  • 本地方法栈内JNI（通常说的本地方法）引用的对象
  • 方法区中类静态属性引用的对象
    • 比如：Java类的引用类型静态变量
  • 方法区中常量引用的对象
    • 比如：字符串常量池(string Table）里的引用
  • 所有被同步锁synchronized持有的对象
  • Java虚拟机内部的引用。
    • 基本数据类型对应的class对象，一些常驻的异常对象（如:NullPointerException、OutOfMemoryError)，系统类加载器。
  • 反映iava虚拟机内部情况的JMXBean、JVMTI中注册的回调、本地代码缓存等。

判断Root小技巧：由于Root采用栈方式存放变量和指针，所以如果一个指针，它保存了堆内存里面的对象，但是自己又不存放在堆内存里面，那它就是一个Root。

如果要使用可达性分析算法来判断内存是否可回收，那么分析工作必须在一个能保障一致性的快照中进行。这点不满足的话分析结果的准确性就无法保证。

这点也是导致GC进行时必须”stop The world”的一个重要原因。即使是号称（几乎）不会发生停顿的CMS 收集器中，枚举根节点时
也是必须要停顿的。

对象终止（ finalization）机制：

java语言提供了对象终止（finalize方法）机制来允许开发人员提供对象被销毁之前的自定义处理逻辑。

当垃圾回收器发现没有引用指向一个对象，即：垃圾回收此对象之前，总会先调用这个对象的finalize()方法。

finalize()方法允许在子类中被重写，用于在对象被回收时进行资源释放。通常在这个方法中进行一些资源释放和清理的工作，比如关闭文件、套接字和数据库连接等。

永远不要主动调用某个对象的finalize()方法，应该交给垃圾回收机制调用。理由包括下面三点：

  1. 在finalize()时可能会导致对象复活。
  2. finalize()方法的执行时间是没有保障的，它完全由GC线程决定，极端情况下，若不发生GC，则finalize()方法将没有执行机会。
  3. 一个糟糕的finalize()会严重影响GC的性能。

由于finalize()方法的存在，虚拟机中的对象一般处于三种可能的状态：

  1. 可触及的：存在到达该对象的引用链
  2. 可复活的：对象的所有引用都被释放，但是对象有可能在finalize()中复活
  3. 不可触及的：finalize()被调用，并且没有复活，就会进入不可触及状态。不可触及的对象不可能被复活，因为finalize()只会被调用一次。只有对象在不可触及时才真正要被回收。

判断一个对象objA是否可回收，至少要经历两次标记的过程：

  1. 如果对象objA到 GC Roots没有引用链，则进行第一次标记。
  2. 进行筛选，判断此对象是否有必要执行finalize()方法
    • 如果对象objA没有重写finalize()方法，或者finalize()方法已经被虚拟机调用过，则虚拟机视为“没有必要执行”，objA被判定为不可触及的。
    • 如果对象objA重写了finalize()方法，且还未执行过，那么objA会被插入到F-Queue队列中，由一个虚拟机自动创建的、低优先级的Finalizer线程触发其finalize()方法执行。
    • finalize()方法是对象逃脱死亡的最后机会，稍后GC会对F-Queue队列中的对象进行第二次标记。如果objA在finalize()方法中与引用链上的任何一个对象建立了联系，那么在第二次标记时，objA会被移出“即将回收”集合。之后，对象会再次出现没有引用存在的情况。在这个情况下，finalize方法不会被再次调用，对象会直接变成不可触及的状态，也就是说，一个对象的finalize方法只会被调用一次。

4.2、清除阶段

当成功区分出内存中存活对象和死亡对象后，GC接下来的任务就是执行垃圾回收，释放掉无用对象所占用的内存空间，以便有足够的可用内存空间为新对象分配内存。

目前在JVM中比较常见的三种垃圾收集算法是：标记-清除算法（Mark-Sweep）、复制算法（copying)、标记–压缩算法（Mark-compact) 。

4.2.1、标记-清除算法

执行过程：

当堆中的有效内存空间(available memory)被耗尽的时候，就会停止整个程序（也被称为stop the world），然后进行两项工作，第一项则是标记，第二项则是清除。

  • 标记：collector从引用根节点开始遍历，标记所有被引用的对象。一般是在对象的Header中记录为可达对象。
  • 清除：collector对堆内存从头到尾进行线性的遍历，如果发现某个对象在其Header中没有标记为可达对象，则将其回收。

缺点：

  • 效率不算高。
  • 在进行GC的时候，需要停止整个应用程序，导致用户体验差。
  • 这种方式清理出来的空闲内存是不连续的，产生内存碎片。需要维护一个空闲列表。

注意：何为清除？

这里所谓的清除并不是真的置空，而是把需要清除的对象地址保存在空闲的地址列表里。下次有新对象需要加载时，判断垃圾的位置空间是否够，如果够，就存放。

4.2.2、复制算法

核心思想：

将活着的内存空间分为两块，每次只使用其中一块，在垃圾回收时将正在使用的内存中的存活对象复制到未被使用的内存块中，之后清除正在使用的内存块中的所有对象，交换两个内存的角色，最后完成垃圾回收。

优点：

  • 没有标记和清除过程，实现简单，运行高效
  • 复制过去以后保证空间的连续性，不会出现“碎片”问题。

缺点：

  • 此算法的缺点也是很明显的，就是需要两倍的内存空间。
  • 对于G1这种分拆成为大量region的GC，复制而不是移动，意味着GC需要维护region之间对象引用关系，不管是内存占用或者时间开销也不小。

特别的：如果系统中的垃圾对象很多，复制算法需要复制的存活对象数量并不会太大，或者说非常低才行。

4.2.3、标记-压缩算法

背景：

  • 复制算法的高效性是建立在存活对象少、垃圾对象多的前提下的。这种情况在新生代经常发生，但是在老年代，更常见的情况是大部分对象都是存活对象。如果依然使用复制算法由于存活对象较多，复制的成本也将很高。因此，基于老年代垃圾回收的特性，需要使用其他的算法。
  • 标记-清除算法的确可以应用在老年代中，但是该算法不仅执行效率低下，而且在执行完内存回收后还会产生内存碎片，所以JVM的设计者需要在此基础之上进行改进。标记–压缩（Mark - compact）算法由此诞生。

执行过程：

  • 第一阶段和标记清除算法一样，从根节点开始标记所有被引用对象
  • 第二阶段将所有的存活对象压缩到内存的一端，按顺序排放。
  • 之后，清理边界外所有的空间。

标记-压缩算法的最终效果等同于标记-清除算法执行完成后，再进行一次内存碎片整理，因此，也可以把它称为标记-清除-压缩(Mark-Sweep-Compact)算法。

二者的本质差异在于标记-清除算法是一种非移动式的回收算法，标记-压缩是移动式的。是否移动回收后的存活对象是一项优缺点并存的风险决策。

可以看到，标记的存活对象将会被整理，按照内存地址依次排列，而未被标记的内存会被清理掉。如此一来，当我们需要给新对象分配内存时，JVM只需要持有一个内存的起始地址即可，这比维护一个空闲列表显然少了许多开销。

优点：

  • 消除了标记-清除算法当中，内存区域分散的缺点，我们需要给新对象分配内存时，JVM只需要持有一个内存的起始地址即可。
  • 消除了复制算法当中，内存减半的高额代价。

缺点：

  • 从效率上来说，标记-整理算法要低于复制算法。
  • 移动对象的同时，如果对象被其他对象引用，则还需要调整引用的地址。
  • 移动过程中，需要全程暂停用户应用程序。即：STW

三种算法对比：

标记-清除算法 标记-压缩算法 复制算法
速度 中等 最慢 最快
空间开销 少（但会堆积碎片） 少（不堆积碎片） 通常需要活对象的2倍大小（不堆积碎片）
移动对象 否 是 是

4.2.4、分代收集算法

前面所有这些算法中，并没有一种算法可以完全替代其他算法，它们都具有自己独特的优势和特点。分代收集算法应运而生。

分代收集算法，是基于这样一个事实：不同的对象的生命周期是不一样的。因此，不同生命周期的对象可以采取不同的收集方式，以便提高回收效率。一般是把Java堆分为新生代和老年代，这样就可以根据各个年代的特点使用不同的回收算法，以提高垃圾回收的效率。

目前几乎所有的GC都是采用分代收集算法执行垃圾回收的。

在HotSpot中，基于分代的概念，GC所使用的内存回收算法必须结合年轻代和老年代各自的特点。

年轻代特点：区域相对老年代较小，对象生命周期短、存活率低，回收频繁。

这种情况复制算法的回收整理，速度是最快的。复制算法的效率只和当前存活对象大小有关，因此很适用于年轻代的回收。而复制算法内存利用率不高的问题，通过hotspot中的两个survivor的设计得到缓解。

老年代特点：区域较大，对象生命周期长、存活率高，回收不及年轻代频繁。

这种情况存在大量存活率高的对象，复制算法明显变得不合适。一般是由标记-清除或者是标记-清除与标记-整理的混合实现。

标记阶段的开销与存活对象的数量成正比。清除阶段的开销与所管理区域的大小成正相关。整理阶段的开销与存活对象的数据成正比。

4.2.5、增量收集算法

上述现有的算法，在垃圾回收过程中，应用软件将处于一种stop the world的状态。在stop the World 状态下，应用程序所有的线程都会挂起，暂停一切正常的工作，等待垃圾回收的完成。如果垃圾回收时间过长，应用程序会被挂起很久，将严重影响用户体验或者系统的稳定性。为了解决这个问题，即对实时垃圾收集算法的研究直接导致了增量收集算法的诞生。

基本思想：

  • 如果一次性将所有的垃圾进行处理，需要造成系统长时间的停顿，那么就可以让垃圾收集线程和应用程序线程交替执行。每次，垃圾收集线程只收集一小片区域的内存空间，接着切换到应用程序线程。依次反复，直到垃圾收集完成。
  • 总的来说，增量收集算法的基础仍是传统的标记-清除和复制算法。增量收集算法通过对线程间冲突的妥善处理，允许垃圾收集线程以分阶段的方式完成标记、清理或复制工作。

缺点：

  • 使用这种方式，由于在垃圾回收过程中，间断性地还执行了应用程序代码，所以能减少系统的停顿时间。但是，因为线程切换和上下文转换的消耗，会使得垃圾回收的总体成本上升，造成系统吞吐量的下降。

4.2.6、分区算法

一般来说，在相同条件下，堆空间越大，一次GC时所需要的时间就越长，有关GC产生的停顿也越长。为了更好地控制GC产生的停顿时间，将一块大的内存区域分割成多个小块，根据目标的停顿时间，每次合理地回收若干个小区间，而不是整个堆空间，从而减少一次GC所产生的停顿。

分代算法将按照对象的生命周期长短划分成两个部分，分区算法将整个堆空间划分成连续的不同小区间。

每一个小区间都独立使用，独立回收。这种算法的好处是可以控制一次回收多少个小区间。

注意：这些只是基本的算法思路，实际GC实现过程要复杂的多，目前还在发展中的前沿GC都是混合算法，并且并行和并发兼备。

5、垃圾回收器

5.1、垃圾回收器的分类

1、如果按照线程数分，可以分为串行垃圾回收器和并行垃圾回收器。

串行回收指的是在同一时间段内只允许有一个CPU用于执行垃圾回收操作，此时工作线程被暂停，直至垃圾收集工作结束。

  • 在诸如单CPU处理器或者较小的应用内存等硬件平台不是特别优越的场合，串行回收器的性能表现可以超过并行回收器和并发回收器。所以，串行回收默认被应用在客户端的Client模式下的JVM中。
  • 在并发能力比较强的CPU上，并行回收器产生的停顿时间要短于串行回收器。

和串行回收相反，并行收集可以运用多个CPU同时执行垃圾回收，因此提升了应用的吞吐量，不过并行回收仍然与串行回收一样，采用独占式，使用了“stop-the-world”机制。

2、按照工作模式分，可以分为并发式垃圾回收器和独占式垃圾回收器。

  • 并发式垃圾回收器与应用程序线程交替工作，以尽可能减少应用程序的停顿时间。
  • 独占式垃圾回收器(Stop the world)一旦运行，就停止应用程序中的所有用户线程，直到垃圾回收过程完全结束。

3、按碎片处理方式分，可分为压缩式垃圾回收器和非压缩式垃圾回收器。

  • 压缩式垃圾回收器会在回收完成后，对存活对象进行压缩整理，消除回收后的碎片。
  • 非压缩式的垃圾回收器不进行这步操作。

4、按工作的内存区间分，又可分为年轻代垃圾回收器和老年代垃圾回收器。

5.2、评估GC性能指标

  1. 吞吐量：运行用户代码的时间占总运行时间的比例
    • (总运行时间：程序的运行时间＋内存回收的时间)
  2. 垃圾收集开销：吞吐量的补数，垃圾收集所用时间与总运行时间的比例。
  3. 暂停时间：执行垃圾收集时，程序的工作线程被暂停的时间。
  4. 收集频率：相对于应用程序的执行，收集操作发生的频率。
  5. 内存占用：Java堆区所占的内存大小。
  6. 快速：一个对象从诞生到被回收所经历的时间。

吞吐量、暂停时间、内存占用这三者共同构成一个“不可能三角”。三者总体的表现会随着技术进步而越来越好。一款优秀的收集器通常最多同时满足其中的两项。

这三项里，暂停时间的重要性日益凸显。因为随着硬件发展，内存占用多些越来越能容忍，硬件性能的提升也有助于降低收集器运行时对应用程序的影响，即提高了吞吐量。而内存的扩大，对延迟反而带来负面效果。

简单来说，主要抓住两点：吞吐量、暂停时间

吞吐量：

吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值，即**吞吐量 = 运行用户代码时间/(运行用户代码时间＋垃圾收集时间)**。

比如：虚拟机总共运行了100分钟，其中垃圾收集花掉1分钟，那吞吐量就是99%。

这种情况下，应用程序能容忍较高的暂停时间，因此，高吞吐量的应用程序有更长的时间基准，快速响应是不必考虑的。

吞吐量优先，意味着在单位时间内，STW的时间最短：0.2 + 0.2 = 0.4

暂停时间：

“暂停时间”是指一个时间段内应用程序线程暂停，让GC线程执行的状态

例如，GC期间100毫秒的暂停时间意味着在这100毫秒期间内没有应用程序线程是活动的。

暂停时间优先，意味着尽可能让单次STW的时间最短：0.1 + 0.1 + 0.1 +0.1 + 0.1 = 0.5

两者对比：

  • 高吞吐量较好因为这会让应用程序的最终用户感觉只有应用程序线程在做“生产性”工作。直觉上，吞吐量越高程序运行越快。
  • 低暂停时间（低延迟）较好因为从最终用户的角度来看不管是GC还是其他原因导致一个应用被挂起始终是不好的。这取决于应用程序的类型，有时候甚至短暂的200毫秒暂停都可能打断终端用户体验。因此，具有低的较大暂停时间是非常重要的，特别是对于一个交互式应用程序。
  • 不幸的是”高吞吐量”和”低暂停时间”是一对相互竞争的目标（矛盾）。
    • 因为如果选择以吞吐量优先，那么必然需要降低内存回收的执行频率，但是这样会导致GC需要更长的暂停时间来执行内存回收。
    • 相反的，如果选择以低延迟优先为原则，那么为了降低每次执行内存回收时的暂停时间，也只能频繁地执行内存回收，但这又引起了年轻代内存的缩减和导致程序吞吐量的下降。

在设计（或使用）GC算法时，我们必须确定我们的目标：一个GC算法只可能针对两个目标之一（即只专注于较大吞吐量或最小暂停时间），或尝试找到一个二者的折衷。

现在标准：在最大吞吐量优先的情况下，降低停顿时间。

5.3、七款垃圾回收器

  • 新生代收集器: Serial、ParNew、Parallel Scavenge;
  • 老年代收集器: Serial Old、Parallel old、CMS;
  • 整堆收集器: G1;

七款垃圾回收器的组合关系：

5.3.1、Serial回收器：串行回收

Serial收集器是最基本、历史最悠久的垃圾收集器了。JDK1.3之前回收新生代唯一的选择。

serial收集器作为HotSpot中Client模式下的默认新生代垃圾收集器。

Serial 收集器采用复制算法、串行回收和”stop-the-world”机制的方式执行内存回收。

除了年轻代之外，Serial收集器还提供用于执行老年代垃圾收集的Serial Old收集器。Serial Old收集器同样也采用了串行回收和”stop the world”机制，只不过内存回收算法使用的是标记-压缩算法。

  • Serial old是运行在client模式下默认的老年代的垃圾回收器
  • Serial old在server模式下主要有两个用途：
    • ①与新生代的Parallel Scavenge配合使用；
    • ②作为老年代CMS收集器的后备垃圾收集方案。

这个收集器是一个单线程的收集器，但它的“单线程”的意义并不仅仅说明它只会使用一个CPU或一条收集线程去完成垃圾收集工作，更重要的是在它进行垃圾收集时，必须暂停其他所有的工作线程，直到它收集结束(Stop The World)。

  • 优势：简单而高效（与其他收集器的单线程比），对于限定单个CPU的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程收集效率。
    • 运行在Client模式下的虚拟机是个不错的选择。
  • 在用户的桌面应用场景中，可用内存一般不大（几十MB至一两百MB），可以在较短时间内完成垃圾收集（几十ms至一百多ms），只要不频繁发生，使用串行回收器是可以接受的。
  • 在HotSpot虚拟机中，使用-XX:+UseSerialGC参数可以指定年轻代和老年代都使用串行收集器。
    • 等价于新生代用Serial GC，且老年代用Serial Old GC

5.3.2、ParNew回收器：并行回收

如果说Serial GC是年轻代中的单线程垃圾收集器，那么ParNew收集器则是Serial收集器的多线程版本。（Par是Parallel的缩写，New：只能处理的是新生代）

ParNew收集器除了采用并行回收的方式执行内存回收外，两款垃圾收集器之间几乎没有任何区别。ParNew收集器在年轻代中同样也是采用**复制算法、”stop-the-world”**机制。

ParNew是很多JVM运行在Server模式下新生代的默认垃圾收集器。

  • 对于新生代，回收次数频繁，使用并行方式高效。
  • 对于老年代，回收次数少，使用串行方式节省资源。(CPU并行需要切换线程，串行可以省去切换线程的资源)

由于ParNew收集器是基于并行回收，那么是否可以断定ParNew收集器的回收效率在任何场景下都会比Serial收集器更高效？

  • ParNew收集器运行在多CPU的环境下，由于可以充分利用多CPU、多核心等物理硬件资源优势，可以更快速地完成垃圾收集，提升程序的吞吐量。
  • 但是在单个CPU的环境下，ParNew收集器不比Serial收集器更高效。虽然Serial收集器是基于串行回收，但是由于CPU不需要频繁地做任务切换，因此可以有效避免多线程交互过程中产生的一些额外开销。

因为除Serial外，目前只有ParNew GC能与CMS收集器配合工作。

  • 在程序中，开发人员可以通过选项”-XX:+UseParNewGC”手动指定使用ParNew收集器执行内存回收任务。它表示年轻代使用并行收集器，不影响老年代。
  • -XX:ParallelGCThreads限制线程数量，默认开启和CPU数据相同的线程数。

5.3.3、Parallel回收器：吞吐量优先

HotSpot的年轻代中除了拥有ParNew收集器是基于并行回收的以外，Parallel Scavenge收集器同样也采用了复制算法、并行回收和”stopthe world”机制。

那么Parallel收集器的出现是否多此一举？

  • 和ParNew收集器不同，Parallel scavenge收集器的目标则是达到一个可控制的吞吐量(Throughput)，它也被称为吞吐量优先的垃圾收集器。
  • 自适应调节策略也是Parallel Scavenge与ParNew一个重要区别。

高吞吐量则可以高效率地利用CPU时间，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务。因此，常见在服务器环境中使用。例如，那些执行批量处理、订单处理、工资支付、科学计算的应用程序。

Parallel 收集器在JDK1.6时提供了用于执行老年代垃圾收集的Parallel old收集器，用来代替老年代的serial old收集器。

Parallel Old收集器采用了标记-压缩算法，但同样也是基于并行回收和”Stop-the-world”机制。

  • 在程序吞吐量优先的应用场景中，Parallel收集器和Parallel Old收集器的组合，在Server模式下的内存回收性能很不错。
  • 在Java8中，默认是此垃圾收集器。

参数配置：

-XX:+UseParallelGC手动指定年轻代使用Parallel并行收集器执行内存回收任务。

-XX:+UseParallelOldGC手动指定老年代都是使用并行回收收集器。

  • 分别适用于新生代和老年代。默认jdk8是开启的。
  • 上面两个参数，默认开启一个，另一个也会被开启。（互相激活）

-Xx: ParallelGCThreads设置年轻代并行收集器的线程数。一般地，最好与CPU数量相等，以避免过多的线程数影响垃圾收集性能。

  • 在默认情况下，当CPU数量小于8个，ParallelGCThreads 的值等于CPU数量。
  • 当CPU数量大于8个，ParallelGCThreads 的值等于3+[5*CPU_Count]/8]。

自适应策略（Parallel Scavenge）：

  • -XX:+UseAdaptiveSizePolicy设置开启自适应策略（默认开启）
  • 在这种模式下，年轻代的大小，Eden和Survivor的比例\晋升老年代的对象年龄等参数会自动被调整，已达到在堆大小，吞吐量和停顿时间之间的平衡点。
  • 在游动调优比较困难的场合，可以直接使用这种自适应的方式，仅指定虚拟机的最大堆、目标的吞吐量(GCTimeRation)和停顿时间(MaxGCPauseMills)让虚拟机自己完成调优工作。

5.3.4、CMS回收器：低延迟

  • 在JDK 1.5时期，HotSpot推出了一款在强交互应用中几乎可认为有划时代意义的垃圾收集器: CMS（Concurrent-Mark-Sweep)收集器，这款收集器是HotSpot虚拟机中第一款真正意义上的并发收集器，它第一次实现了让垃圾收集线程与用户线程同时工作。

  • CMS收集器的关注点是尽可能缩短垃圾收集时用户线程的停顿时间。停顿时间越短（低延迟）就越适合与用户交互的程序，良好的响应速度能提升用户体验。

    • 目前很大一部分的Java应用集中在互联网站或者B/S系统的服务端上，这类应用尤其重视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验。CMS收集器就非常符合这类应用的需求。

  • CMS的垃圾收集算法采用标记-清除算法，并且也会”Stop-The-World”

不幸的是，CMS作为老年代的收集器，却无法与JDK 1.4.0中已经存在的新生代收集器Parallel Scavenge 配合工作，所以在JDK 1.5中使用CMS来收集老年代的时候，新生代只能选择ParNew或者Serial收集器中的一个。

在G1出现之前，CMS使用还是非常广泛的。一直到今天，仍然有很多系统使用CMS GC。

CMS整个过程比之前的收集器要复杂，整个过程分为4个主要阶段，即初始标记阶段、并发标记阶段、重新标记阶段和并发清除阶段。

  • 初始标记(Initial-Mark）阶段：在这个阶段中，程序中所有的工作线程都将会因为“stop-the-world”机制而出现短暂的暂停，这个阶段的主要任务仅仅只是标记出GC Roots能直接关联到的对象。一旦标记完成之后就会恢复之前被暂停的所有应用线程。由于直接关联对象比较小，所以这里的速度非常快。

  • 并发标记（Concurrent-Mark）阶段：从GC Roots的直接关联对象开始遍历整个对象图的过程，这个过程耗时较长但是不需要停顿用户线程，可以与垃圾收集线程一起并发运行。

  • 重新标记（Remark）阶段：由于在并发标记阶段中，程序的工作线程会和垃圾收集线程同时运行或者交叉运行，因此为了修正并发标记期间，因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间通常会比初始标记阶段稍长一些，但也远比并发标记阶段的时间短。

  • 并发清除(Concurrent-Sweep）阶段：此阶段清理删除掉标记阶段判断的已经死亡的对象，释放内存空间。由于不需要移动存活对象，所以这个阶段也是可以与用户线程同时并发的

尽管CMS收集器采用的是并发回收（非独占式），但是在其初始化标记和再次标记这两个阶段中仍然需要执行“Stop-the-world”机制暂停程序中的工作线程，不过暂停时间并不会太长，因此可以说明目前所有的垃圾收集器都做不到完全不需要“stop-the-world”，只是尽可能地缩短暂停时间。

由于最耗费时间的并发标记与并发清除阶段都不需要暂停工作，所以整体的回收是低停顿的。

另外，由于在垃圾收集阶段用户线程没有中断，所以在CMS回收过程中，还应该确保应用程序用户线程有足够的内存可用。因此，CMS收集器不能像其他收集器那样等到老年代几乎完全被填满了再进行收集，而是当堆内存使用率达到某一阈值时，便开始进行回收，以确保应用程序在CMS工作过程中依然有足够的空间支持应用程序运行。要是CNS运行期间预留的内存无法满足程序需要，就会出现一次“Concurrent Mode Failure“失败，这时虚拟机将启动后备预案：临时启用Serial Old收集器来重新进行老年代的垃圾收集,这样停顿时间就很长了。

CMS收集器的垃圾收集算法采用的是标记-清除算法，这意味着每次执行完内存回收后，由于被执行内存回收的无用对象所占用的内存空间极有可能是不连续的一些内存块，不可避免地将会产生一些内存碎片。那么CMS在为新对象分配内存空间时，将无法使用指针碰撞（Bump the Pointer）技术，而只能够选择空闲列表（Free List）执行内存分配。

那么为什么CMS不采用标记-整理算法？

  • 因为CMS时，用户线程还在执行，因此不能改变对象的地址。

CMS的优点：

  • 并发收集
  • 低延迟

CMS的弊端：

  • 会产生内存碎片，导致并发清除后，用户线程可用的空间不足。在无法分配大对象的情况下，不得不提前触发Full GC。
  • CMS收集器对CPU资源非常敏感。在并发阶段，它虽然不会导致用户停顿，但是会因为占用了一部分线程而导致应用程序变慢，总吞吐量会降低。
  • CMS收集器无法处理浮动垃圾。可能出现“Concurrent Mode Failure”失败而导致另一次 Full GC 的产生。在并发标记阶段由于程序的工作线程和垃圾收集线程是同时运行或者交叉运行的，那么在并发标记阶段如果产生新的垃圾对象，CMS将无法对这些垃圾对象进行标记，最终会导致这些新产生的垃圾对象没有被及时回收，从而只能在下一次执行GC时释放这些之前未被回收的内存空间。

参数设置：

  • 手动指定使用CMS：-XX:+UseConcMarkSweepGC，开启该参数后会自动将-XX:+UseParNewGC打开。即ParNew（年轻代用）+CMS（老年代用）+Serial Old组合使用
  • 设置堆内存使用率的阈值： -XX:CMSlnitiatingOccupanyFraction （如果内存增长缓慢，可以把阈值设置的高一点）
  • 用于指定Full GC后对内存空间进行整理，消除内存碎片：-XX:+UseCMSCompactAtFullCollection
  • 设置执行多少次Full GC后对内存空间进行整理：-XX:CMSFullGCsBeforeCompaction
  • 设置CMS的线程数-XX:ParallelCMSThreads

小结：

HotSpot有这么多的垃圾回收器，那么如果有人问，Serial GC、Parallel GC、Concurrent Mark Sweep GC这三个GC有什么不同呢?请记住以下口令：

如果你想要最小化地使用内存和并行开销，请选Serial GC;

如果你想要最大化应用程序的吞吐量，请选Parallel GC;

如果你想要最小化cc的中断或停顿时间，请选CMS GC。

5.3.5、G1回收器：区域化分代式

G1(Garbage First)回收器是为了适应不断扩大的内存和不断增加的处理器数量，进一步降低暂停时间，同时兼顾良好的吞吐量。

官方给G1设定的目标是在延迟可控的情况下获得尽可能高的吞吐量。

G1是一个并行回收器，它把堆分割为许多不相关的区域（Region）(物理上不连续)。使用不同的Region来表示Eden S0 S1 老年代。G1可以跟踪每个Region的垃圾堆积价值，在后台维护一个优先队列，每次根据允许的收集时间，优先回收价值最大的Region。由于这种方式的侧重点在于回收垃圾最大量的区域(Region)，所以叫垃圾优先(G1/Garbage First)

G1是面向服务端应用的垃圾收集器，主要针对配备了多核CPU及大容量内存的机器，以极高概率满足GC停顿时间的同时，还兼具高吞吐量的性能特征。

在JDK1.7版本正式启用，移除了Experimental的标识，是JDK 9以后的默认垃圾回收器，取代了CMS回收器以及Parallel + Parallel old组合。被oracle官方称为“全功能的垃圾收集器”。

与此同时，CMS已经在JDK 9中被标记为废弃（deprecated)。在jdk8中还不是默认的垃圾回收器，需要使用-XX:+UseG1GC来启用。

分区Regin介绍：

使用G1收集器时，它将整个Java堆划分成约2048个大小相同的独立Region块，每个Region块大小根据堆空间的实际大小而定，整体被控制在1MB到32MB之间，且为2的N次幂，即1MB，2MB，4MB，8MB，16MB，32MB。可以通过-XX:G1HeapRegionSize设定。所有的Region大小相同，且在JVM生命周期内不会被改变。

虽然还保留有新生代和老年代的概念，但新生代和老年代不再是物理隔离的了，它们都是一部分Region (不需要连续）的集合。通过Regin的动态分配方式实现逻辑上的连续。

一个region 有可能属于 Eden，Survivor或者 Old/Tenured 内存区域。但是个region只可能属于一个角色。图中的E表示该region属于Eden内存区域，s表示属于survivor内存区域，o表示属于Old内存区域。图中空白的表示未使用的内存空间。

G1垃圾收集器还增加了一种新的内存区域，叫做 Humongous内存区域，如图中的H块。主要用于存储大对象，如果超过1.5个region，就放到H。

优势：

与其他 GC收集器相比，G1使用了全新的分区算法，其特点如下所示:

  • 并行与并发

    • 并行性：G1在回收期间，可以有多个cc线程同时工作，有效利用多核计算能力。此时用户线程STW
    • 并发性：G1拥有与应用程序交替执行的能力，部分工作可以和应用程序同时执行，因此，一般来说，不会在整个回收阶段发生完全阻塞应用程序的情况

  • 分代收集

    • 从分代上看，G1依然属于分代型垃圾回收器，它会区分年轻代和老年代，年轻代依然有Eden区和survivor区。但从堆的结构上看，它不要求整个Eden区、年轻代或者老年代都是连续的，也不再坚持固定大小和固定数量。
    • 将堆空间分为若干个区域(Region)，这些区域中包含了逻辑上的年轻代和老年代。
    • 和之前的各类回收器不同，它同时兼顾年轻代和老年代。对比其他回收器，或者工作在年轻代，或者工作在老年代。

  • 空间整合

    • CMS：“标记-清除”算法、内存碎片、若干次GC后进行一次碎片整理。
    • G1将内存划分为一个个的region。内存的回收是以region作为基本单位的。Region之间是复制算法，但整体上实际可看作是标记-压缩（Mark-Compact)算法，两种算法都可以避免内存碎片。这种特性有利于程序长时间运行，分配大对象时不会因为无法找到连续内存空间而提前触发下一次GC。尤其是当Java堆非常大的时候，G1的优势更加明显。

  • 可预测的停顿时间模型（即：软实时soft real-time)

    这是 G1 相对于CMS 的另一大优势，G1除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒。

    • 由于分区的原因，G1可以只选取部分区域进行内存回收，这样缩小了回收的范围，因此对于全局停顿情况的发生也能得到较好的控制。
    • G1跟踪各个Region里面的垃圾堆积的价值大小（回收所获得的空间大小以及回收所需时间的经验值），在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region。保证了G1收集器在有限的时间内可以获取尽可能高的收集效率。
    • 相比于CMS Gc，G1未必能做到CMS在最好情况下的延时停顿，但是最差情况要好很多。

缺点：

  • 相较于CMS，G1还不具备全方位、压倒性优势。比如在用户程序运行过程中，G1无论是为了垃圾收集产生的内存占用(Footprint）还是程序运行时的额外执行负载(Overload）都要比CMS要高。
  • 从经验上来说，在小内存应用上CMS的表现大概率会优于G1，而G1在大内存应用上则发挥其优势。平衡点在6-8GB之间。

参数设置：

  • -X:+UseG1GC：手动指定使用G1收集器执行内存回收任务。
  • -XX:G1HeapRegionSize：设置每个Region的大小。值是2的幂，范围是1MB到32MB之间，目标是根据最小的Java堆大小划分出约2048个区域。默认是堆内存的1/2000。
  • -XX:MaxGCPauseMillis：设置期望达到的最大GC停顿时间指标（JVM会尽力实现，但不保证达到）。默认值是200ms
  • -XX: ParallelGCThread：设置STW工作线程数的值。最多设置为8
  • -XX:ConcGCThreads：设置并发标记的线程数。将n设置为并行垃圾回收线程数(ParallelGCThreads)的1/4左右。
  • -XX:InitiatingHeapOccupancyPercent：设置触发并发GC周期的Java堆占用率阈值。超过此值，就触发GC。默认值是45。