1. 对象“已死”？

垃圾收集器在对堆进行回收之前，第一件事情就是要确定哪些对象是‘活着’的哪些是已经‘死去’的。

1.1 引用计数法

简单理解就是，在对象中添加一个引用计数器，当一个地方引用到它时，计数器就 +1，当引用失效时，计数器就 -1，任何时刻，当计数器的值为0时，对象就是不在被使用的状态了。

客观的说，该方法原理简单，判定效率高效，在大多数情况下，是一种不错的选择。但是，这个算法也有很多例外的情况要考虑，必须配合大量额外的处理才能正常工作。譬如，单纯的计数器就很难解决对象之间的相互循环依赖的问题。

所以，主流的java虚拟机并没有选择该算法进行内存管理。

1.2 可达性分析算法

该算法的原理是，选择一些称为“GC Roots”的根对象为起始节点集，随后沿着引用关系向下搜索，搜索过程中走过的路径称为“引用链”，如果一个对象到GC Roots间没有任何引用链相连，则该对象是不可使用（不可达）的。

在Java技术体系里，可称为GC Roots 的对象包括一下几类：

• 在虚拟机栈(栈帧中的本地变量表)中引用的对象，如各个线程被调用的方法堆
  栈中使用到的参数、局部变量、临时变量等。
• 在方法区中类静态属性引用的对象，譬如Java类的引用类型静态变量。
• 在方法区中常量引用的对象，譬如字符串常量池(StringTable)里的引用。
• 在本地方法栈中JNI(即通常所说的Native方法)引用的对象。
• Java虚拟机内部的引用，如基本数据类型对应的Class对象，一些常驻的异常对象
  (比如 NullPointExcepiton、OutOfMemoryError)等，还有系统类加载器。
• 所有被同步锁(synchronized 关键字)持有的对象。
• 反映 Java 虚拟机内部情况的 JMXBean、JVMTI 中注册的回调、本地代码缓存等。

2. 垃圾收集算法

从如何判定对象消亡的角度出发，垃圾收集算法可以划分为“引用计数式垃圾收集
和“追踪式垃圾收集”两大类，这两类也常被称作“直接垃圾收集”和“间接垃圾收集”。由于引用计数式垃圾收集算法在主流Java虚拟机中均未涉及，所以这里介绍的所有算法均属于追踪式垃圾收集的范畴。

2.1 标记-清除算法

最早出现也是最基础的垃圾收集算法是“标记-清除”(Mark-Sweep)算法，在1960年由 Lisp 之父 John McCarthy 所提出。如它的名字一样，算法分为“标记”和“清除”两个阶段:首先标记出所有需要回收的对象，在标记完成后，统一回收掉所有被标记的对象也可以反过来，标记存活的对象。统一回收所有未被标记的对象。标记过程就是对象是否属于垃圾的判定过程。
它的主要缺点有两个:

• 第一个是执行效率不稳定，如果Java堆中包含大量对象，而且其中大部分是需要被回收的，这时必须进行大量标记和清除的动作，导致标记和清除两个过程的执行效率都随对象数量增长而降低;
• 第二个是内存空间的碎片化问题，标记、清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致当以后在程序运行过程中需要分配较大对象时无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。

2.2 标记-复制算法

为了解决标记-清除算法面对大量可回收对象时执行效率低的问题，1969年Fenichel提出了一种称为“半区复制”(Semispace Copying)的垃圾收集算法。

原理是：它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。

如果内存中多数对象都是存活的，这种算法将会产生大量的内存间复制的开销，但对于多数对象都是可回收的情况，算法需要复制的就是占少数的存活对象而且每次都是针对整个半区进行内存回收，分配内存时也就不用考虑有空间碎片的复杂情况，只要移动堆顶指针，按顺序分配即可。这样实现简单，运行高效，不过其缺陷也显而易见，这种复制回收算法的代价是将可用内存缩小为了原来的一半。

现在大部分的商用java虚拟机都优先采用了该算法去回收新生代。

2.3 标记-整理算法

