JVM之垃圾回收

如何确定垃圾

引用计数法

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

可达性分析

为了解决引用计数法的循环引用问题，Java 使用了可达性分析的方法。通过一些列的“GC roots”对象作为起点搜索（可以理解在main方法主业务逻辑中我们自己创建的对象，类似于这种对象一定是有用的，所以可以把这些对象作为”roots”向下寻找）。如果在“GC roots”和一个对象之间没有可达路径，则称该对象是不可达的。要注意的是，不可达对象不等价于可回收对象，不可达对象变为可回收对象至少要经过两次标记过程。两次标记后仍然是可回收对象，则将面临回收。

垃圾回收算法

分代收集理论
分代收集算法是目前大部分 JVM 所采用的方法，其核心思想是根据对象存活的不同生命周期将内存划分为不同的域，一般情况下将 GC 划分为老年代和新生代，另一种方式是分区回收。
比如在新生代中，每次收集都会有大量对象(近99%)死去，所以可以选择复制算法，只需要付出少量对象的复制成本就可以完成每次垃圾收集。而老年代的对象存活几率是比较高的，而且没有额外的空间对它进行分配担保，所以我们必须选择“标记-清除”或“标记-整理”算法进行垃圾收集。注意，“标记-清除”或“标记-整理”算法会比复制算法慢10倍以上。

标记-清除算法(Mark-Sweep)

最基础的垃圾回收算法，分为两个阶段：标记和清除。标记存活的对象， 统一回收所有未被标记的对象(一般选择这种)；也可以反过来，标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象 ，如图：

它是最基础的收集算法，比较简单，但是会带来两个明显的问题：

1. 效率问题 (如果需要标记的对象太多，效率不高)
2. 空间问题（标记清除后会产生大量不连续的碎片）

   标记-复制算法(Copying)

   为了解决Mark-Sweep算法内存碎片化严重的缺陷而被提出的算法。按内存容量将内存划分为等大小的两块，每次只使用其中的一块。当这一块内存满后将尚存活的对象复制到另一块上去，把已使用的内存清理，如图：
   
   这种算法虽然实现简单，内存效率高，不易产生碎片，但是最大的问题是可用内存被压缩到了原来的一半。且随着存活对象的增多，Copying算法的效率会大大降低。

   标记-整理算法(Mark-Compact)

   结合以上两种算法而出现。标记阶段和 Mark-Sweep 算法相同，标记后不是清除对象，而是将存活对象移至内存的一端，然后直接清理掉端边界以外的内存，如图：
   

垃圾收集器（分代）

如果说收集算法是回收的方法论，那么垃圾收集器就是内存回收的具体实现。
到目前为止还没有最好最完美的垃圾收集器出现，更没有万能的垃圾收集器，能做的就是根据具体应用场景选择合适自己的垃圾收集器。如果有任何场景下都完美的垃圾收集器存在，那 Java 虚拟机就不会实现这么多不同的垃圾收集器。

Serial收集器(-XX:+UseSerialGC -XX:+UseSerialOldGC)

Serial (串行)收集器是最基本、历史最悠久的垃圾收集器。看名字就知道是单线程收集器。它的“单线程”的意义不仅仅意味着使用一条垃圾收集线程去完成垃圾收集工作，更重要的是它在进行垃圾手机工作的时候必须暂停其他所有的工作线程 （”Stop The World”），直到它收集结束。
新生代采用复制算法，老年代采用标记-整理算法。

虚拟机的设计者们最头疼的就是STW带来的不良用户体验，所以在后续的垃圾收集器中停顿时间在不断缩短（仍然还有停顿）。
虽然 Serial 是但单线程，但是也有优于其它垃圾收集器的地方。它简单而高效（相比较与其他收集器的单线程相比）。Serial 收集器由于没有线程交互的开销，自然在单线程上收集效率最高。
Serial Old 收集器是 Serial 收集器的老年代版本，它同样是一个单线程收集器。它主要的两个用途是：

1. 在 JDK1.5 以及之前的版本中与 Paallel Scavenge 收集器搭配使用。

