JVM垃圾回收

简单回顾

关于垃圾回收算法，基本就是那么几种：

• 标记-清除
• 标记-复制
• 标记-整理
• 分代：新生代/老年代，每代采取不同的回收算法，以提高整体的分配和回收效率。
• 分区：把连续的Java堆划分为多个大小相等的独立区域（Region），每一个Region都可以根据需要，扮演新生代的Eden空间、Survivor空间，或者老年代空间。收集器能够对扮演不同角色的Region采用不同的策略去处理

无论使用哪种算法，标记总是必要的一步。这是理算当然的，你不先找到垃圾，怎么进行回收？

垃圾回收器的工作流程大体如下：

1. 标记出哪些对象是存活的，哪些是垃圾（可回收）；
2. 进行回收（清除/复制/整理），如果有移动过对象（复制/整理），还需要更新引用。
   接下来着重来看下标记的部分。

如何确定垃圾

引用计数法

在 Java 中，引用和对象是有关联的。如果要操作对象则必须用引用进行。因此，很显然一个简单的办法是通过引用计数来判断一个对象是否可以回收。简单说，即一个对象如果没有任何与之关联的引用，即他们的引用计数都不为 0，则说明对象不太可能再被用到，那么这个对象就是可回收对象。

可达性分析

为了解决引用计数法的循环引用问题，Java 使用了可达性分析的方法。通过一系列的“GC roots”对象作为起点搜索。如果在“GC roots”和一个对象之间没有可达路径，则称该对象是不可达的。

GC roots

第一种是 虚拟机栈中的引用的对象 。在程序中正常创建一个对象，对象会在堆上开辟一块空间，同时会将这块空间的地址作为引用保存到虚拟机栈中，如果对象生命周期结束了，那么引用就会从虚拟机栈中出栈，因此如果在虚拟机栈中有引用，就说明这个对象还是有用的，这种情况是最常见的。
第二种是我们 在类中定义了全局的静态的对象 ，也就是使用了 static 关键字，由于虚拟机栈是线程私有的，所以这种对象的引用会保存在共有的方法区中，显然将方法区中的静态引用作为 GC Roots 是必须的。
第三种便是 常量引用 ，就是使用了 static final 关键字，由于这种引用初始化之后不会修改，所以方法区常量池里的引用的对象也应该作为 GC Roots。
第四种是在 使用 JNI 技术时，有时候单纯的 Java 代码并不能满足我们的需求，我们可能需要在 Java 中调用 C 或 C++的代码，因此会使用 Native 方法，JVM 内存中专门有一块本地方法栈，用来保存这些对象的引用，所以本地方法栈中引用的对象也会被作为 GC Roots。

注：不可达对象不等价于可回收对象，不可达对象变为可回收对象至少要经过两次标记过程。两次标记后仍然是可回收对象，则将面临回收。

第一次标记

如果对象在进行可达性分析后发现没有与GC Roots相连接的引用链，那它将会被第一次标记。

第二次标记

经过第一次标记后的对象，根据 此对象是否有必要执行finalize()方法 进行筛选，随后会由收集器对F-Queue中的对象进行第二次小规模的标记。具体如下：

• 经过第一次标记后的对象，根据 此对象是否有必要执行finalize()方法 进行筛选。被判定为确实有必要执行finalize()方法的对象将会被放置在一个名为F-Queue的队列之中。
• 假如对象没有覆盖finalize()方法，或者finalize()方法已经被虚拟机调用过，那么虚拟机将这两种情况都视为“没有必要执行”。
• 稍后会由一条由虚拟机自动建立的、低调度优先级的 Finalizer线程 去执行F-Queue中对象的finalize()方法。
• finalize()方法是对象逃脱死亡命运的最后一次机会，稍后收集器将对F-Queue中的对象进行 第二次小规模的标记。如果对象在finalize()中成功拯救自己——只要重新与引用链上的任何一个对象建立关联即可，那在第二次标记时它将被移出 “即将回收” 的集合；如果对象这时候还没有逃脱，那基本上它就真的要被回收了。
• 这种自救的机会只有一次，因为对象的finalize()方法最多只会被系统调用一次。