1974年EdwardLueders提出了“标记-整理”( Mark-Compact)算法，其中的标记过程仍然与“标记-清除”算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向内存空间一端移动，然后直接清理掉边界以外的内存。
标记-清除算法与标记-整理算法的本质差异在于前者是一种非移动式的回收算法。而后者是移动式的。是否移动回收后的存活对象是一项优缺点并存的风险决策:

如果移动存活对象，尤其是在老年代这种每次回收都有大量对象存活区域，移动存活对象并更新所有引用这些对象的地方将会是一种极为负重的操作，而且这种对象移动操作必须全程暂停用户应用程序才能进行，这就更加让使用者不得不小心翼翼地权衡其弊端了，像这样的停顿被最初的虚拟机设计者形象地描述为“Stop The World”。

但如果跟标记-清除算法那样完全不考虑移动和整理存活对象的话，弥散于堆中的存活对象导致的空间碎片化问题就只能依赖更为复杂的内存分配器和内存访问器来解决。如通过“分区空闲分配链表”来解决内存分配问题(计算机硬盘存储大文件就不要求物理连续的磁盘空间，能够在碎片化的硬盘上存储和访问就是通过硬盘分区表实现的)。内存的访问是用户程序最频繁的操作，甚至都没有之一，假如在这个环节上增加了额外的负担，势必会直接影响应用程序的吞吐量。

基于以上两点，是否移动对象都存在弊端，移动则内存回收时会更复杂，不移动则内存分配时会更复杂。从垃圾收集的停顿时间来看，不移动对象停顿时间会更短，甚至可以不需要停顿，但是从整个程序的吞吐量来看，移动对象会更划算。即使不移动对象会使得收集器的效率提升一些，但因内存分配和访问相比垃圾收集频率要高得多，这部分的耗时增加总吞吐量仍然是下降的。

还有一种‘中和’的方式，就是平时使用标记-清除算法，暂时容忍内存碎片的存在，当无法在分配对象时，在采用标记-整理算法收集一次，以获得规整的内存空间。

3. 垃圾收集器

3.1 Serial 收集器（新生代）

Serial 收集器是最基础，历史最悠久的收集器。这个收集器是一个单线程工作的收集器，但它的“单线程”的意义并不仅仅是说明它只会使用一个处理器或一条收集线程去完成垃圾收集工作，更重要的是强调在它进行垃圾收集时，必须暂停其他所有工作线程，直到它收集结束。

“Stop The World”这个词语也许听起来很酷，但这项工作是由虚拟机在后台自动发起和自动完成的，在用户不可知、不可控的情况下把用户的正常工作的线程全部停掉，这对很多应用来说都是不能接受的。

3.2 ParNew 收集器（新生代）

ParNew收集器实质上是Serial收集器的多线程并行版本，除了同时使用多条线程进行垃圾收集之外，其余的行为包括Serial收集器可用的所有控制参数(例如:-XXSurvivorRatio、-XX:PretenureSizeThreshold、-XX:HandlePromotionFailure等)、收集算法Stop The World、对象分配规则、回收策略等都与Serial收集器完全一致。

3.3 Parallel Scavenge 收集器（新生代）

Parallel Scavenge 收集器也是一款新生代收集器，它同样是基于标记-复制算法实现的收集器，也是能够并行收集的多线程收集器……Parallel Scavenge的诸多特性从表面上看和ParNew非常相似，那它有什么特别之处呢?

Parallel Scavenge 收集器的特点是它的关注点与其他收集器不同，CMS等收集器的关注点是尽可能地缩短垃圾收集时用户线程的停顿时间，而Parallel Scavenge收集器的目标则是达到一个可控制的吞吐量(Throughput)。所谓吞吐量就是处理器用于运行用户代码的时间与处理器总消耗时间的比值，即:
吞吐量= 运行用户代码时间 / （运行用户代码时间+运行垃圾收集时间）
如果虚拟机完成某个任务，用户代码加上垃圾收集总共耗费了100分钟，其中垃圾收集
花掉1分钟，那吞吐量就是99%。