2. 作为 CMS 收集器的备选方案。

   Parallel 收集器(-XX:+UseParallelGC(年轻代),-XX:+UseParallelOldGC(老年代))

   新生代采用复制算法，老年代采用标记-整理算法**。
   Parallel 收集器其实就是 Serial 收集器的多线程版本（Parallel Scavenge），除了使用多线程进行垃圾收集外，其余行为（控制参数、收集算法、回收策略等）和 Serial 收集器类似。默认的收集线程数与 cpu 核数相同，当然也可以用参数（-XX:ParallelGCThreads）指定收集线程数，但是一般不推荐修改。
   Parallel Scavenge 收集器关注重点是吞吐量（高效率的使用 CPU）。CMS 等垃圾收集器的关注点更多的是用户线程的停顿时间（提高用户体验）。
   所谓吞吐量就是 CPU 中用于运行用户代码的时间与 CPU 总消耗时间的比值。Parallel Scavenge 收集器提供了很多参数供用户找到最合适的停顿时间或最大吞吐量，如果对于收集器运作不了解，可以选择把内存管理优化交给虚拟机去完成。
   
   Parallel Old 收集器是 Parallel Scavenge 收集器的老年代版本。使用多线程和“标记-整理”算法。在注重吞吐量以及CPU资源的场合，都可以优先考虑 Parallel Scavenge收集器和Parallel Old收集器(JDK8默认的新生代和老年代收集器**)。

   ParNew收集器(-XX:+UseParNewGC)

   新生代采用复制算法，老年代采用标记-整理算法**。**
   ParNew 收集器类似于 Parallel 收集器，区别主要在于它可以与 CMS 收集器配合使用。
   
   它是许多运行在 Server 模式下的虚拟机的首要选择，除了 Serial 收集器外，只有它能与 CMS 收集器（真正意义上的并发收集器）配合工作。

   CMS收集器(-XX:+UseConcMarkSweepGC(old))

   CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。它非常符合在注重用户体验的应用上使用，它是 Hotspot 虚拟机第一款真正意义上的并发收集器，它第一次实现了让垃圾收集线程与用户线程（基本上）同时工作。
   从名字中的 Mark Sweep 这两个词可以看出，CMS 收集器一种“标记-清除”算法实现的，它的运作过程较之前的几种垃圾收集器相比更复杂，整个过程分为几个步骤：

3. 初始标记：暂停所有的其他线程（STW），并记录下“GC roots”直接能引用的对象，速度很快。

4. 并发标记：并发标记阶段就是从 “GC roots”的直接关联对象开始遍历整个对象图的过程，这个过程好使较长但是不需要停顿用户线程，可以与垃圾收集器一起并发运行。因为用户程序继续运行，可能会有导致已经标记过的对象状态发生改变。
5. 重新标记：重新标记阶段就是为修正并发标记期间因为用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段的时间较长，远远比并发标记阶段时间短。主要用到三色标记中的增量更新算法那做重新标记。
6. 并发清理：开启用户线程，同时 GC 线程开始对未标记的区域做清扫。这个阶段如果有新增对象会被标记为黑色不做任何处理。
7. 并发重置：重置本次 GC 过程中的标记数据。

从它的名字就可以看出它是一块优秀的垃圾收集器，主要优点：并发收集、底停顿。但是它有下面几个明显的缺点：

• 对 CPU 资源敏感（会和服务抢资源）
• 无法处理浮动垃圾（在并发标记和并发清理阶段又产生垃圾，这种浮动垃圾只能等到 GC 再清理了）。
• 它使用的回收算法“标记-清除”算法会导致收集结束时会有大量空间碎片产生，当然通过参数-XX:+UseCMSCompactAtFullCollection，可以让 JVM 在执行完标记清除后在做整理
• 执行过程中的不确定性，会存在上一次垃圾回收还没进行完，然后垃圾回收又被触发的情况，特别是在并发标记和并发清理阶段会出现，一边回收，系统一边运行，也许没回收完就会再次触发 full GC，也就是“concurrent mode failure”，此时会进入 STW，用 Serial Old 垃圾收集器来回收。

CMS的相关核心参数

垃圾收集器（分区）

G1收集器(-XX:+UseG1GC)

G1 (Garbage-First) 是一款面向服务器的垃圾收集器，主要针对配备多颗处理器及大容量内存的机器。以极高概率满足GC停顿时间要求的同时,还具备高吞吐量性能特征。JDK1.9默认

