JVM(九) - 垃圾回收机制
各语言内存操作对比：
| 语言 |
申请内存 |
释放内存 |
| C |
malloc |
free |
| C++ |
new |
delete |
| Java |
new |
自动释放 |
Java语言的自动内存管理设计最终可以归结为自动化地解决了两个问题：
- 给对象分配内存，可查看JVM内存模型、Java对象创建等文章；
- 回收分配给对象的内存。
即对象内存的分配和回收。
了解JVM是垃圾回收机制，如何有效防止内存泄露、保证内存的有效使用，需要思考三个方向的问题：
- 什么对象的内存需要回收？(什么是垃圾？怎么判断对象是垃圾？)
- 用什么方式回收？（垃圾回收的算法？）
- 有什么垃圾收集器？
一、对象回收判断
进行垃圾回收的第一步：什么是垃圾？ 没有引用指向的一个对象或多个对象(循环引用)。
定位垃圾的方法有两种：引用计数法和可达性分析。
1、对像的引用
Java中将数据类型分为两大类：基本类型和引用类型。如果reference类型数据中存储的数值为另一个块内存的起始地址，就称这块内存代表一个引用。在JDK1.2开始对引用的概念进行了扩充，分为强、软、弱、虚四种引用，且强度依次逐渐降低。详细见Java-四种引用类型。
Person p = new Person();
// 等号后面的 new Person(); 是真正的实例对象，其内容存储在Java堆内存中
// 等号前面的 p 只是一个引用标识符，保存在虚拟机栈内存中，它存储的只是一个地址，是 new Person() 在堆内存中的起始位置，因此 p 就是一个引用。
// 等号是一种强引用方式2、引用计数法(Reference Count已淘汰 )
引用计数法是垃圾收集器中的早期策略，通过判断对象的引用数量来决定对象是否可以被回收。该方法为堆中每个对象添加一个计数器，有地方引用了此对象则该对象的计数器加1，如果引用失效了则计数器减1，引用计数为0的对象实例则可以被当作垃圾收集。
优点：实现简单，判定效率也很高；
缺点：很难解决对象之间循环引用的问题；互相引用导致他们的引用计数都不为0，最终不能回收他们。
3、根可达性分析算法(Root Searching)
通过判断对象的引用链是否可达GCRoot来决定对象是否可以被回收。从离散数学中的图论引入，把所有的引用关系当作一张关系图谱，从被称为"GCRoot"的对象作为起始点，沿着引用链(Reference Chain，即引用路径)向下搜索，如果一个对象没有任何引用链连接到GCRoot节点，则证明此对象是不可用的/不可达，则此对象可被回收。
JAVA中可以作为GCRoot对象/根对象包括以下几种：
- 虚拟机栈(栈帧中的局部变量表)中引用的对象；
- 方法区中类静态变量引用的对象；
- 方法区中运行常量池引用的对象；
- 本地方法栈中Native方法引用的对象；
如图，引用链连接上GCroot的Object1、2、3、4都是被使用的对象，但是Object5、6、7却不能通过任何方式连接上根节点，因此判定Object5、6、7为可回收的节点。
4、对象死亡和自我拯救
可达性分析之后，不可达的对象一定会被垃圾收集器回收吗？不一定。
在可达性分析后发现不可达的对象会被进行一次标记，然后进行筛选，筛选的条件是判断该对象有没有必要执行finalize()方法；
- 回收情况：如果对象没有重写finalize()方法或者对象的finalize方法已经被虚拟机调用过一次了，则都将视为"没有必要执行"，垃圾回收器直接回收对象。
- 自救情况：如果对有重写finalize()方法且对象的finalize方法没有被虚拟机调用过，则将该对象判定"有必要执行"，那么虚拟机会把这个对象放置在一个F-Queue的队列中，然后由一个专门的Finalizer线程去执行这个对象的finalize()方法；在这个方法中可以进行对象的"自我拯救"，即重新与引用链上的任何一个对象建立关联就可以了，如把this赋值给某个类的变量、或者对象的成员变量；但在又被第二次GC标记时它将被移除"即将回收"的集合。
1、对象无finalize方法：直接去除引用链，一次GC时便直接回收实例对象。
// JVM执行参数 -Xmx20m -XX:+PrintGCDetails
public class FinalizeTest {
static class M {
// 10M大小
private byte[] bytes = new byte[10 * 1024 * 1024];
}
public static void main(String[] args) throws Exception {
M m = new M();
m = null;
// new M()被去掉引用，且M中没有自救方法finalize，所以在GC时会直接回收
System.gc();
// GC相关线程优先级低，主线程等待一下
Thread.sleep(1000);
}
}
// 日志
/* 年轻代PSYoungGen的总内存大小为6144k=6M，所以10M的new M()对象会直接被分配在老年代ParOldGen*/
[GC (System.gc()) [PSYoungGen: 1749K->480K(6144K)] 11989K->10765K(19968K), 0.0018203 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
// FGC情况下，ParOldGen老年代从10285K->471K
[Full GC (System.gc()) [PSYoungGen: 480K->0K(6144K)] [ParOldGen: 10285K->471K(13824K)] 10765K->471K(19968K), [Metaspace: 3087K->3087K(1056768K)], 0.0046541 secs] [Times: user=0.01 sys=0.00, real=0.00 secs]
/* 可知new M()有10M大小，从整个堆上各代的使用内存情况，可知new M()已经不在堆上面，也可以通过jmap来查看实例对象存活*/
/* 后面的三个内存地址值指的是：起始地址，已使用空间的结束地址，对应区整个内存空间的结束地址 */
Heap
PSYoungGen total 6144K, used 1255K [0x00000007bf980000, 0x00000007c0000000, 0x00000007c0000000)
eden space 5632K, 22% used [0x00000007bf980000,0x00000007bfab9f10,0x00000007bff00000)
from space 512K, 0% used [0x00000007bff00000,0x00000007bff00000,0x00000007bff80000)
to space 512K, 0% used [0x00000007bff80000,0x00000007bff80000,0x00000007c0000000)
ParOldGen total 13824K, used 471K [0x00000007bec00000, 0x00000007bf980000, 0x00000007bf980000)
object space 13824K, 3% used [0x00000007bec00000,0x00000007bec75e70,0x00000007bf980000)
Metaspace used 3613K, capacity 4536K, committed 4864K, reserved 1056768K
class space used 399K, capacity 428K, committed 512K, reserved 1048576K
Process finished with exit code 02、对象有finalize方法，但不进行自我拯救：直接去除引用链，第一次GC时对象放入F-Queue的队列且进行finalize方法的拯救，不会被回收，但finalize中并未拯救，所以第二次GC时对象会被回收。
public class FinalizeTest {
static class M {
// 10M大小
private byte[] bytes = new byte[10 * 1024 * 1024];
@Override
protected void finalize() {
System.out.println("m的finalize执行了，但并不拯救");
}
}
public static void main(String[] args) throws Exception {
M m = new M();
m = null;
System.out.println("第一次GC-----------");
// 因为M的存在finalize，所以被放入F-Queue的队列中，拯救线程执行finalize方法，所以10M的new M()对象本次不被回收
System.gc();
// GC相关线程优先级低，主线程等待一下
Thread.sleep(1000);
// 第二次GC，
System.out.println("第二次GC-----------");
// 因为M的finalize已经执行了，但并未拯救，所以10M的new M()对象被回收了
System.gc();
Thread.sleep(1000);
}
}
// 日志
第一次GC-----------
[GC (System.gc()) [PSYoungGen: 1862K->512K(6144K)] 12102K->10797K(19968K), 0.0022455 secs] [Times: user=0.01 sys=0.00, real=0.00 secs]
/* 第一次FGC情况下，ParOldGen老年代从10285K->10712K，说明并未回收10M的new M()对象*/
[Full GC (System.gc()) [PSYoungGen: 512K->0K(6144K)] [ParOldGen: 10285K->10712K(13824K)] 10797K->10712K(19968K), [Metaspace: 3101K->3101K(1056768K)], 0.0040101 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
m的finalize执行了，但并不拯救
第二次GC-----------
[GC (System.gc()) [PSYoungGen: 1422K->448K(6144K)] 12134K->11168K(19968K), 0.0008161 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
/* 第二次FGC情况下，ParOldGen老年代从10720K->773K，因为M的finalize已经执行了，但并未拯救，所以10M的new M()对象被回收了*/
[Full GC (System.gc()) [PSYoungGen: 448K->0K(6144K)] [ParOldGen: 10720K->773K(13824K)] 11168K->773K(19968K), [Metaspace: 3614K->3614K(1056768K)], 0.0054856 secs] [Times: user=0.01 sys=0.00, real=0.00 secs]
Heap
PSYoungGen total 6144K, used 150K [0x00000007bf980000, 0x00000007c0000000, 0x00000007c0000000)
eden space 5632K, 2% used [0x00000007bf980000,0x00000007bf9a5a40,0x00000007bff00000)
from space 512K, 0% used [0x00000007bff80000,0x00000007bff80000,0x00000007c0000000)
to space 512K, 0% used [0x00000007bff00000,0x00000007bff00000,0x00000007bff80000)
ParOldGen total 13824K, used 773K [0x00000007bec00000, 0x00000007bf980000, 0x00000007bf980000)
object space 13824K, 5% used [0x00000007bec00000,0x00000007becc1520,0x00000007bf980000)
Metaspace used 3620K, capacity 4540K, committed 4864K, reserved 1056768K
class space used 399K, capacity 428K, committed 512K, reserved 1048576K
Process finished with exit code 03、对象有finalize，且会自我拯救：直接去除引用链，第一次GC时对象放入F-Queue的队列且进行finalize方法的拯救，不会被回收；第二次GC时，被拯救的对象保持着新的引用链，所以不会被回收。
public class FinalizeTest {
public static M saveMen = null;
static class M {
// 10M大小
private byte[] bytes = new byte[10 * 1024 * 1024];
@Override
protected void finalize() {
FinalizeTest.saveMen = this;
System.out.println("m的finalize执行了，且自我拯救");
}
}
public static void main(String[] args) throws Exception {
M m = new M();
m = null;
System.out.println("第一次GC-----------");
System.gc();
// GC相关线程优先级低，主线程等待一下
Thread.sleep(1000);
System.out.print("saveMen: " + saveMen);
// 第二次GC
System.out.println("第二次GC-----------");
System.gc();
Thread.sleep(1000);
System.out.print("saveMen: " + saveMen);
}
}
// 日志
第一次GC-----------
[GC (System.gc()) [PSYoungGen: 1862K->496K(6144K)] 12102K->10781K(19968K), 0.0019234 secs] [Times: user=0.01 sys=0.00, real=0.00 secs]
/* 第一次FGC情况下，ParOldGen老年代从10285K->10712K，说明并未回收10M的new M()对象*/
[Full GC (System.gc()) [PSYoungGen: 496K->0K(6144K)] [ParOldGen: 10285K->10712K(13824K)] 10781K->10712K(19968K), [Metaspace: 3103K->3103K(1056768K)], 0.0043965 secs] [Times: user=0.01 sys=0.00, real=0.00 secs]
m的finalize执行了，且自我拯救
/* 打印拯救的变量saveMen的引用，说明拯救成功 */
saveMen: edward.com.FinalizeTest$M@3fee733d第二次GC-----------
[GC (System.gc()) [PSYoungGen: 1423K->384K(6144K)] 12136K->11104K(19968K), 0.0018592 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
/* 第二次FGC情况下，ParOldGen老年代从10720K->11013K，因为M的finalize已经执行且已拯救，所以10M的new M()对象被saveMen强引用着*/
[Full GC (System.gc()) [PSYoungGen: 384K->0K(6144K)] [ParOldGen: 10720K->11013K(13824K)] 11104K->11013K(19968K), [Metaspace: 3618K->3618K(1056768K)], 0.0074772 secs] [Times: user=0.01 sys=0.00, real=0.01 secs]
/* 第二次GC后打印拯救的变量saveMen的引用，说明对象还在 */
saveMen: edward.com.FinalizeTest$M@3fee733dHeap
PSYoungGen total 6144K, used 263K [0x00000007bf980000, 0x00000007c0000000, 0x00000007c0000000)
eden space 5632K, 4% used [0x00000007bf980000,0x00000007bf9c1ce0,0x00000007bff00000)
from space 512K, 0% used [0x00000007bff80000,0x00000007bff80000,0x00000007c0000000)
to space 512K, 0% used [0x00000007bff00000,0x00000007bff00000,0x00000007bff80000)
ParOldGen total 13824K, used 11013K [0x00000007bec00000, 0x00000007bf980000, 0x00000007bf980000)
object space 13824K, 79% used [0x00000007bec00000,0x00000007bf6c16f0,0x00000007bf980000)
Metaspace used 3625K, capacity 4540K, committed 4864K, reserved 1056768K
class space used 399K, capacity 428K, committed 512K, reserved 1048576K
Process finished with exit code 04、对象有finalize，且会自我拯救，但两次去除引用链：直接去除引用链，第一次GC时对象放入F-Queue的队列且进行finalize方法的拯救，不会被回收；但第二次GC时，被拯救的对象的新引用链又去除，这次对象直接被回收。
public class FinalizeTest {
public static M saveMen = null;
static class M {
// 10M大小
private byte[] bytes = new byte[10 * 1024 * 1024];
@Override
protected void finalize() {
FinalizeTest.saveMen = this;
System.out.println("m的finalize执行了，且自我拯救");
}
}
public static void main(String[] args) throws Exception {
M m = new M();
m = null;
System.out.println("第一次GC-----------");
System.gc();
// GC相关线程优先级低，主线程等待一下
Thread.sleep(1000);
System.out.print("saveMen: " + saveMen);
// 第二次GC，且再次去除次拯救new M()对象的引用链
saveMen = null;
System.out.println("第二次GC-----------");
System.gc();
Thread.sleep(1000);
System.out.print("saveMen: " + saveMen);
}
}
// 日志
第一次GC-----------
[GC (System.gc()) [PSYoungGen: 1862K->496K(6144K)] 12102K->10781K(19968K), 0.0008208 secs] [Times: user=0.00 sys=0.01, real=0.00 secs]
/* 第一次FGC情况下，ParOldGen老年代从10285K->10712K，说明并未回收10M的new M()对象*/
[Full GC (System.gc()) [PSYoungGen: 496K->0K(6144K)] [ParOldGen: 10285K->10712K(13824K)] 10781K->10712K(19968K), [Metaspace: 3111K->3111K(1056768K)], 0.0044683 secs] [Times: user=0.01 sys=0.00, real=0.01 secs]
m的finalize执行了，且自我拯救
/* 打印拯救的变量saveMen的引用，说明拯救成功 */
saveMen: edward.com.FinalizeTest$M@3fee733d第二次GC-----------
[GC (System.gc()) [PSYoungGen: 1423K->416K(6144K)] 12136K->11136K(19968K), 0.0018508 secs] [Times: user=0.01 sys=0.00, real=0.01 secs]
/* 第二次FGC情况下，ParOldGen老年代从10720K->774K，因为M的finalize已经执行且已拯救，所以再次去掉引用后GC，10M的new M()对象直接被回收*/
[Full GC (System.gc()) [PSYoungGen: 416K->0K(6144K)] [ParOldGen: 10720K->774K(13824K)] 11136K->774K(19968K), [Metaspace: 3624K->3624K(1056768K)], 0.0078671 secs] [Times: user=0.01 sys=0.00, real=0.00 secs]
/* 第二次GC后打印拯救的变量saveMen的引用，对象不在 */
saveMen: nullHeap
PSYoungGen total 6144K, used 263K [0x00000007bf980000, 0x00000007c0000000, 0x00000007c0000000)
eden space 5632K, 4% used [0x00000007bf980000,0x00000007bf9c1ce0,0x00000007bff00000)
from space 512K, 0% used [0x00000007bff80000,0x00000007bff80000,0x00000007c0000000)
to space 512K, 0% used [0x00000007bff00000,0x00000007bff00000,0x00000007bff80000)
ParOldGen total 13824K, used 774K [0x00000007bec00000, 0x00000007bf980000, 0x00000007bf980000)
object space 13824K, 5% used [0x00000007bec00000,0x00000007becc1938,0x00000007bf980000)
Metaspace used 3631K, capacity 4540K, committed 4864K, reserved 1056768K
class space used 399K, capacity 428K, committed 512K, reserved 1048576K
Process finished with exit code 0二、垃圾收集算法
1、标记清除算法(Mark-Sweep)
算法分为"标记"和"清除"两个阶段。
- 标记：从根集合进行扫描，对需要回收的对象进行标记。(也可以标记存活的对象)
- 清除：标记完毕后，再扫描整个空间中被标记的对象并进行回收。
优点：逻辑清晰，易于操作；
缺点：
- 效率不稳定：标记和清除两个过程需要大量标记和清除的动作；
- 内存空间碎片化：标记清除后会产生内存空间碎片，会导致需要分配大对象时空间不足再次触发回收。
2、标记复制算法(Coping)
将可用内存划分为大小相等的两块，每次只使用其中的一块，当一块的内存用完，将还存活的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。
适用于对象存活率低的场景，研究发现新生代中的对象每次回收都基本上只有10%左右的对象存活，所以需要复制的对象很少，效率不错。
优点：内存区域连续性，不会产生内存碎片，实现简单，运行高效。
缺点：
- 空间浪费：可用内存缩小为了原来的一半；
- 内存的复制开销：存在大量存活对象时复制开销越大；
3、标记压缩算法(Mark-Compact)
和标记清除算法类似，但后续不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存，类似于磁盘整理的过程。
适用于对象存活率高的场景（老年代）。
优点：
- 解决了标记清除算法产生内存碎片的问题
- 解决了复制算法只能利用一半内存的问题
三、分代收集算法(Generational Collecting)
HotSpot虚拟机的堆内存分代设计：
1、新生代(Young Generation)：
一般情况下，所有新生成的对象首先都是放在新生代的，目标就是尽可能快的收集掉那些生命周期短的对象。
- 新生代内存按照 8:1:1 的比例分为一个eden区和两个survivor(survivor0，survivor1)区，大部分对象在Eden区中生成；
- 新生代发生的GC也叫做MinorGC，MinorGC发生频率比较高，不一定等 Eden区满了才触发；
- Minor GC垃圾回收时，先将eden区存活对象复制到survivor0区，然后清空eden区；
- survivor0区也满了时，则将eden区和survivor0区存活对象复制到survivor1区，然后清空eden和这个survivor0区；
- 交换survivor0区和survivor1区的角色，保持 一个survivor为空；
- 某个survivor区也不足以存放eden区和另一个survivor区的存活对象时，就将存活对象直接存放到老年代；
- 老年代也满了，就会触发一次FullGC，也就是新生代、老年代都进行回收；
YGC条件：Eden区满
2、老年代(Old Generation)：
一般情况下，存放的都是一些生命周期较长的对象，在新生代中经历了N次垃圾回收后仍然存活的对象就会被放到老年代中。
- 老年代的内存也比新生代大很多(大概比例是2:1)；
- 老年代满时会触发Major GC(Full GC)，老年代对象存活时间比较长，因此FullGC发生的频率比较低。
Full GC的原因：
- 老年代被写满、永久代（JDK1.7 Perm）被写满
- 空间担保原则生败
- System.gc()被显式调用，执行jmap -dump时。
对象进入老年代的情况：
- 大对象：指需要大量连续内存空间的对象，如很长的字符串和数组。因为复制成本较高，所以 直接进入到老年代，避免新生代发生大量的内存复制。（由JVM参数-XX:+PretenureSizeThreshold=100000设置，单位为字节）
- 长期存活的对象：每个对象都有一个年龄计数器。每进行一次Minor GC，年龄就加1，当年龄超过一定值时（默认是15，由JVM参数-XX:MaxTenuringThreshold=15配置；CMS是6岁，不同收集器略微不同），就进入到老年代。
- 对象动态年龄判断：
- 什么时候动态判断：mimor GC后，为解决Survivor存活区对象放不下。
- 动态判断规则定义：Survivor空间中同一年龄的所有对象大小总和 > 一半Survivor区空间，则将 >= 该年龄的对象放入老年代，不一定要求对象年龄到达15。
- 内存判断的标准：一半Survivor空间大小，即默认50%，可通过-XX:TargetSurvivorRatio来配置
- 计算规则：从小到大算，先从age1算，不满足再从age2计算。
在JVM运行稳定后，以FGC后老年代存活对象空间大小为参考：
- Java堆，参数-Xms和-Xmx，建议扩大至3-4倍FGC后的老年代空间占用；
- 年轻代，参数-Xmn，建议扩大至1-1.5倍FGC之后的老年代空间占用；
- 老年代，2-3倍FGC后的老年代空间占用；
老年代的空间分配担保原则：
空间担保原则触发条件：Minor GC前
在发生Minor GC之前，虚拟机会计算老年代剩余可用空间 > 年轻代所有对象总空间(包括垃圾对象)？
- 如果大于，那么Minor GC可以确保是安全的（因为极端情况下，就算新生代所有对象都存活，也可以保证安全晋升到老年代）。
- 如果小于，虚拟机会查看-XX:+HandlePromotionFailure配置的值是否允许担保失败。允许担保失败，那么会继续检查老年代可用空间是否 > 历次晋升到老年代对象的平均大小。如果大于，将尝试进行一次Minor GC（尽管有风险）；如果小于或者HandlePromotionFailure设置不允许冒险，那么就先进行一次Full GC。
以上说的有风险，是因为取历次晋升到老年代对象的平均值，并不能保证每次都能担保成功;如果担保失败的话，依然需要进行Full GC。所以我们最好还是打开HandlePromotionFailure开关，避免过多频繁的Full GC（因为Full GC的执行速度比Minor GC慢的多）。
3、永久代(Permanent Generation)/方法区/元空间
- 永久代主要存放的是类信息、静态变量、编译代码、运行时常量池；
- 在JDK1.8之前永久代是有固定默认内存大小，也可通过JVM参数配置，所以需要进行垃圾回收；
- 永久代的内存回收目标主要是针对 常量池的回收 和 对类型的卸载，同堆的回收一样；
- 在JDK1.8开始把永久代移除了，而用元空间代替。字符串常量和类引用被移动到 Java Heap中，元空间直接使用本机物理内存，不受JVM内存限制；
GC情况：
- 元空间默认就是21M，满了之后就会FGC，收集器并增大元空间内存。又满后FGC，再增大元空间内存，直到扩大的元空间大小合适不再发生FGC，或到MaxMetaspaceSize设置的最大值。
- 一般建议JVM参数将-XX:MetaspaceSize和-XX:MaxMetaspaceSize设置成一样的值，8G内存的机器，一般会将这两个值设置为256M或者512M都可以
类对象的回收条件：
- 该类所有的实例都已经被回收，即Java堆中不存在该类的任何实例；
- 加载该类的ClassLoader已经被回收；
- 该类对应的 java.lang.Class 对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法；
JVM堆内存为什么分代 ？
不同对象的生命周期(存活情况)是不一样的，分代可以根据不同对象的情况进行不同的管理和回收。
新生代：存活率低，每次垃圾收集都有大批对象死去，选择复制算法快速且只需要付出少量存活对象的复制成本即可；
老年代：存活率高，没有额外空间对它进行分配担保，因此使用标记清除或者标记整理算法；
gc频率和耗时也不一样，使性能最高效。
新生代各区内存比例为什么是8:1:1？
研究发现新生代中的对象每次回收都基本上只有10%左右的对象存活。这样划分内存的空间利用率达到了90%，只有10%的空间是浪费掉；
四、垃圾收集器
JVM的出现过的十种垃圾收集器，及组合方式：
Serial(年轻代)/Serial Old(老年代)适用于单CPU的环境，单线程、简单高效、没有线程切换的开销，垃圾收集时会暂停其他用户进程。
Serial Old在JDK1.5中配合PS使用；也作为CMS的后备选择，在concurrent mode failure时使用。
ParNew其实就是 Serial 收集器的多线程并行版本（参数控制、收集算法、STW、对象分配规则、回收策略等），在多核CPU环境下有着比Serial更好的表现。可以使用-XX:ParallelGCThreads参数来控制垃圾收集线程数，默认和CPU数量一样。也是为了和CMS组合的。
PS是吞吐优先的回收器，GC自适应调节策略。
https://hllvm-group.iteye.com/group/topic/37095#post-242695
ParNew为什么不能和Parallel Old组合？
PNew和PS是不同人在同一时期开发的，PS的开发者更注重高吞吐(自适应策略)，和PNew低停顿是对立的，PS开发之后效果不错就合上去了，正好同一期PO的开发(也有PS的开发)就是为了兼容PS，所以就组合一起了，且PO只能和PS组合。
查看JVM默认使用的垃圾回收器命令：
// PrintCommandLineFlags打印JVM启动的命令行参数
java -XX:+PrintCommandLineFlags -version
JVM垃圾回收器使用配置：
- -XX:+UseSerialGC：新生代使用Serial，老年代使用Serial Old；
- -XX:+UseParallelGC/-XX:UseParallelOldGC：新生代使用Parallel Scavenge，老年代使用Parallel Old
- -XX:+UseParNewGC：新生代使用ParNew，老年代自动使用Serial Old；
- -XX:+UseConMarkSweepGC：新生代使用ParNew，老年代使用CMS + Serial Old；
- -XX:+UseG1GC：使用G1；
JDK1.8server模式下，默认使用PS+PO收集器。
1、Serial(串行)收集器
年轻代的单线程收集器，采用复制算法，GC时会暂停所有用户进程(Stop The Wold)；
2、Serial Old收集器
老年代的单线程收集器，采用标记-整理算法，Serial收集器的老年代版本，也会STW。
- Serial Old是Serial的老年代版本；
- Serial Old在JDK1.5中配合PS使用；
- 也作为CMS的后备选择，在concurrent mode failure时使用。
3、ParNew收集器
年轻代的并行收集器，采用复制算法，ParNew收集器实质上是 Serial 收集器的多线程并行版本，在多核CPU环境下有着比Serial更好的表现，和CMS收集器配合使用。
- 并行(Parallel)收集器：指多条垃圾收集线程并行工作，但此时用户线程仍然STW。有PN、PS、PO收集器。
- 并发(Concurrent)收集器：指用户线程与垃圾收集线程同时执行(交替执行)，用户程序在继续运行，而垃圾收集器运行在另一个 CPU 上。
4、Parallel Scavenge收集器
也是年轻代收集器，采用复制算法的多线程并行收集器 ，但Parall Scavenger 收集追求高吞吐量，高效利用CPU；所以也叫吞吐量优先收集器。
与Parallel New的区别：
- 关注高吞吐量：吞吐量 = 用户线程时间/(用户线程时间+GC线程时间)，高吞吐量可以高效率的利用CPU时间；
- GC自适应调节策略：虚拟机会根据系统运行状况收集监控信息，动态设置相关内存参数以提供最优的停顿时间和最高的吞吐量。
- 开关参数设置：-XX:+UseAdptiveSizePolicy，打开开关后不需要手动指定新生代大小(-Xmn)、Eden区和Survivor区比例(-XX:SurvivorRation)、晋升老年代年龄(-XX:PretenureSizeThreshold)等；
- 吞吐参数设置：
- -XX:MaxGCPauseMillis：控制最大的GC停顿时间
- -XX:GCRation：直接设置吞吐量的大小
5、Parallel Old收集器
老年代的多线程并行收集器，采用标记-整理算法，吞吐量优先，为配合PS收集器的老年代版本。
6、CMS(Concurrent Mark Sweep)收集器
老年代并发收集器，采用标记 - 清除算法，以最短回收低停顿时间为目标的收集器，HotSpot 虚拟机第一款真正意义上的并发收集器，它第一次实现了让垃圾收集线程与用户线程（基本上）同时工作。STW时间能降低到200ms内。
CMS收集器使用的是标记 - 清除算法，所以会产生内存碎片，对于内存碎片的处理需要通过 标记-整理算法来进行压缩整理，所以CMS收集器的老年代也会搭配Serial Old收集器使用！！！
- -XX:CMSInitiatingOccupancyFraction：老年代使用内存回收阈值，超过该阀值后开始CMS收集，默认是68%。
- -XX:+UseCMSCompactAtFullCollection：在FGC时压缩整理内存，通过SerialOld收集器
- -XX:CMSFullGCsBeforeCompaction：多少次FGC之后进行压缩整理
基于标记 - 清除算法的实现四个步骤 :
- 初始标记(Initial Mark)：找到GC Roots 对象能关联的对象(GCroot第一层子节点)，速度很快，需要STW；
- 并发标记(Concurrent Mark)：从GC Roots 关联对象开始遍历整个对象图的过程，与用户线程并发运行，会耗时较长但是不需要停顿用户线程；
- 重新标记(remark)：修正在并发标记期间，因用户程序运行而导致标记产生变动的那一部分对象的标记记录。这个阶段会STW，重新从头扫描有用的树(所以不存在漏标)，停顿时间会比初始标记长些，但也远比并发标记阶段时间短。
- 并发清除(Concurrent Sweep)：清除掉标记阶段判断已死亡的对象，由于不需要移动存活对象，这个阶段也是并发执行的。
缺点：
- 浮动垃圾(Floating Garbage)：在并发清除阶段，用户线程将已标记不用回收的对象引用去掉，而GC并不会回收该阶段产生的垃圾，必须到下一次垃圾收集才能处理。如果浮动垃圾太多，会concurrent mode failure再次触发垃圾回收，导致性能降低；
- 因会产生内存碎片，导致大对象无法分配，所以也会提前触发FGC，也可通过参数控制-XX:CMSInitiatingOccupancyFraction内存回收阈值，默认是68%；
- 虽然重新标记阶段会解决部分漏标场景，但是三色标记算法的还会存在不可以解决的漏标问题。
CMS的并发预处理和并发可中断预处理？
1、首先，CMS是一个关注停顿时间，以回收停顿时间最短为目标的垃圾回收器。并发预处理阶段做的工作是标记，重标记需要STW（Stop The World），因此重标记的工作尽可能多的在并发阶段完成来减少STW的时间。此阶段标记从新生代晋升的对象、新分配到老年代的对象以及在并发阶段被修改了的对象。
2、并发可中断预清理(Concurrent precleaning)是标记在并发标记阶段引用发生变化的对象，如果发现对象的引用发生变化，则JVM会标记堆的这个区域为Dirty Card。那些能够从Dirty Card到达的对象也被标记（标记为存活），当标记做完后，这个Dirty Card区域就会消失。CMS有两个参数：CMSScheduleRemarkEdenSizeThreshold、CMSScheduleRemarkEdenPenetration，默认值分别是2M、50%。两个参数组合起来的意思是预清理后，eden空间使用超过2M时启动可中断的并发预清理（CMS-concurrent-abortable-preclean），直到eden空间使用率达到50%时中断，进入重新标记阶段。
为什么CMS后有G1？
因为现代服务器可用内存发展越来越大，CMS清理之后会老年代会产生内存碎片，内存不够时还是会FGC，可能老年代的内存碎片空间并不大，但是内存压缩整理时需要移动很多对象的内存，导致FGC停顿时间很长(如128G的堆，停顿10～20分钟)。所以CMS不适用于大内存的JVM虚拟机。CMS起着承上启下的作用。
7、G1(Garbage First)收集器
G1 跳出固定大小以及固定分代区域划分的限制，而是把连续的 Java 堆分成了多个大小相等的不需要连续的独立区域 ( region )，每一个 region 都可以根据需要扮演新生代的 Eden Survivor空间 或者 老年代空间。分而治之的思想，STW时间能降低到10ms内，主要适用于多处理器、大容量内存的、追求低停顿同时具备高吞吐的垃圾回收器。
内存结构：
G1特点：
- 用在heap memory很大的情况下，把heap划分为很多很多的region块，然后并行进行垃圾回收；
- JVM规定不超过2048个Region(JVM源码里TARGET_REGION_NUMBER 定义)，实际可以超过但是不推荐；
- Region大小等于堆大小除以2048，比如堆大小为4096M，则Region大小为2M；也可以用JVM参数 -XX:G1HeapRegionSize指定Region大小。
- Region 中还有一类特殊的 Humongous 区域，专门用来存储大对象，G1 认为大对象 -即超过 region内存的一半的对象；
- Humongous区专门存放短期大型对象，不用直接进老年代，节约老年代的空间，避免因为老年代空间不够的GC开销。
- Region保留了年轻代和老年代的概念，它们不再是物理隔离，它们都是(可以不连续)Region的集合；
- 收集器根据对Region的不同角色采用不同的策略去回收；
- 年轻代的垃圾回收使用复制算法，把Eden区和Survivor区的对象复制到新的Survivor区域；
- 老年代的垃圾收集，G1也分为四个阶段如下文；
- 回收Region的时候基本不会STW，从整体来看是基于标记-整理算法，从局部(两个region之间)来看基于复制算法；
- G1会维护一个优先级列表，优先处理回收价值收益最大的那些Region，价值即回收所获得的空间大小、回收所需时间，就如其名。
- 根据该回收的Region中的Rset(Remember Set为每个Region中记录其内的对象被引用的对象所在区)找到其他分区。
- Full GC除了收集年轻代和老年代之外，也会将Humongous区一并回收。
- 一个Region可能之前是年轻代，该Region进行垃圾回收后可能又会变成老年代；Region的区域功能可能会动态变化。
G1老年代收集器的运作可分四个步骤：
- 初始标记：同CMS一样，标记 GC Roots 直接关联的对象，速度很快，也会STW。但是G1的初始标记结点是跟Minor gc一起发生的，把老年代上的初始标记给做了；不用像CMS那样，FGC时的执行。
- 并发标记：同CMS一样，扫描整个堆的对象图找到要回收的对象，会耗时较长但可与用户线程并发执行。但G1会多做一件事件，计算每个Region的存活率，方便后面的清除阶段使用，以及在该阶段发现哪些老年代Region中对象的存活率很小或者基本没有对象存活，则G1就会在这个阶段将其回收掉，不用等到后面的清除阶段，这也是Garbage First名字的由来。
- 最终标记：同CMS一样，修正在并发标记期间，因用户程序运行而导致标记产生变动的那一部分对象的标记记录，用户线程会STW。但是GC采用的算法不一样，G1采用了一种叫做STAB(snapshot-at-the-begining)的算法能够在Remark阶段更快的标记可达对象。
- 筛选回收(clean up/Copy)：从Region的统计数据中对各区的回收价值和成本进行排序，必须暂停用户线程。根据用户期望的停顿时间来制定回收计划，可以自由选择任意多个Region构成回收集，然后把决定回收的那一部分Region的存活对象复制到空的Region中，再清理掉整个旧Region的全部空间。这里的操作涉及存活对象的移动，是必须暂停用户线程，由多条收集器线程并行完成的。G1会挑选出那么对象存活率低的region进行回收，这个阶段也是和minor gc一同完成的
G1垃圾收集的种类：
- YoungGC：YGC并不是现有Eden区满了就马上触发 ，G1会计算Eden区回收大概需要的时间，如果回收时间远小于-XX:MaxGCPauseMills配置的指，则增加年轻代Eden区的Region，继续给新对象存放 ；直到Eden区再次放满，计算回收时间接近参数设定的指，才会触发YoungGC；
- MixedGC：不是FullGC，老年代的堆占有率达到-XX:InitiatingHeapOccupancyPercent设定的比例则触发MixedGC，回收所有年轻代和部分老年代(根据期望GC停顿时间确定Old区的垃圾收集先后顺序)，以及大对象区，正常情况G1是先进行MixedGC，使用复制算法，把各个Region中存活的对象拷贝到别的Region里去，拷贝过程如果发现没有足够的空Region能放拷贝的对象就会触发一次FullGC；
- FullGC：STW，然后采用线程进行标记、清理、压缩整理，空出Region来供下一次MixedGC使用，该过程非常耗时。(Shenandoah优化成多线程收集了)。
为什么G1能保证-XX:MaxGCPauseMills配置的最大停顿时间？
G1垃圾回收器在垃圾遍历的时候就会计算对应回收需要的时间，当接近所配置的时间时就去进行部分收集，远小于则会继续遍历更多的垃圾来回收。
G1从整体来看是基于标记整理算法实现的收集器，但从局部上看又是基于标记复制算法实现。最终这两种算法都意味着G1运作期间不会产生内存空间碎片，垃圾收集完成之后能提供规整的可用内存。
8、ZGC(Zero paused GC)
STW时间能降低到10ms内(比拟C++回收效率)，JDK11可以使用。ZGC
- ZGC利用对象指针处理，和以往堆内存空间的处理思想不一样；
- ZGC不支持32位的指针，不支持指针压缩；
- 64位的地址指针，ZGC使用44位来描述地址，可达到16T的内存空间地址寻找；
- 指针其余位用于Colored Pointer + Load Barrier，Load Barrier根据指针颜色来做不同的事情。
什么是颜色指针？什么是mmap？不同指针间是怎么映射到同一个位置上的？什么是重定位？什么是转发表？什么是线程自愈？
9、shenandoan
实验状态。
10、Eplison
实验状态。
五、三色标记算法
对象标记使用的是三色标记算法，将对象标记状态分为三种颜色，每次寻找都是基于上一次标记状态的结果来进行下一步遍历。
三种状态：
- 白色：对象还未被标记的节点，需要完全遍历寻找；可达性分析开始阶段所有对象都是白色，在可达性分析结束后，仍是白色对象的节点代表不可达。
- 灰色：对象已经标记的节点，但至少存在一个以上fields节点没有标记，会遍历其fields寻找；
- 黑色：对象已经标记的节点，且其fields节点(所有引用)都标记完成。代表已经扫描，安全存活状态，如有其他对象引用黑色状态对象，则无需再遍历一遍；黑色对象不可能不经过灰色对象直接指向白色对象；
颜色状态的存储：CMS垃圾回收器是在对象头部的Mark Word拿出两个二进制位来存储对象的标记颜色。
1、CMS三色标记的问题：
问题1：多标 - 浮动垃圾Floating Garbage
并发标记阶段，用户线程和垃圾线程并行运行。
1、当前垃圾线程标记及引用链的状态：GCRoot -> A(黑) -> B(黑)
2、线程切换导致垃圾线程停止，用户线程运行，将A(黑) -> B(黑)引用去掉。则会导致B成为浮动垃圾。
- 另外并发标记/并发清除阶段，开始后产生的新对象，通常的做法是直接当为黑色对象，本轮也不会当为垃圾，这段时间就算成为了垃圾，也只能等下一轮 清理。
问题2：漏标 - 误删(已解决)
并发标记阶段，用户线程和垃圾线程并行运行。
1、当前垃圾线程标记及引用链的状态：A(黑) -> B(灰) -> D(白)
2、线程切换导致垃圾线程停止，用户线程运行，正好将B(灰) -> D(白)引用去掉，增加A(黑) ->D(白)引用。
3、垃圾线程再次运行时，A(黑)不会再标记其fields节点，而遍历B(灰)时，D(白)已不是B的fields节点，所以则会导致D(白)的漏标。可能会被误删。
CMS解决方案：Incremental Update。
增量更新指当黑色对象新增引用为白色的对象时，会将这个引用记录下来，等并发标记结束后，再将这些引用关系的黑色对象作为根重新扫描一次。也可简单理解为JVM通过写屏障，在A.xField = D的时候，如果A是黑色，D是白色，则将A置为灰色，这样垃圾线程再次遍历会重写标记A的fields节点。
问题3：但是CMS的Incremental Update解决方案依然存在漏标。
1、当前垃圾线程标记及引用链的状态：A(灰) -> B(白) -> D(白)，且垃圾线程1已扫描完A对象的field1属性。
2、线程切换导致垃圾线程停止，用户线程运行，正好将B(白) -> D(白)引用去掉，增加A.field1 ->D(白)引用。
3、垃圾线程1再次运行时，A.field1不会再标记其fields节点的D，当扫描完A.field2和B时会变为黑，已完成标记，则会导致D的漏标。
所以CMS在remark阶段，必须从GCRoot对已标记树再扫描一遍。
2、G1的三色标记：
G1实现三色标记算法的方案是SATB(Snapshot At The Begining，原始快照)。
如有引用A(黑) -> B(灰) -> D(白)引用链，在B -> D引用消失的时候，将B->D的引用推到堆栈中记录，并发标记结束后，然后从堆栈中取出该引用(即指向的D对象)来扫描，来看D对象是否还被引用。避免本次误删。再加上G1的分区的Remember Set设计，可以找到当前分区对象被其他哪些分区所引用。
3、写屏障