停顿时间越短就越适合需要与用户交互或需要保证服务响应质量的程序，良好的响应速度能提升用户体验；

高吞吐量则可以最高效率地利用处理器资源，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的分析任务。

Parallel Scavenge 收集器提供了两个参数用于精确控制吞吐量

• 控制最大垃圾收集停顿时间的 -XX:MaxGCPauseMillis ，允许的值是一个大于0的毫秒数，收集器将尽力保证内存回收花费的时间不超过用户设定值。

  垃圾收集停顿时间缩短是以牺牲吞吐量和新生代空间为代价换取的：系统把新生代调得小一些，收集300MB新生代肯定比收集500MB 快，但这也直接导致垃圾收集发生得更频繁，原来10秒收集一次、每次停顿100毫秒，现在变成5秒收集一次、每次停顿 70毫秒。停顿时间的确在下降，但吞吐量也降下来了

• 直接设置吞吐量大小的 -XX:GCTimeRatio 参数，值则应当是一个大于0小于100的整数，也就是垃圾收集时间占总时间的比率，相当于吞吐量的倒数。譬如把此参数设置为19，那允许的最大垃圾收集时间就占总时间的 5%(即 1/(1+19))，默认值为 99，即允许最大1%(即 1/(1+99))的垃圾收集时间

由于与吞吐量关系密切，Parallel Scavenge收集器也经常被称作“吞吐量优先收集器”

3.4 Serial Old 收集器（老年代）

Serial Old是Serial收集器的老年代版本，它同样是一个单线程收集器，使用标记-整理算法。这个收集器的主要意义也是供客户端模式下的HotSpot虚拟机使用。如果在服务端模式下，它也可能有两种用途：一种是在JDK5以及之前的版本中与Parallel Scavenge 收集器搭配使用，另外一种就是作为CMS收集器发生失败时的后备预案，在并发收集发生Concurrent Mode Failure 时使用。

3.5 Parallel Old 收集器（老年代）

Parallel Old是Parallel Scavenge收集器的老年代版本，支持多线程并发收集，基于标记-整理算法实现。

在注重吞吐量或者处理器资源较为稀缺的场合，都可以优先考虑Parallel Scavenge 加Parallel Old 收集器这个组合。

3.6 CMS 收集器（老年代）

CMS(Coneurrent Mark Sweep)收集器是一种以获取最短回收停顿时间为目标的收集器，目前很大一部分的Java应用集中在互联网网站或者基于浏览器的 B/S系统的服务端上。这类应用通常都会较为关注服务的响应速度，希望系统停顿时间尽可能短，以给用户带来自好的交互体验。CMS收集器就非常符合这类应用的需求。

从名字(包含“Mark Sweep”)上就可以看出CMS收集器是基于标记-清除算法实现的，它的运作过程相对于前面几种收集器来说要更复杂一些，整个过程分为四个步骤包括：

1. 初始标记(CMS initial mark，STW)
2. 并发标记(CMS concurrent mark)
3. 重新标记(CMS remark，STW)
4. 并发清除(CMS concurrent sweep)

初始标记仅仅只是标记一下 GC Roots 能直接关联到的对象，速度很快。

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

而重新标记阶段则是为了修正并发标记期间，因用户序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间通常会比初始标记阶段稍长一些，但也远比并发标记阶段的时间短。

最后是并发清除阶段，清理掉标记阶段判断的已经死亡的对象，由于不需移动存活对象，所以这个阶段也是可以与用户线程同时并发的。

三大缺点：

1. 首先，CMS收集器对处理器资源非常敏感。事实上，在并发阶段，它虽然不会导致用户线程停顿，但却会因为占用了一部分线程(或者说处理器的计算能力)而导致应用程序变慢，降低总吞吐量。

   CMS默认启动的回收线程数是(处理器核心数量+3)/4，也就是说，如果处理器核心数在四个或以上，并发回收时垃圾收集线程只占用不超过25%的处理器运算资源，并且会随着处理器核心数量的增加而下降。但是当处理器核心数量不足四个时，CMS对用户程序的影响就可能变得很大。如果应用本来的处理器负载就很高，还要分出一半的运算能力去执行收集器线程，就可能导致用户程序的执行速度忽然大幅降低。