从 G1 开始采用了分区回收思想。G1将 Java 堆划分为多个大小相等的独立区域（Region）,JVM 最多可以有2048个 Region。
一般 Region 的大小等于堆大小除以2048，比如堆大小为4096M，则 Region 大小为2M，当然也可以使用参数-XX:G1HeapRegionSize手动指定 Region 大小，但是推荐默认的计算方式。
G1 保留了年轻代和老年代的概念，但是不再是物理隔阂，它们都是（可以不连续）Region 的集合。
默认年轻代在堆中的占比为5%，如果堆大小为4096M，那么年轻代占据200MB左右的内存，对应大概是100个 Region，可以通过-XX:G1NewSizePercent设置新生代初始占比。在系统运行中，JVM会不停的给年轻代增加更多的 Region，但是最多新生代占比不会超过60%，可以通过-XX:G1MaxNewSizePercent调整。年轻代种的 Eden 和 Survivor 对应的 Region 也跟之前一样，默认 8:1:1，假设年轻代现在有1000个 Region，Eden 区对应800个，s0和s1对应各100个。
一个 Region 可能之前是年轻代，如果 Region 进行了垃圾回收，之后可能又会变成老年代，也就是说 Region 的区域功能可能会动态变化。

G1 垃圾收集器对于对象何时进入老年代与之前类似，唯一不同的是对大对象的处理。G1有专门分配大对象的 Region 叫 Humongous 区，而不是让大对象直接进入老年代的 Region 中。在G1中，大对象的判定规则就是一个大对象超过了一个 Region 大小的50%。也就是每个 Region 是2M，只要一个大对象超过了1M，就会被放入 Humongous 中，而且一个大对象如果超大，可能会横跨多个 Region 来存放。
Humongous 区专门存放短期大对象，不用直接进入老年代，可以节约老年代的空间，避免因为老年代空间不够的 GC 开销。
Full GC 的时候除了收集年轻代和老年代之外，也会将 Humongous 区一并回收。

运作过程

• 初始标记（initial mark，STW）：暂停所有其它线程，并记录下 GC roots 直接能引用的对象，速度很快。
• 并发标记（Concurrent Making）：同 CMS 的并发标记。
• 最终标记（Remark，STW）：同 CMS 的重新标记。
• 筛选回收（Cleanup，STW）：筛选回收阶段首先对各个 Region 的回收价值和成本进行排序，根据用户所期望的 GC 停顿 STW 时间（可以用 JVM 参数**-XX:MaxGCPauseMillis**）来制定回收计划。比如说老年代此时有1000个 Region 满了，但是因为根据预期停顿时间，本次垃圾回收只能停顿200毫秒，那么通过之前回收成本计算得知，可能回收其中800个 Region 刚好需要200ms，那么只会回收800个 Region，尽量把 GC 导致的停顿时间控制在我们指定范围内。这个阶段其实也可以做到与用户程序一起并发执行，但是因为只回收一部分 Region，时间是用户可控制的，而且停顿用户线程将大幅提高收集效率。不管是年轻代或者老年代，回收算法用的是复制算法，将一个 Region 中的存活对象复制到另一个 Region 中，这样不会像 CMS 那样收集完有很多内存碎片还需要整理一次，G1采用复制算法回收几乎不会有太多内存碎片（CMS 回收阶段是与用户线程一起并发执行的，G1因为内部实现太复杂暂时没有实现并发回收，不过到了 ZGC ，Shenandoah 就实现了并发收集，Shenandoah 可以看成G1的升级版本）。

G1收集器在后台维护了一个优先列表，每次根据允许的收集时间，优先选择回收价值最大的 Region(这也就是它的名字 Garbage-First 的由来)，比如一个 Region 花200ms能回收10M垃圾，另外一个 Region 花50ms能回收20M垃圾，在回收时间有限情况下，G1当然会优先选择后面这个Region 回收。这种使用Region划分内存空间以及有优先级的区域回收方式，保证了G1收集器在有限时间内可以尽可能高的收集效率。

G1被视为JDK1.7以上版本Java虚拟机的一个重要进化特征。它具备以下特点：

• 并行与并发：G1能充分利用CPU、多核环境下的硬件优势，使用多个CPU（CPU或者CPU核心）来缩短Stop-The-World停顿时间。部分其他收集器原本需要停顿Java线程来执行GC动作，G1收集器仍然可以通过并发的方式让java程序继续执行。
• 分代收集：虽然G1可以不需要其他收集器配合就能独立管理整个GC堆，但是还是保留了分代的概念。
• 空间整合：与CMS的“标记—清理”算法不同，G1从整体来看是基于“标记整理”算法实现的收集器；从局部上来看是基于“复制”算法实现的。
• 可预测的停顿：这是G1相对于CMS的另一个大优势，降低停顿时间是G1 和 CMS 共同的关注点，但G1 除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段(通过参数**-XX:MaxGCPauseMillis**指定)内完成垃圾收集。