JVM中的CMS、G1垃圾回收器所使用垃圾回收标记算法即为三色标记法。

三色标记法

三色标记算法思想

三色标记法将对象的颜色分为了黑、灰、白，三种颜色。
白色：该对象没有被标记过。（对象垃圾）
灰色：该对象已经被标记过了，但该对象下的属性没有全被标记完。（GC需要从此对象中去寻找垃圾）
黑色：该对象已经被标记过了，且该对象下的属性也全部都被标记过了。（程序所需要的对象）

假设现在有白、灰、黑三个集合（表示当前对象的颜色,算法思想具体实现方式不同），其遍历访问过程为：
1 初始时，所有对象都在 【白色集合】中；
2 将GC Roots 直接引用到的对象 挪到 【灰色集合】中；
3 从灰色集合中获取对象：
3.1. 将本对象 引用到的 其他对象 全部挪到 【灰色集合】中；
3.2. 将本对象 挪到 【黑色集合】里面。
重复步骤3，直至【灰色集合】为空时结束。
结束后，仍在【白色集合】的对象即为GC Roots 不可达，可以进行回收。
注：如果标记结束后对象仍为白色，意味着已经“找不到”该对象在哪了，不可能会再被重新引用。

当Stop The World （以下简称 STW）时，对象间的引用 是不会发生变化的，可以轻松完成标记。
而当需要支持并发标记时，即标记期间应用线程还在继续跑，对象间的引用可能发生变化，多标和漏标的情况就有可能发生。

多标

并发标记的过程中，若一个已经被标记成黑色或者灰色的对象，突然变成了垃圾，由于不会再对黑色标记过的对象重新扫描,所以不会被发现，那么这个对象不是白色的但是不会被清除，重新标记也不能从GC Root中去找到，所以成为了浮动垃圾，浮动垃圾对系统的影响不大，留给下一次GC进行处理即可。

漏标

并发标记的过程中，一个业务线程将一个未被扫描过的白色对象断开引用成为垃圾（删除引用），同时黑色对象引用了该对象（增加引用）（这两部可以不分先后顺序）；因为黑色对象的含义为其属性都已经被标记过了，重新标记也不会从黑色对象中去找，导致该对象被程序所需要，却又要被GC回收，此问题会导致系统出现问题。

不难分析，漏标只有同时满足以下两个条件时才会发生：
条件一：灰色对象 断开了 白色对象的引用（直接或间接的引用）；即灰色对象 原来成员变量的引用 发生了变化。
条件二：黑色对象 重新引用了 该白色对象；即黑色对象 成员变量增加了 新的引用。

而CMS与G1，两种回收器在使用三色标记法时，都采取了一些措施来应对这些问题，CMS对增加引用环节进行处理（Increment Update），G1则对删除引用环节进行处理(SATB)。

CMS 之 Increment Update

CMS 收集过程

[GC [1 CMS-initial-mark: 13991K(20288K)] 14103K(22400K), 0.0023781 secs]
[GC [DefNew: 2112K->64K(2112K), 0.0837052 secs] 16103K->15476K(22400K), 0.0838519 secs]
...
[GC [DefNew: 2077K->63K(2112K), 0.0126205 secs] 17552K->15855K(22400K), 0.0127482 secs]
[CMS-concurrent-mark: 0.267/0.374 secs]
[GC [DefNew: 2111K->64K(2112K), 0.0190851 secs] 17903K->16154K(22400K), 0.0191903 secs]
[CMS-concurrent-preclean: 0.044/0.064 secs]
[GC [1 CMS-remark: 16090K(20288K)] 17242K(22400K), 0.0210460 secs]
[GC [DefNew: 2112K->63K(2112K), 0.0716116 secs] 18177K->17382K(22400K), 0.0718204 secs]
[GC [DefNew: 2111K->63K(2112K), 0.0830392 secs] 19363K->18757K(22400K), 0.0832943 secs]
...
[GC [DefNew: 2111K->0K(2112K), 0.0035190 secs] 17527K->15479K(22400K), 0.0036052 secs]
[CMS-concurrent-sweep: 0.291/0.662 secs]
[GC [DefNew: 2048K->0K(2112K), 0.0013347 secs] 17527K->15479K(27912K), 0.0014231 secs]
[CMS-concurrent-reset: 0.016/0.016 secs]
[GC [DefNew: 2048K->1K(2112K), 0.0013936 secs] 17527K->15479K(27912K), 0.0014814 secs
]