2. 由于CMS 收集器无法处理“浮动垃圾”，有可能出现“Concurrent Mode Failure”失败进而导致另一次完全“Stop The World”的 Full GC的产生。

   ​ 在CMS的并发标记和并发清理阶段，用户线程是还在继续运行的，程序在运行自然就还会伴随有新的垃圾对象不断产生，但这一部分垃圾对象是出现在标记过程结束以后CMS无法在当次收集中处理掉它们，只好留待下一次垃圾收集时再清理掉。这一部分垃圾就称为“浮动垃圾”。

   ​ 同样也是由于在垃圾收集阶段用户线程还需要持续运行，那就还需要预留足够内存空间提供给用户线程使用，因此CMS收集器不能像其他收集器那样等待到老年代几乎完全被填满了再进行收集，必须预留一部分空间供并发收集时的程序运作使用。

   ​ 在JDK5的默认设置下，CMS收集器当老年代使用了68%的空间后就会被激活，这是一个偏保守的设置，如果在实际应用中老年代增长并不是太快，可以适当调高参数 -XX:CMSInitiatingOccu-pancyFraction的值来提高CMS的触发百分比，降低内存回收比率，获取更好的性能。

   ​ 到了JDK6时，CMS收集器的启动值就已经默认提升至92%但这又会更容易面临另一种风险：要是CMS运行期间预留的内存无法满足程序分配新对象的需要，就会出现一次“并发失败”(Concurrent Mode Failure)，这时候虚拟机将不得不启动后备预案：冻结用户线程的执行，临时启用SerialOld收集器来重新进行老年代的垃圾收集，但这样停顿时间就很长了。所以参数-XX:CMSInitiatingOccupaneyFraction 设置得太高将会很容易导致大量的并发失败产生，性能反而降低，用户应在生产环境中根据实际用情况来权衡设置。

3. ​ CMS是一款基于“标记-清除”算法实现的收集器，这意味着收集结束时会有大量空间碎片产生。空间碎片过多时，将会给大对象分配带来很大麻烦，往往会出现老年代还有很多剩余空间，但就是无法找到足够大的连续空间来分配当前对象，而不得不提前触发一次 Full GC 的情况。

   ​ 为了解决这个问题，CMS 收集器提供了一个-XX:+UseCMSCompactAtFullCollection开关参数(默认是开启的，此参数从JDK9开始废弃)，用于在CMS 收集器不得不进行Full GC 时开启内存碎片的合并整理过程，由于这个内存整理必须移动存活对象，(在Shenandoah和ZGC出现前)是无法并发的。这样空间碎片问题是解决了但停顿时间又会变长，因此虚拟机设计者们还提供了另外一个参数-XX:CMSFullGCsBeforeCompaction(此参数从JDK9开始废弃)，这个参数的作用是要求CMS收集器在执行过若干次(数量由参数值决定)不整理空间的Full GC之后，下一次进入Full GC前会先进行碎片整理(默认值为0，表示每次进人Full GC时都进行碎片整理)。

3.7 Garbage First 收集器

Garbage First(简称G1)收集器是垃圾收集器技术发展历史上的里程碑式的成果，它开创了收集器面向局部收集的设计思路和基于Region的内存布局形式。可以由用户指定期望的停顿时间是G1收集器很强大的一个功能。G1是一款主要面向服务端应用的垃圾收集器。JDK9发布之日，G1成为服务端模式下的默认垃圾收集器。