毫无疑问，G1的可以由用户指定期望的停顿时间是非常强大的功能，也是得G1在不同应用场景中取得关注吞吐量和关注延迟时间之间的最佳平衡。
不过这里设置的“期望值”必须是符合实际的，毕竟G1是要冻结用户线程来复制对象，这个停顿时间再低也要有个消毒。它默认的目标停顿时间我200ms，一般来说回收阶段占几十甚至接近两三百毫秒都正常，但是如果把停顿时间调很低，譬如设置了20ms，很可能出现由于停顿目标时间太短，导致每次筛选出的回收集只占堆内存很小的一部分，收集器收集的速度逐渐跟不上分配器分配的速度，导致垃圾慢慢堆积。很可能一开始收集器还能从空闲的堆内存中获得一些喘息时间，但是应用运行时间长了就不行了，最终沾满堆引发 Full GC 反而降低性能，所以通常将停顿时间设置为一百到两三百毫秒都是比较合理的。

G1垃圾收集器分类
YoungGC
YoungGC并不是说现有的 Eden 区放满了就会马上触发，G1会计算下现在 Eden 区回收大概要多久时间，如果回收时间远远小于参数 -XX:MaxGCPauseMills 设定的值，那么增加年轻代的region，继续给新对象存放，不会马上做Young GC，直到下一次Eden区放满，G1计算回收时间接近设定的值，那么就会触发Young GC。
MixedGC
不是FullGC，老年代的堆占有率达到参数(**-XX:InitiatingHeapOccupancyPercent**)设定的值则触发，回收所有的Young和部分Old(根据期望的 GC 停顿时间确定old区垃圾收集的优先顺序)以及大对象区，正常情况G1的垃圾收集是先做MixedGC，主要使用复制算法，需要把各个region中存活的对象拷贝到别的region里去，拷贝过程中如果发现没有足够的空 Region 能够承载拷贝对象就会触发一次 Full GC。
Full GC
停止系统程序，然后采用单线程进行标记、清除和压缩整理，好空闲出来一批 Region 来供下一次 Mixed GC 使用，这个过程是非常耗时的。(Shenandoah优化成多线程收集了)。

G1收集器调优参数（部分）

优化建议：假设参数-XX:MaxGCPauseMills设置的值很大，导致系统运行很久，年轻代可能都占用了堆内存的60%了，此时才触发年轻代gc。
那么存活下来的对象可能就会很多，此时就会导致Survivor区域放不下那么多的对象，就会进入老年代中。或者是你年轻代gc过后，存活下来的对象过多，导致进入 Survivor 区域后触发了动态年龄判定规则，达到了Survivor区域的50%，也会快速导致一些对象进入老年代中。
所以这里核心还是在于调节-XX:MaxGCPauseMills这个参数的值，在保证他的年轻代gc别太频繁的同时，还得考虑每次gc过后的存活对象有多少,避免存活对象太多快速进入老年代，频繁触发mixed gc。

什么场景适合使用G1

1. 50%以上的堆被存活对象占用
2. 对象分配和晋升的速度变化非常大
3. 垃圾回收时间特别长，超过1秒
4. 8GB以上的堆内存(建议值)
5. 停顿时间是500ms以内

每秒几十万并发的系统如何优化JVM
Kafka 类似的支撑高并发消息系统大家肯定不陌生，对于 kafka 来说，每秒处理几万甚至几十万消息时很正常的，一般来说部署 kafka 需要用大内存机器(比如64G)，也就是说可以给年轻代分配个三四十G的内存用来支撑高并发处理，这里就涉及到一个问题了，虽然 Eden 区的 Young GC 是很快的，这种情况下它的执行还会很快吗？很显然，不可能，因为内存太大，处理还是要花不少时间的，假设三四十G内存回收可能最快也要几秒钟，按 kafka 这个并发量放满三四十G的 Eden 区可能也就一两分钟吧，那么意味着整个系统每运行一两分钟就会因为 Young GC 卡顿几秒钟没法处理新消息，显然是不行的。那么对于这种情况如何优化了，我们可以使用G1收集器，设置-XX:MaxGCPauseMills为50ms，假设50ms能够回收三到四个G内存，然后50ms的卡顿其实完全能够接受，用户几乎无感知，那么整个系统就可以在卡顿几乎无感知的情况下一边处理业务一边收集垃圾。
G1天生就适合这种大内存机器的JVM运行，可以比较完美的解决大内存垃圾回收时间过长的问题。

ZGC收集器(-XX:+UseZGC)

暂时用处较少，高版本jdk算法较完善 >=11
关键词：