1）初始标记（CMS initial mark）
2）并发标记（CMS concurrent mark）
Concurrent Preclean（并发预清理）
3）重新标记（CMS remark）
4）并发清除（CMS concurrent sweep）
Concurrent Reset（并发重置）

其中初始标记、重新标记这两个步骤仍然需要“Stop The World”。

• 初始标记仅仅只是标记一下GCRoots能直接关联到的对象，速度很快；
• 并发标记阶段就是从GC Roots的直接关联对象开始遍历整个对象图的过程，这个过程耗时较长但是不需要停顿用户线程，可以与垃圾收集线程一起并发运行；
• 重新标记阶段则是为了修正并发标记期间，因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间通常会比初始标记阶段稍长一些，但也远比并发标记阶段的时间短；
• 并发清除阶段，清理删除掉标记阶段判断的已经死亡的对象，由于不需要移动存活对象，所以这个阶段也是可以与用户线程同时并发的。

由于在整个过程中耗时最长的并发标记和并发清除阶段中，垃圾收集器线程都可以与用户线程一起工作，降低了应用停顿时间。

写屏障

针对新增的引用，利用写屏障（update_barrier_set）将其记录下来等待遍历，即增量更新（Incremental Update）实现漏标处理。

翻译：当使用CMS时，我们必须使用release语义将对应于p的card table标记为dirty，以防止CMS看到脏卡，而p指向的不是新的vlaue v，因为这两个存储可能会重新排序，引发可见性问题。注意，cms有一个并发的预清理阶段，当java线程运行时，它读取card table，并标记被Dirty对象直接或间接引用的对象，然后清除Card标识。

CMS 收集过程值得注意的是，除了预清理阶段需要遍历写屏障的Dirty card 中的记录 ，在重新标记阶段，还需要重新扫描遍历GC Roots（当然标记过的无需再遍历了），这是由于CMS对于astore_x等指令不添加写屏障的原因。

G1 之 SATB

G1 收集

G1 特点在于可控的停顿时间，可以用来取代 CMS 收集器，和 CMS 相同的地方在于，它们都属于并发收集器，在大部分的收集阶段都不需要挂起应用程序。区别在于，G1 没有 CMS 的碎片化问题（或者说不那么严重），同时提供了更加可控的停顿时间。如果你的应用使用了较大的堆（如 6GB 及以上）而且还要求有较低的垃圾收集停顿时间（如 0.5 秒），那么 G1 是你绝佳的选择，是时候放弃 CMS 了。

G1(Garbage First)物理内存不再分代，而是由一块一块的Region组成,但是逻辑分代仍然存在。G1不再坚持固定大小以及固定数量的分代区域划分，而是把连续的Java堆划分为多个大小相等的独立区域（Region），每一个Region都可以根据需要，扮演新生代的Eden空间、Survivor空间，或者老年代空间。Region中还有一类特殊的Humongous区域，专门用来存储大对象。G1认为只要大小超过了一个Region容量一半的对象即可判定为大对象。

Card Table（多种垃圾回收器均具备）

1. 辅助YoungGC
   由于在进行YoungGC时，我们在进行对一个对象是否被引用的过程，需要扫描整个Old区，所以JVM设计了CardTable，将Old区分为一个一个Card，一个Card有多个对象；如果一个Card中的对象有引用指向Young区，则将其标记为Dirty Card，下次需要进行YoungGC时，只需要去扫描Dirty Card即可，无需遍历整个Old区。

2. 辅助CMS三色标记 Incremental Update
   CMS 并发标记阶段

• 新生代的对象晋升到老年代；
• 直接在老年代分配对象；
• 老年代对象的引用关系发生变更；
  为了提高重新标记的效率，本阶段会把这些发生变化的对象所在的Card标识为Dirty，这样后续就只需要扫描这些Dirty Card的对象，从而避免扫描整个老年代。