G1可以面向堆内存任何部分来组成回收集(CollectionSet，一般简称CSet)进行回收、衡量标准不再是它属于哪个分代，而是哪块内存中存放的垃圾数量最多，回收收益最大，这就是G1收集器的 Mixed GC 模式。
G1是基于Region的堆内存布局的。虽然G1也仍是遵循分代收集理论设计的，但其堆内存的布局与其他收集器有非常明显的差异：G1不再坚持固定大小以及固定数量的分代区域划分，而是把连续的Java堆划分为多个大小相等的独立区域(Region)，每一个Region都可以根据需要，扮演新生代的Eden空间、Survivor空间或者老年代空间。收集器能够对扮演不同角色的Region采用不同的策略去处理，这样无论是新创建的对象还是已经存活了一段时间、熬过多次收集的旧对象都能获取很好的收集效果。Region中还有一类特殊的Humongous区域，专门用来存储大对象。G1认为只要大小超过了一个 Region 容量一半的对象即可判定为大对象。每个Region 的大小可以通过参数-XX:G1HeapRegionSize设定，取值范围为IMB~32MB，且应为2的N次幕。而对于那些超过了整个Region容量的超级大对象，将会被存放在N个连续的Humongous Region之中。G1的大多数行为都把 Humongous Region作为老年代的一部分来进行看待。

虽然G1仍然保留新生代和老年代的概念，但新生代和老年代不再是固定的了、它们都是一系列区域(不需要连续)的动态集合。G1收集器将Region作为单次回收的最小单元，即每次收集到的内存空同都是Region大小的整数倍，这样可以有计划地避免在整个Java堆中进行全区域的垃圾收集。更具体的处理思路是计G1收集器去跟踪各个Region里面的垃圾堆积的“价值”大小，价值即回收所获得的空间大小以及回收所需时间的经验值，然后在后台维护一个优先级列表，每次根据用户设定允许的收集停顿时间，优先处理回收价值收益最大的那些Region，这也就是“Garbage First”名字的由来。这使用Region划分内存空间、以及具有优先级的区域回收方式，保证了G1收集器在有限时间内获取尽可能高的收集效率。

收集停顿时间，可使用参数-xX:MaxGCPauseMilis指定，默认值是200毫秒。

运行原理大致可分为四部分：

1. 初始标记(Initial Marking)：仅仅只是标记一下GC Roots能直接关联到的对象并且修改TAMS指针的值，让下一阶段用户线程并发运行时，能正确地在可用的Region中分配新对象。这个阶段需要停顿线程，但耗时很短，而且是借用进行Minor GC的时候同步完成的，所以G1收集器在这个阶段实际并没有额外的停顿。
2. 并发标记(Concurrent Marking)：从GC Root开始对堆中对象进行可达性分析，递归扫描整个堆里的对象图，找出要回收的对象，这阶段耗时较长，但可与用户程序并发执行。当对象图扫描完成以后，还要重新处理SATB记录下的在并发时有引用变动的对象。
3. 最终标记(Final Marking)：对用户线程做另一个短暂的暂停，用于处理并发阶段结束后仍遗留下来的最后那少量的SATB记录。
4. 筛选回收(Live Date Counting and Evacuation)：负责更新 Region的统计数据,各个Region的回收价值和成本进行排序，根据用户所期望的停顿时间来制定回计划、可以自由选择任意多个Region构成回收集，然后把决定回收的那一部Region的存活对象复制到空的 Region中，再清理掉整个旧Region的全部空间。这里的操作涉及存活对象的移动，是必须暂停用户线程，由多条收集器线程并行。

将Java堆分成多个独立Region后，Region里面存在的跨Region引用对象如何解决?

解决思路：使用记忆集避免全堆作为GC Roots 扫描，但在G1收集器上记忆集的应用其实要复杂很多，它的每个Region 都维护有自己的记忆集，这些记忆集会记录下别的Region指向自己的指针并标记这些指针分别在哪些卡页的范围之内。G1的记忆集在存储结构的本质上是一种哈希表，Key是别的Region的起始地址，Value是一个集合，里面存储的元素是卡表的索引号。这种“双向”的卡表结构(卡表是“我指向谁”，这种结构还记录了“谁指向我”)比原来的卡表实现起来更复杂，同时由于Region数量比传统收集器的分代数量明显要多得多，因此G1收集器要比其他的传统垃圾收集器有着更高的内存占用负担。根据经验，G1至少要耗费大约相当于Java堆容量10%至20%的额外内存来维持收集器工作。