1. 只支持64位指针，不支持32位，不支持指针压缩。
2. 颜色指针，只使用44位做寻址，4位作为标记为（Finalizable、Remapped、Marked1、Marked0），空闲18位。
3. 支持内存TB级别，最高16TB？
4. 响应时间大概10ms
5. 读屏障

参考：
https://wiki.openjdk.java.net/display/zgc/Main
http://cr.openjdk.java.net/~pliden/slides/ZGC-Jfokus-2018.pdf

底层垃圾收集算法

三色标记算法

概念

由于在并发标记过程中，因为标记期间应用线程在继续运行，对象间的引用可能发生变化，多标和漏标情况就有可能发生。而三色标记算法是所有利用了可达性分析方法垃圾收集器的基础算法。
三色标记就是为了解决这两个问题而出现，把通过“GC roots”可达性分析遍历对象过程中遇到的对象，按照“是否访问过”这个条件标记成以下三种颜色（不是真的标上了颜色，只是在某个位置能表示！）：

• 黑色：表示对象已经被垃圾收集器访问过，且该对象的所有引用（子对象）都已经扫描。黑色的对象已扫描，它是安全存活的，如果有其它对象引用指向了黑色对象，无需重新扫描一遍。黑色对象（不经过灰色对象）不可能直接指向某个白色对象。
• 灰色：表示对象已经被垃圾收集器访问过，但这个对象上至少存在一个引用还没有被扫描（未完全扫描）。
• 白色：表示对象尚未被垃圾收集器访问过。显然在可达性分析刚开始阶段时，所有的对象都是白色的，如果分析结束阶段对象仍然是白色，即代表不可达。

然而三色标记算法中也存在着某些问题

存在问题

多标-浮动垃圾

在并发标记过程中，如果由于方法运行结束导致部分局部变量（GC root）被销毁，这个 GC root引用的对象之前又被扫描过（被标记为非垃圾对象），那么本轮 GC 不会回收这部分，由于这部分内存本应该在 GC root 被销毁时回收而没有被回收，称为“浮动垃圾”。浮动垃圾并不会影响垃圾回收的准确性，只是需要等到下一轮垃圾回收中才被清除。
另外，针对并发标记（还有并发清理）开始以后产生的新对象，通常做法是直接标记为黑色，本轮不进行清除。这部分对象期间可能变为垃圾，算是浮动垃圾的一部分。

漏标-读写屏障

漏标会导致正在被引用的对象被当成垃圾误删，这是极为严重的 bug。一张图表示漏标：

过程是，A 已完全扫描（黑色），B部分扫描（C完全扫描，D暂未扫描，灰色）。此时线程暂停后，由于业务中某些方法使得 B->D 的引用消失，反而增加了 A->D 的引用，此时 D 正在被 A 引用，但是由于漏标了 D 的颜色导致其被当为垃圾回收了，此时存在漏标问题。
漏标有两种解决方案：增量更新（Incremental Update）和原始快照（Snapshot At The Beginning，SATB）。

• 增量更新：当黑色对象新引用白色对象时，JVM 将这个引用记录，等并发扫描结束后，再将这些记录过的引用关系中的黑色对象为根，重新扫描一次。即 JVM 会将那些新引用指向白色对象的黑色对象重新变为灰色（写屏障）。
• 原始快照：当灰色对象要删除指向白色对象的引用时，这个白色对象的引用会被记录下来，等并发扫描结束后，再将这些记录过的引用关系中的灰色对象为根重新扫描。这样就能扫描到白色对象，将白色对象直接标记为黑色（目的就是让这种对象在本轮的 GC 清理中存活，待下一轮 GC 重新扫描，当然这个对象也可能是浮动垃圾）。、

无论是对引用关系的插入还是记录，虚拟机的记录操作都是通过写屏障实现的。

写屏障

给某个对象的成员变量赋值时，其底层代码约为：

/**
* @param field 某对象的成员变量，如 a.b.d 
* @param new_value 新值，如 null
*/
void oop_field_store(oop* field, oop new_value) { 
    *field = new_value; // 赋值操作
}

所谓的写屏障，其实就是指在赋值操作前后，加入一些处理（可以参考AOP的概念）：

void oop_field_store(oop* field, oop new_value) {  
    pre_write_barrier(field);          // 写屏障-写前操作
    *field = new_value; 
    post_write_barrier(field, value);  // 写屏障-写后操作
}

• 写屏障实现 SATB

