JVM知识点整理

1. 创建类的实例
2. 访问某个类或接口的静态变量，或者对该静态变量赋值
3. 调用类的静态方法I
4. 反射（比如：Class.forName（"com.atguigu.Test"））
5. 初始化一个类的子类
6. Java虚拟机启动时被标明为启动类的类
7. JDK7开始提供的动态语言支持：
8. java.lang.invoke.MethodHandle实例的解析结果REF getStatic、REF putStatic、REF invokeStatic句柄对应的类没有初始化，则初始化

其他使用Java类的方式都被看作是对类的被动使用，都不会导致类的初始化。

/** * 演示栈中的异常：StackOverflowError */
public class StackErrorTest {
 private static int count = 1;
 public static void main(String[] args) {
 System.out.println(count++);
 main(args);
 }
}

/**
* VM Args：-Xss2M
*启动多个线程，实现 OutOfMemoryError异常;
*通过不断的创建线程的方式来产生内存溢出异常。
*/
public class JavaVMStackOOM {

private void dontStop() {
while (true) {
}
}

public void stackLeakByThread() {
while (true) {
Thread thread = new Thread(new Runnable() {
@Override
public void run() {
dontStop();
}
});
thread.start();
}
}

public static void main(String[] args) throws Throwable {
JavaVMStackOOM oom = new JavaVMStackOOM();
oom.stackLeakByThread();
}
}

介绍：

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

静态变量与局部变量的对比:

变量的分类：

• 按数据类型分：基本数据类型、引用数据类型
• 按类中声明的位置分：成员变量（类变量-static修饰，实例变量）、局部变量
•      类变量：linking的paper阶段，给类变量默认赋值，init阶段给类变量显示赋值即静态代码块
•      实例变量：随着对象创建，会在堆空间中分配实例变量空间，并进行默认赋值
•      局部变量：在使用前必须进行显式赋值，不然编译不通过。
  参数表分配完毕之后，再根据方法体内定义的变量的顺序和作用域分配。

我们知道类变量表有两次初始化的机会，第一次是在“准备阶段”，执行系统初始化，对类变量设置零值，另一次则是在“初始化”阶段，
赋予程序员在代码中定义的初始值。

和类变量初始化不同的是，局部变量表不存在系统初始化的过程，这意味着一旦定义了局部变量则必须人为的初始化，否则无法使用。

在栈帧中，与性能调优关系最为密切的部分就是前面提到的局部变量表。在方法执行时，虚拟机使用局部变量表完成方法的传递。

局部变量表中的变量也是重要的垃圾回收根节点，只要被局部变量表中直接或间接引用的对象都不会被回收。

概念：

• 每一个独立的栈帧除了包含局部变量表以外，还包含一个后进先出（Last - In - First -Out）的 操作数栈，也可以称之为 表达式栈（Expression Stack）
• 操作数栈，在方法执行过程中，根据字节码指令，往栈中写入数据或提取数据，即入栈（push）和 出栈（pop）
•   某些字节码指令将值压入操作数栈，其余的字节码指令将操作数取出栈。使用它们后再把结果压入栈
  
•   比如：执行复制、交换、求和等操作

• 操作数栈，主要用于保存计算过程的中间结果，同时作为计算过程中变量临时的存储空间。
• 操作数栈就是JVM执行引擎的一个工作区，当一个方法刚开始执行的时候，一个新的栈帧也会随之被创建出来，这个方法的操作数栈是空的。
• 这个时候数组是有长度的，因为数组一旦创建，那么就是不可变的。
• 每一个操作数栈都会拥有一个明确的栈深度用于存储数值，其所需的最大深度在编译期就定义好了，保存在方法的Code属性中，为maxstack的值。
• 栈中的任何一个元素都是可以任意的Java数据类型
•   32bit的类型占用一个栈单位深度
•   64bit的类型占用两个栈单位深度
• 操作数栈并非采用访问索引的方式来进行数据访问的，而是只能通过标准的入栈和出栈操作来完成一次数据访问。
• 如果被调用的方法带有返回值的话，其返回值将会被压入当前栈帧的操作数栈中，并更新PC寄存器中下一条需要执行的字节码指令。
• 操作数栈中元素的数据类型必须与字节码指令的序列严格匹配，这由编译器在编译器期间进行验证，同时在类加载过程中的类检验阶段的数据流分析阶段要再次验证。|
• 另外，我们说Java虚拟机的解释引擎是基于栈的执行引擎，其中的栈指的就是操作数栈。