在并发标记阶段如何保证收集线程与用户线程互不干扰地运行?

首先要解决的是用户线程改变对象引用关系时，必须保证其不能打破原本的对象图结构，导致标记结果出现错误，G1收集器则是通过原始快照(SATB)算法来实现的。

此外，垃圾收集对用户线程的影响还体现在回收过程中新创建对象的内存分配上，程序要继续运行就肯定会持续有新对象被创建，G1为每一个Region设计了两个名为TAMS(Top at Mark Start)的指针，把 Region中的一部分空间划分出来用于并发回收过程中的新对象分配，并发回收时新分配的对象地址都必须要在这两个指针位置以上。G1收集器默认在这个地址以上的对象是被隐式标记过的，即默认它们是存活的，不纳人回收范围。如果内存回收的速度赶不上内存分配的速度，G1收集器也要被迫冻结用户线程执行，导致Full GC而产生长时间“Stop The World "。

毫无疑问，可以由用户指定期望的停顿时间是G1收集器很强大的一个功能，设置不同的期望停顿时间，可使得G1在不同应用场景中取得关注吞吐量和关注延迟之间的最佳平衡。

由于G1是要冻结用户线程来复制对象的，这个停顿时间再怎么低也得有个限度。它默认的停顿目标为两百毫秒，一般来说，回收阶段占到几十到一百甚至接近两百毫秒都很正常，但如果我们把停顿时间调得非常低，譬如设置为二十毫秒，很可能出现的结果就是由于停顿目标时间太短导致每次选出来的回收集只占堆内存很小的一部分，收集器收集的速度逐渐跟不上分配器分配的速度，导致垃圾慢慢堆积。很可能一开始收集器还能从空闲的堆内存中获得一些息的时间，但应用运行时间一长就不行了，最终占满堆引发Full GC反而降低性能、所以通常把期望停顿时间设置为一两百毫秒或者两三百毫秒会是比较合理的。

CMS 与 G1的比较

相比CMS，G1的优点有很多，暂且不论可以指定最大停顿时间、分Region的内存布局、按收益动态确定回收集这些创新性设计带来的红利，单从最传统的算法理论上看，G1也更有发展潜力。与CMS的“标记-清除”算法不同，G1从整体来看是基于“标记-整理”算法实现的收集器，但从局部(两个Region之间)上看又是基于“标记-复制”算法实现，无论如何，这两种算法都意味着G1运作期间不会产生内存空间碎片，垃圾收集完成之后能提供规整的可用内存。这种特性有利于程序长时间运行，在程序为大对象分配内存时不容易因无法找到连续内存空间而提前触发下一次收集。

不过，比起CMS，G1的弱项也可以列举出不少。如在用户程序运行过程中，G1无论是为了垃圾收集产生的内存占用还是程序运行时的额外执行负载都要比 CMS 要高。就内存占用来说，虽然G1和CMS都使用卡表来处理跨代指针，但G1的卡表实现更为复杂，而且堆中每个Region，无论扮演的是新生代还是老年代角色，都必须有一份卡表这导致G1的记忆集(和其他内存消耗)可能会占整个堆容量的20%乃至更多的内存空间相比起来CMS的卡表就相当简单，只有唯一一份，而且只需要处理老年代到新生代的引用，反过来则不需要，由于新生代的对象具有朝生夕灭的不稳定性，引用变化频繁，能省下这个区域的维护开销是很划算的。

3.8 Shenandoah 收集器

Shenandoah 和 G1，它们两者有着相似的堆内存布局，在初始标记、并发标记等许多阶段的处理思路上都高度一致，由于Shenandoah加入所带来的一些新特性，也有部分会出现在G1收集器中，譬如在并发失败后作为“逃生门”的Full GC，G1就是由于合并了Shenandoah 的代码才获得多线程 Full GC 的支持。