当对象B的成员变量的引用发生变化时，比如引用消失（a.b.d = null）。利用写屏障，将 B 原来成员变量的引用对象 D 记录下来：

void pre_write_barrier(oop* field) {
    oop old_value = *field;    // 获取旧值
    remark_set.add(old_value); // 记录原来的引用对象
}

• 写屏障实现增量更新

  void post_write_barrier(oop* field, oop new_value) {  
    remark_set.add(new_value);  // 记录新引用的对象
  }

  读屏障

  oop oop_field_load(oop* field) {
    pre_load_barrier(field); // 读屏障-读取前操作
    return *field;
  }

  读屏障是直接针对第一步：D d = a.b.d，当读取成员变量时，一律记录下来：

  void pre_load_barrier(oop* field) {  
    oop old_value = *field;
    remark_set.add(old_value); // 记录读取到的对象
  }

现代追踪式（可达性分析）的垃圾回收器几乎都借鉴了三色标记的算法思想，尽管实现的方式不尽相同。
对于读写屏障，以 Java HotSpot VM 为例，其并发标记时对漏标的处理方案如下：

• CMS：写屏障 + 增量更新
• G1，Shenandoah：写屏障 + SATB
• ZGC：颜色指针 + 读屏障

工程实现中，读写屏障还有其他功能，比如写屏障可以用于记录跨代/区引用的变化，读屏障可以用于支持移动对象的并发执行等。功能之外，还有性能的考虑，所以对于选择哪种，每款垃圾回收器都有自己的想法。

为什么G1用SATB？CMS用增量更新？
SATB 相对增量更新效率会高(当然 SATB 可能造成更多的浮动垃圾)，因为不需要在重新标记阶段再次深度扫描被删除引用对象，而 CMS 对增量引用的根对象会做深度扫描，G1 因为很多对象都位于不同的 region，CMS就一块老年代区域，重新深度扫描对象的话 G1 的代价会比 CMS 高，所以 G1 选择 SATB 不深度扫描对象，只是简单标记，等到下一轮 GC 再深度扫描。

记忆集与卡表

在新生代做 GC Roots 可达性扫描过程中可能会碰到跨代引用的对象，这种如果又去对老年代再去扫描效率太低了。
为此，在新生代可以引入记忆集（Remember Set）的数据结构（记录从非收集区到收集区的指针集合），避免把整个老年代加入 GC Roots 扫描范围。除了分代收集算法中的跨代引用，在例如易于分区收集算法的垃圾收集器 G1、ZGC 和 Shenandoah等都会面临相同的问题。
垃圾收集场景中，收集器只需要通过记忆集判断出某一块非收集区域是否存在指向收集区域的指针即可，无需了解跨带引用指针的全部细节。
Hotspot 中使用了一种叫做“卡表”（Cardtable）的方式实现记忆集，也就是目前最常用的一种方式。关于记忆集与卡表可以类比于 Java 的 Map 与 HashMap。
卡表是使用一个字节数组实现：CARD_TABLE[]，每个元素对应其标识的内存区域一块特定大小的内存块，成为“卡页”(每个卡页大小为 29大小，即512字节)。

一个卡页可包含多个对象，只要有一个对象的字段存在跨带/跨区指针，即发生字段引用赋值时，其对应的卡表元素标识就是1，表示该元素变脏，否则为0。
GC 时，只要筛选本收集区的卡表中变脏的元素加入 GC Roots 中。

安全点与安全区域

安全点就是指代码中一些特定的位置,当线程运行到这些位置时它的状态是确定的,这样 JVM 就可以安全的进行一些操作,比如 GC 等，所以 GC 不是想什么时候做就立即触发的，是需要等待所有线程运行到安全点后才能触发。
这些特定的安全点位置主要有以下几种:

1. 方法返回之前
2. 调用某个方法之后
3. 抛出异常的位置
4. 循环的末尾

大体实现思想是当垃圾收集需要中断线程的时候， 不直接对线程操作， 仅仅简单地设置一个标志位， 各个线程执行过程时会不停地主动去轮询这个标志， 一旦发现中断标志为true时就自己在最近的安全点上主动中断挂起。 轮询标志的地方和安全点是重合的。
安全区域又是什么？
Safe Point 是对正在执行的线程设定的。
如果一个线程处于 Sleep 或中断状态，它就不能响应 JVM 的中断请求，再运行到 Safe Point 上。
因此 JVM 引入了 Safe Region。
Safe Region 是指在一段代码片段中，引用关系不会发生变化。在这个区域内的任意地方开始 GC 都是安全的。