栈顶缓存技术：Top Of Stack Cashing

• 基于栈式架构的虚拟机所使用的零地址指令更加紧凑，但完成一项操作的时候必然需要使用更多的入栈和出栈指令，这同时也就意味着将需要更多的指令分派（instruction dispatch）次数和内存读/写次数。
• 由于操作数是存储在内存中的，因此频繁地执行内存读/写操作必然会影响执行速度。为了解决这个问题，HotSpot JVM的设计者们提出了栈顶缓存（Tos，Top-of-Stack Cashing）技术，将栈顶元素全部缓存在物理CPU的寄存器中，以此降低对内存的读/写次数，提升执行引擎的执行效率。
• 寄存器：指令更少，执行速度快

概述：
每一个栈帧内部都包含一个指向运行时常量池中该栈帧所属方法的引用，
包含这个引用的目的就是为了支持当前方法的代码能够实现动态链接（Dynamic Linking）。比如：invokedynamic指令

在Java源文件被编译到字节码文件中时，所有的变量和方法引用都作为符号引用（symbolic Reference）保存在class文件的常量池里。

比如：描述一个方法调用了另外的其他方法时，就是通过常量池中指向方法的符号引用来表示的，那么动态链接的作用
就是为了将这些符号引用转换为调用方法的直接引用。

为什么需要运行时常量池？

因为在不同的方法，都可能调用常量或者方法，所以只需要存储一份即可，节省了空间。
常量池的作用：就是为了提供一些符号和常量，便于指令的识别

方法调用：解析与分配
  * 在JVM中，将符号引用转换为调用方法的直接引用与方法的绑定机制相关

概述：
存放调用该方法的pc寄存器的值。一个方法的结束，有两种方式：

• 正常执行完成
• 出现未处理的异常，非正常退出
  
  无论通过哪种方式退出，在方法退出后都返回到该方法被调用的位置。方法正常退出时，
  调用者的pc计数器的值作为返回地址，即调用该方法的指令的下一条指令的地址。
  而通过异常退出的，返回地址是要通过异常表来确定，栈帧中一般不会保存这部分信息。
  

栈帧中还允许携带与Java虚拟机实现相关的一些附加信息。例如：对程序调试提供支持的信息。

public class StringBuilderTest {

// s1的声明方式是线程安全的
public static void method01() {
// 线程内部创建的，属于局部变量
StringBuilder s1 = new StringBuilder();
s1.append("a");
s1.append("b");
}

// 这个也是线程不安全的，因为有返回值，有可能被其它的程序所调用
public static StringBuilder method04() {
StringBuilder stringBuilder = new StringBuilder();
stringBuilder.append("a");
stringBuilder.append("b");
return stringBuilder;
}

// stringBuilder 是线程不安全的，操作的是共享数据
public static void method02(StringBuilder stringBuilder) {
stringBuilder.append("a");
stringBuilder.append("b");
}


/**
* 同时并发的执行，会出现线程不安全的问题
*/
public static void method03() {
StringBuilder stringBuilder = new StringBuilder();
new Thread(() -> {
stringBuilder.append("a");
stringBuilder.append("b");
}, "t1").start();

method02(stringBuilder);
}

// StringBuilder是线程安全的，但是String也可能线程不安全的
public static String method05() {
StringBuilder stringBuilder = new StringBuilder();
stringBuilder.append("a");
stringBuilder.append("b");
return stringBuilder.toString();
}
}

 // -Xms10m -Xmx10m
public static void main(String[] args) {
            List<Integer> list = new ArrayList<>();
            while(true) {
               list.add(999999999);
            }
}