虽然 Shenandoah 也是使用基于 Region 的堆内存布局，同样有着用于存放大对象的Humongous Region，默认的回收策略也同样是优先处理回收价值最大的Region。但在管理堆内存方面，它与G1至少有三个明显的不同之处：

1. 最重要的当然是支持并发的整理算法，G1的回收阶段是可以多线程并行的，但却不能与用户线程并发。
2. 其次，Shenandoah(目前)是默认不使用分代收集的，换言之，不会有专门的新生代Region或者老年代Region的存在，没有实现分代，并不是说分代对Shenandoah没有价值，这更多是出于性价比的权衡，基于工作量上的考虑而将其放到优先级较低的位置上。
3. 最后Shenandoah摒弃了在G1中耗费大量内存和计算资源去维护的记忆集，改用名为“连接
   矩阵”的全局数据结构来记录跨 Region的引用关系，降低了处理跨代指针时的记忆集维护消耗，也降低了伪共享问题的发生概率。

连接矩阵 可以简单理解为一张二维表格，如果Region N有对象指向Region M，就在表格的N行M列中打上一个标记，在回收时通过这张表格就可以得出哪些 Region 之间产生了跨代引用。

工作流程大致可分为9个阶段：

1. 初始标记(Initial Marking)：与 G1 一样，首先标记与 GC Roots 直接关联的对。这个阶段仍是“ Stop The World”的，但停顿时间与堆大小无关，只与 GC Roots 的数量相关。

2. 并发标记(Concurrent Marking)：与G1一样，遍历对象图，标记出全部可达的对象这个阶段是与用户线程一起并发的，时间长短取决于堆中存活对象的数量以及对象图的结构复杂程度。

3. 最终标记(Final Marking)：与 G1一样，处理剩余的 SATB 扫描，并在这个阶段统计出回收价值最高的Region，将这些Region构成一组回收集(Collection Set)。最终标记阶段也会有一小段短暂的停顿。

4. 并发清理(Concurrent Cleanup)：这个阶段用于清理那些整个区域内连一个存活对象都没有找到的 Region。

5. 并发回收(Concurrent Evacuation)：并发回收阶段是 Shenandoah 与之前 HotSpot 中其他收集器的核心差异。在这个阶段，Shenandoah要把回收集里面的存活对象先复制一份到其他未被使用的Region之中。

   复制对象这件事情如果将用户线程冻结起来再做那是相当简单的，但如果两者必须要同时并发进行的话，就变得复杂起来了其困难点是在移动对象的同时，用户线程仍然可能不停对被移动的对象进行读写访问，移动对象是一次性的行为，但移动之后整个内存中所有指向该对象的引用都还是旧对象的地址，这是很难一瞬间全部改变过来的。对于并发回收阶段遇到的这些困难，Shenandoah将会通过读屏障和被称为“Brooks Pointers”的转发指针来解决。并发回收阶段运行的时间长短取决于回收集的大小。

6. 初始引用更新(Initial Update Reference)：并发回收阶段复制对象结束后，还需要把堆中所有指向旧对象的引用修正到复制后的新地址，这个操作称为引用更新。引用更新的初始化阶段实际上并未做什么具体的处理，设立这个阶段只是为了建立一个线程集合点，确保所有并发回收阶段中进行的收集器线程都已完成分配给它们的象移动任务而已。初始引用更新时间很短，会产生一个非常短暂的停顿。

7. 并发引用更新(ConeurrentUpdateReference)：真正开始进行引用更新操作，这个阶段是与用户线程一起并发的，时间长短取决于内存中涉及的引用数量的多少。并且引用更新与并发标记不同，它不再需要沿着对象图来搜索，只需要按照内存物理址的顺序，线性地搜索出引用类型，把旧值改为新值即可。

8. 最终引用更新(Final Update Reference)：解决了堆中的引用更新后，还要修正存于GC Roots中的引用。这个阶段是Shenandoah的最后一次停顿，停顿时间只与GC Roots 的数量相关。