RSet(Remembered Set)

是辅助GC过程的一种结构，典型的空间换时间工具，和Card Table有些类似。
后面说到的CSet(Collection Set)也是辅助GC的，它记录了GC要收集的Region集合，集合里的Region可以是任意年代的。
在GC的时候，对于old->young和old->old的跨代对象引用，只要扫描对应的CSet中的RSet即可。 逻辑上说每个Region都有一个RSet，RSet记录了其他Region中的对象引用本Region中对象的关系，属于points-into结构（谁引用了我的对象）。
而Card Table则是一种points-out（我引用了谁的对象）的结构，每个Card 覆盖一定范围的Heap（一般为512Bytes）。G1的RSet是在Card Table的基础上实现的：每个Region会记录下别的Region有指向自己的指针，并标记这些指针分别在哪些Card的范围内。 这个RSet其实是一个Hash Table，Key是别的Region的起始地址，Value是一个集合，里面的元素是Card Table的Index。每个Region中都有一个RSet，记录其他Region到本Region的引用信息；使得垃圾回收器不需要扫描整个堆找到谁引用当前分区中的对象，只需要扫描RSet即可。

CSet(Collection Set)

一组可被回收的分区Region的集合, 是多个对象的集合内存区域。

youngGC

年轻代收集概念上和其他分代收集器大差不差的，但是它的年轻代会动态调整，进行扩容或缩容

Old GC 之 并发标记周期

标记周期包括以下阶段：
Initial marking phase：G1收集器扫描所有的根。该过程是和young GC的暂停过程一起的；
Root region scanning phase：扫描Survivor Regions中指向老年代的被initial mark phase标记的引用及引用的对象，这一个过程是并发进行的。但是该过程要在下一个young GC开始之前结束；
Concurrent marking phase：并发标记阶段，标记整个堆的存活对象。该过程可以被young GC所打断。并发阶段产生的新的引用（或者引用的更新）会被SATB的write barrier记录下来；
Remark phase：也叫final marking phase。该阶段只需要扫描SATB(Snapshot At The Beginning)的buffer，处理在并发阶段产生的新的存活对象的引用。作为对比，CMS的remark需要扫描整个mod union table的标记为dirty的entry以及全部根；
Cleanup phase：清理阶段。该阶段会计算每一个region里面存活的对象，并把完全没有存活对象的Region直接放到空闲列表中。在该阶段还会重置Remember Set。该阶段在计算Region中存活对象的时候，是STW(Stop-the-world)的，而在重置Remember Set的时候，却是可以并行的；

SATB(Snapshot At The Beginning),

在应对漏标问题时，G1使用了SATB方法来做,具体流程：

• 在开始标记的时候生成一个快照图标记存活对象
• 在一个引用断开后，要将此引用推到GC的堆栈里，保证白色对象（垃圾）还能被GC线程扫描到(在write barrier写屏障（update_barrier_set_pre）里把所有旧的引用所指向的对象都变成非白的)。
• 配合Rset，去扫描哪些Region引用到当前的白色对象，若没有引用到当前对象，则回收
  
  SATB效率高于增量更新的原因？
  因为SATB在重新标记环节只需要去重新扫描那些被推到堆栈中的引用，并配合Rset来判断当前对象是否被引用来进行回收；
  并且在最后G1并不会选择回收所有垃圾对象，而是根据Region的垃圾多少来判断与预估回收价值（指回收的垃圾与回收的STW时间的一个预估值），将一个或者多个Region放到CSet中，最后将这些Region中的存活对象压缩并复制到新的Region中，清空原来的Region。

G1会不会进行Full GC?
会，当内存满了的时候就会进行Full GC；且JDK10之前的Full GC，为单线程的，所以使用G1需要避免Full GC的产生。

解决方案：

• 加大内存；
• 提高CPU性能，加快GC回收速度，而对象增加速度赶不上回收速度，则Full GC可以避免；
• 降低进行Mixed GC触发的阈值，让Mixed GC提早发生（默认45%）