图示

图示

• JDK命令行
• Eclipse：Memory Analyzer Tool
• Jconsole
• Visual VM（实时监控 推荐~）
• Jprofiler（推荐~）
• Java Flight Recorder（实时监控）
• GCViewer
• GCEasy

指发生在老年代的GC，对象从老年代消失时，我们说 “Major Gc” 或 “Full GC” 发生了

出现了MajorGc，经常会伴随至少一次的Minor GC
（但非绝对的，在Paralle1 Scavenge收集器的收集策略里就有直接进行MajorGC的策略选择过程）

也就是在老年代空间不足时，会先尝试触发MinorGc。如果之后空间还不足，则触发Major GC
Major GC的速度一般会比MinorGc慢10倍以上，STW的时间更长，如果Major GC后，内存还不足，就报OOM了

触发FullGC执行的情况有如下五种：

• 调用System.gc（）时，系统建议执行FullGC，但是不必然执行
• 老年代空间不足
• 方法区空间不足
• 通过Minor GC后进入老年代的平均大小大于老年代的可用内存
• 由Eden区、survivor spacee（From Space）区向survivor spacel（To Space）区复制时，
  对象大小大于To Space可用内存，则把该对象转存到老年代，且老年代的可用内存小于该对象大小

说明：Full GC 是开发或调优中尽量要避免的。这样暂时时间会短一些

概念：
从内存模型而不是垃圾收集的角度，对Eden区域继续进行划分，JVM为每个线程分配了
一个私有缓存区域，它包含在Eden空间内。

多线程同时分配内存时，使用TLAB可以避免一系列的非线程安全问题，同时还能够提升内
存分配的吞吐量，因此我们可以将这种内存分配方式称之为快速分配策略。

问题：堆空间都是共享的么？ 不一定，因为还有TLAB这个概念，在堆中划分出一块区域，为每个线程所独占

TLAB：Thread Local Allocation Buffer，也就是为每个线程单独分配了一个缓冲区，
堆区是线程共享区域，任何线程都可以访问到堆区中的共享数据，
由于对象实例的创建在JVM中非常频繁，因此在并发环境下从堆区中划分内存空间是线程不安全的，
为避免多个线程操作同一地址，需要使用加锁等机制，进而影响分配速度。

随着JIT编译期的发展与逃逸分析技术逐渐成熟，栈上分配、标量替换优化技术将会导致一些
微妙的变化，所有的对象都分配到堆上也渐渐变得不那么“绝对”了。

有一种特殊情况，那就是如果经过逃逸分析（Escape Analysis）后发现，
一个对象并没有逃逸出方法的话，那么就可能被优化成栈上分配。

逃逸分析的基本行为就是分析对象动态作用域：

• 当一个对象在方法中被定义后，对象只在方法内部使用，则认为没有发生逃逸。

当一个对象在方法中被定义后，它被外部方法所引用，则认为发生逃逸。例如作为调用参数传递到其他地方中。

在JDK 1.7 版本之后，HotSpot中默认就已经开启了逃逸分析

如果使用的是较早的版本，开发人员则可以通过： 

• 选项“-xx：+DoEscapeAnalysis"显式开启逃逸分析
• 通过选项“-xx：+PrintEscapeAnalysis"查看逃逸分析的筛选结果

JIT编译器在编译期间根据逃逸分析的结果，发现如果一个对象并没有逃逸出方法的话，
就可能被优化成栈上分配。分配完成后，继续在调用栈内执行，最后线程结束，栈空间被回收，
局部变量对象也被回收。这样就无须进行垃圾回收了。

常见的栈上分配的场景

在逃逸分析中，已经说明了。分别是给成员变量赋值、方法返回值、实例引用传递。

在动态编译同步块的时候，JIT编译器可以借助逃逸分析来判断同步块所使用的锁对象是否只能够
被一个线程访问而没有被发布到其他线程。如果没有，那么JIT编译器在编译这个同步块的时候就会
取消对这部分代码的同步。这样就能大大提高并发性和性能。这个取消同步的过程就叫同步省略，也叫锁消除。