9. 并发清理(Concurrent Cleanup)：经过并发回收和引用更新之后，整个回收集中所的 Region已再无存活对象，最再调用一次并发清理过程来回收这些Region的内存空间，供以后新对象分配使用。

其中三个最重要的并发阶段是并发标记、并发回收、并发引用更新。

3.9 ZGC 收集器

我们可以给ZGC下这样的定义来概括它的主要特征：ZGC收集器是一款基于Region内存布局的，(暂时)不设分代的，使用了读屏障、染色指针和内存多重映射等技术来实现可并发的‘标记-整理’算法的，以低延迟为首要目标的一款垃圾收集器。

ZGC的运作过程大致可划分为以下四个大的阶段。全部四个阶段都是可以并发执行的，仅是两个阶段中间会存在短暂的停顿小阶段，这些小阶段，譬如初始化GC Root直接关联对象的 Mark Start.与之前 G1和Shenandoah 的 Initial Mark阶段并没有什么差异，笔者就不再单独解释了。

1. 并发标记(Concurrent Mark)：与G1、Shenandoah 一样，并发标记是遍历对象图做。可达性分析的阶段，前后也要经过类似于G1、Shenandoah的初始标记、最终标记(尽管ZGC中的名字不叫这些)的短暂停顿，而且这些停顿阶段所做的事情在目标上也是相类似的。与G1、Shenandoah不同的是，ZGC的标记是在指针上而不是在对象上进行的，标记阶段会更新染色指针中的Marked0、Marked1标志位。
2. 并发预备重分配(Concurrent Prepare for Relocate)：这个阶段需要根据特定的查询条件统计得出本次收集过程要清理哪些Region，将这些Region组成重分配集。重分配集与G1收集器的回收集(Collection Set)还是有区别的。ZGC划分Region的目的并非为了像G1那样做收益优先的增量回收。相反，ZGC每次回收都会扫描所有的Region，用范围更大的扫描成本换取省去G1中记忆集的维护成本。因此，ZGC的重分配集只是决定了里面的存活对象会被重新复制到其他的 Region中，里面的Region会被释放，而并不能说回收行为就只是针对这个集合里面的Region进行，因为标记过程是针对全堆的。此外，在JDK12的ZGC中开始支持的类卸载以及弱引用的处理，也是在这个阶段中完成的。
3. 并发重分配(Concurrent Relocate)：重分配是ZGC执行过程中的核心阶段，这个程要把重分配集中的存活对象复制到新的Region上，并为重分配集中的每个Region维护一个转发表，记录从旧对象到新对象的转向关系。得益于染色指针的支持，ZGC收集器能仅从引用上就明确得知一个对象是否处于重分配集之中，如果用户线程此时并发访问了位于重分配集中的对象，这次访问将会被预置的内存屏障所截获，然后立即根据Region上的转发表记录将访问转发到新复制的对象上，并同时修正更新该引用的值，使其直接指向新对象，ZGC将这种行为称为指针的“自愈”(Self-Healing)能力。这样做的好处是只有第一次访问旧对象陷人转发，也就是只慢一次。
4. 并发重映射(ConcurrentRemap)：重映射所做的就是修正整个堆中指向重分配集中旧对象的所有引用，这一点从目标角度看是与Shenandoah并发引用更新阶段一的，但是ZGC的并发重映射并不是一个必须要“迫切”去完成的任务，因为前面说过，即使是旧引用，它也是可以自愈的，最多只是第一次使用时多一次转发和修正操作。重映射清理这些旧引用的主要目的是为了不变慢(还有清理结束后可以释放转发表这样的附带收益)，所以说这并不是很“迫切”。因此，ZGC很巧妙地把并发重映射阶段要做的工作，合并到了下一次垃圾收集循环中的并发标记阶段里去完成反正它们都是要遍历所有对象的，这样合并就节省了一次遍历对象图的开销。一旦所有指针都被修正之后，原来记录新旧对象关系的转发表就可以释放掉了。

参考自《深入理解Java虚拟机》