标量（scalar）是指一个无法再分解成更小的数据的数据。Java中的原始数据类型就是标量。

相对的，那些还可以分解的数据叫做聚合量（Aggregate），Java中的对象就是聚合量，因为他可以
分解成其他聚合量和标量。

在JIT阶段，如果经过逃逸分析，发现一个对象不会被外界访问的话，那么经过JIT优化，就会把这个对象
拆解成若干个其中包含的若干个成员变量来代替。这个过程就是标量替换。

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

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

• 方法区，内部包含了运行时常量池
• 字节码文件，内部包含了常量池
• 要弄清楚方法区，需要理解清楚C1assFile，因为加载类的信息都在方法区。
• 要弄清楚方法区的运行时常量池，需要理解清楚classFile中的常量池。

静态变量和类关联在一起，随着类的加载而加载，他们成为类数据在逻辑上的一部分

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

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

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

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

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

指针碰撞：
如果内存规整，采用此方法，意思是所有用过的内存在一边，空闲的内存放另外一边，中间放着一个指针
作为分界点的指示器，分配内存就仅仅是把指针指向空闲那边挪动一段与对象大小相等的距离罢了。如果
垃圾收集器选择的是Serial ，ParNew这种基于压缩算法的，虚拟机采用这种分配方式。一般使用带
Compact（整理）过程的收集器时，使用指针碰撞。

空闲列表：
如果内存不规整。虚拟机维护了一个列表，记录上那些内存块是可用的，再分配的时候从列表中找到
一块足够大的空间划分给对象实例，并更新列表上的内容。这种分配方式成为了 “空闲列表（Free List）”

运行时元数据：

• 哈希值（HashCode）
• GC分代年龄
• 锁状态标志
• 线程持有的锁
• 偏向线程ID
• 翩向时间戳

类型指针：
指向类元数据InstanceKlass，确定该对象所属的类型。
指向的其实是方法区中存放的类元信息

一个被多次调用的方法，或者是一个方法体内部循环次数较多的循环体都可以被称之为“热点代码”，
因此都可以通过JIT编译器编译为本地机器指令。由于这种编译方式发生在方法的执行过程中，
因此被称之为栈上替换，或简称为OSR（On Stack Replacement）编译。

目前HotSpot VM所采用的热点探测方式是基于计数器的热点探测。采用基于计数器的热点探测，
HotSpot V将会为每一个方法都建立2个不同类型的计数器，分别为方法调用计数器
（Invocation Counter）和回边计数器（Back Edge Counter）。

• 方法调用计数器用于统计方法的调用次数
• 回边计数器则用于统计循环体执行的循环次数

缺省情况下HotSpot VM是采用解释器与即时编译器并存的架构，当然开发人员可以根据具体的应用场景，
通过命令显式地为Java虚拟机指定在运行时到底是完全采用解释器执行，还是完全采用即时编译器执行。如下所示：

-Xint：完全采用解释器模式执行程序；
-Xcomp：完全采用即时编译器模式执行程序。如果即时编译出现问题，解释器会介入执行
-Xmixed：采用解释器+即时编译器的混合模式共同执行程序。

JIT的编译器还分为了两种，分别是C1和C2，在HotSpot VM中内嵌有两个JIT编译器，
分别为Client Compiler和Server Compiler，但大多数情况下我们简称为C1编译器 和 C2编译器。
开发人员可以通过如下命令显式指定Java虚拟机在运行时到底使用哪一种即时编译器，如下所示：

-client：指定Java虚拟机运行在Client模式下，并使用C1编译器；
     C1编译器会对字节码进行简单和可靠的优化，耗时短。以达到更快的编译速度。

-server：指定Java虚拟机运行在server模式下，并使用C2编译器。
    C2进行耗时较长的优化，以及激进优化。但优化的代码执行效率更高。（使用C++）

程序执行时并非在所有地方都能停顿下来开始GC，只有在特定的位置才能停顿下来开始GC，这些位置称为“安全点（Safepoint）”。

Safe Point的选择很重要，如果太少可能导致GC等待的时间太长，如果太频繁可能导致运行时的性能问题。大部分指令的执行时间都非常短暂，
通常会根据“是否具有让程序长时间执行的特征”为标准。比如：选择一些执行时间较长的指令作为Safe Point，如方法调用、循环跳转和异常跳转等。

如何在GC发生时，检查所有线程都跑到最近的安全点停顿下来呢？

• 抢先式中断：（目前没有虚拟机采用了）首先中断所有线程。如果还有线程不在安全点，就恢复线程，让线程跑到安全点。
• 主动式中断：设置一个中断标志，各个线程运行到Safe Point的时候主动轮询这个标志，如果中断标志为真，则将自己进行中断挂起。（有轮询的机制）

Safepoint 机制保证了程序执行时，在不太长的时间内就会遇到可进入GC的Safepoint。但是，程序“不执行”的时候呢？例如线程处于sleep-状态或Blocked 状态，这时候线程无法响应JVM的中断请求，“走”到安全点去中断挂起，JVM也不太可能等待线程被唤醒。对于这种情况，就需要安全区域（Safe Region）来解决。

安全区域是指在一段代码片段中，对象的引用关系不会发生变化，在这个区域中的任何位置开始Gc都是安全的。我们也可以把Safe Region看做是被扩展了的Safepoint。

执行流程：

• 当线程运行到Safe Region的代码时，首先标识已经进入了Safe Region，如果这段时间内发生GC，JVM会忽略标识为Safe Region状态的线程
• 当线程即将离开Safe Region时，会检查JVM是否已经完成GC，如果完成了，则继续运行，否则线程必须等待直到收到可以安全离开Safe Region的信号为止；

• 程序中最常见的引用类型是强引用（普通系统99%以上都是强引用），也就是我们最常见的普通对象引用，

也是默认的引用类型。

• 当在Java语言中使用new操作符创建一个新的对象，并将其赋值给一个变量的时候，

这个变量就成为指向该对象的一个强引用。强引用的对象是可触及的，垃圾收集器就永远不会回收掉被引用的对象。

强引用，强引用具备以下特点：

• 强引用可以直接访问目标对象。
• 强引用所指向的对象在任何时候都不会被系统回收，虚拟机宁愿抛出OOM异常，也不会回收强引用所指向对象。
• 强引用可能导致内存泄漏。

软引用是用来描述一些还有用，但非必需的对象。在JDK1.2版之后提供了SoftReference类来实现软引用。
只被软引用关联着的对象，在系统将要发生内存溢出异常前，会把这些对象列进回收范围之中进行第二次回收，
如果这次回收还没有足够的内存，才会抛出内存溢出异常。

软引用通常用来实现内存敏感的缓存。比如：高速缓存就有用到软引用。如果还有空闲内存，就可以暂时保留缓存，
当内存不足时清理掉，这样就保证了使用缓存的同时，不会耗尽内存。
一句话概括：当内存足够时，不会回收软引用可达的对象。内存不够时，会回收软引用的可达对象

Object obj = new Object(); // 声明强引用
SoftReference<Object> sf = new SoftReference<>(obj); // 创建一个软引用
obj = null; //销毁强引用，这是必须的，不然会存在强引用和软引用

发现即回收
弱引用也是用来描述那些非必需对象，被弱引用关联的对象只能生存到下一次垃圾收集发生为止。
在系统GC时，只要发现弱引用，不管系统堆空间使用是否充足，都会回收掉只被弱引用关联的对象。

Object obj = new Object();  // 声明强引用
WeakReference<Object> sf = new WeakReference<>(obj);  // 创建一个弱引用
obj = null; //销毁强引用，这是必须的，不然会存在强引用和弱引用

• 也称为“幽灵引用”或者“幻影引用”，是所有引用类型中最弱的一个。
• 为一个对象设置虚引用关联的唯一目的在于跟踪垃圾回收过程。比如：能在这个对象被收集器回收时收到一个系统通知。
• 虚引用必须和引用队列 （ReferenceQueue）联合使用。当垃圾回收器准备回收一个对象时，如果发现它还有虚引用，

就会在回收对象的内存之前，把这个虚引用加入到与之 关联的引用队列中。

Object obj = new Object();  // 声明强引用
ReferenceQueue phantomQueue = new ReferenceQueue();  // 声明引用队列
PhantomReference<Object> sf = new PhantomReference<>(obj, phantomQueue);  // 声明虚引用（还需要传入引用队列）
obj = null; 

概述

概述

GC ROOTS

对象的finalization机制

标记过程

图示

• 标记：Collector从引用根节点开始遍历，标记所有被引用的对象。一般是在对象的Header中记录为可达对象。

        标记的是引用的对象，不是垃圾！！

• 清除：Collector对堆内存从头到尾进行线性的遍历，如果发现某个对象在其Header中没有标记为可达对象，则将其回收
  
  这里所谓的清除并不是真的置空，而是把需要清除的对象地址保存在空闲的地址列表里。下次有新对象需要加载时，
  判断垃圾的位置空间是否够，如果够，就存放覆盖原有的地址。
  关于空闲列表是在为对象分配内存的时候 提，过：
  
  • 如果内存规整，采用指针碰撞的方式进行内存分配。
  • 如果内存不规整，虚拟机需要维护一个列表，空闲列表分配。

这里所谓的清除并不是真的置空，而是把需要清除的对象地址保存在空闲的地址列表里。下次有新对象需要加载时，
判断垃圾的位置空间是否够，如果够，就存放覆盖原有的地址。
关于空闲列表是在为对象分配内存的时候 提，过：

• 如果内存规整，采用指针碰撞的方式进行内存分配。
• 如果内存不规整，虚拟机需要维护一个列表，空闲列表分配。

图示

• 将活着的内存空间分为两块，每次只使用其中一块，在垃圾回收时将正在使用的内存中的存活对象复制到未被使用的内存块中，

之后清除正在使用的内存块中的所有对象，交换两个内存的角色，最后完成垃圾回收

• 把可达的对象，直接复制到另外一个区域中复制完成后，A区就没有用了，里面的对象可以直接清除掉，

其实里面的新生代里面就用到了复制算法

优点

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

缺点

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

图示

• 第一阶段和标记清除算法一样，从根节点开始标记所有被引用对象
• 第二阶段将所有的存活对象压缩到内存的一端，按顺序排放。之后，清理边界外所有的空间。
  
  标记-压缩算法的最终效果等同于标记-清除算法执行完成后，再进行一次内存碎片整理，因此，
  也可以把它称为标记-清除-压缩（Mark-Sweep-Compact）算法。
  

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

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

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

如果一次性将所有的垃圾进行处理，需要造成系统长时间的停顿，那么就可以让垃圾收集线程
和应用程序线程交替执行。每次，垃圾收集线程只收集一小片区域的内存空间，接着切换到
应用程序线程。依次反复，直到垃圾收集完成。

总的来说，增量收集算法的基础仍是传统的标记-清除和复制算法。增量收集算法通过对线程间
冲突的妥善处理，允许垃圾收集线程以分阶段的方式完成标记、清理或复制工作

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

图示

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

分代算法将按照对象的生命周期长短划分成两个部分，分区算法将整个堆空间划分成连续的不同小区间。
每一个小区间都独立使用，独立回收。这种算法的好处是可以控制一次回收多少个小区间。

按线程数分

按工作模式分

按碎片处理方式分

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

图

图示

• G1是一个并行回收器，它把堆内存分割为很多不相关的区域（Region）（物理上不连续的）。

使用不同的Region来表示Eden、幸存者0区，幸存者1区，老年代等。

• G1 GC有计划地避免在整个Java堆中进行全区域的垃圾收集。G1跟踪各个Region里面的垃圾堆

积的价值大小（回收所获得的空间大小以及回收所需时间的经验值），在后台维护一个优先列表，
每次根据允许的收集时间，优先回收价值最大的Region。

• 是JDK9以后的默认垃圾回收器，CMS已经在JDK9中被标记为废弃（deprecated）。

优点：
1、并行与并发

• 并行性：G1在回收期间，可以有多个GC线程同时工作，有效利用多核计算能力。
• 并发性：G1拥有与应用程序交替执行的能力，部分工作可以和应用程序同时执行，因此，一般来说，

     不会在整个回收阶段发生完全阻塞应用程序的情况
2、分代收集

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

3、空间整合

• CMS：“标记-清除”算法、内存碎片、若干次GC后进行一次碎片整理。
• G1将内存划分为一个个的region。内存的回收是以region作为基本单位的。

      Region之间是复制算法，但整体上实际可看作是标记-压缩（Mark-Compact）算法，
      两种算法都可以避免内存碎片。这种特性有利于程序长时间运行，分配大对象时不会因为无法找到
      连续内存空间而提前触发下一次GC。尤其是当Java堆非常大的时候，G1的优势更加明显。
4、可预测的停顿时间模型（即：软实时soft real-time）：这是G1相对于CMS的另一大优势，G1除了追求低停顿外，
还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒。

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

• -XX:+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。

• 使用G1收集器时，它将整个Java堆划分成约2048个大小相同的独立Region块，

每个Region块大小根据堆空间的实际大小而定，整体被控制在1MB到32MB之间，且为2的N次幂。

• XX:G1HeapRegionsize设定。所有的Region大小相同，且在JVM生命周期内不会被改变。

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

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

**设置H的原因：**对于堆中的对象，默认直接会被分配到老年代，但是如果它是一个短期存在的大对象就会对垃圾收集器造成负面影响。
为了解决这个问题，G1划分了一个Humongous区，它用来专门存放大对象。如果一个H区装不下一个大对象，
那么G1会寻找连续的H区来存储。为了能找到连续的H区，有时候不得不启动Fu11Gc。G1的大多数行为都把H区作为老年代的一部分来看待。

每个Region都是通过指针碰撞来分配空间

一个对象被不同区域引用的问题。
一个Region不可能是孤立的，一个Region中的对象可能被其他任意Region中对象引用，
判断对象存活时，是否需要扫描整个Java堆才能保证准确？

无论G1还是其他分代收集器，JVM都是使用Remembered Set来避免全局扫描：
每个Region都有一个对应的Remembered Set；每次Reference类型数据写操作时，都会产生一个Write Barrier暂时中断操作；
然后检查将要写入的引用指向的对象是否和该Reference类型数据在不同的Region（其他收集器：检查老年代对象是否引用了新生代对象）；
如果不同，通过cardTable把相关引用信息记录到引用指向对象的所在Region对应的Remembered Set中；当进行垃圾收集时，
在GC根节点的枚举范围加入Remembered Set；就可以保证不进行全局扫描，也不会有遗漏。

年轻代GC（Young GC）

老年代并发标记过程（Concurrent Marking）

混合回收（Mixed GC）

G1回收可选的过程4 - Full GC

年轻代大小 避免使用-Xmn或-XX:NewRatio等相关选项显式设置年轻代大小 固定年轻代的大小会覆盖 暂停时间目标暂停时间目标不要太过严苛 G1 GC的吞吐量目标是90%的应用程序时间和10%的垃圾回收时间 评估G1GC的吞吐量时，暂停时间目标不要太严苛。目标太过严苛表示你愿意承受更多的垃圾回收开销，而这些会直接影响到吞吐量。

-XX:+PrintGc输出GC日志。类似：-verbose:gc -XX:+PrintGcDetails输出Gc的详细日志 -XX:+PrintGcTimestamps 输出Gc的时间戳（以基准时间的形式） -XX:+PrintGCDatestamps 输出Gc的时间戳（以日期的形式，如2013-05-04T21：53：59.234+0800） -XX:+PrintHeapAtGC在进行Gc的前后打印出堆的信息 -Xloggc:../logs/gc.1og日志文件的输出路径