如何发起内存回收?
当前主流的JVM都是采用可达性分析算法通过根节点枚举来找到已经死去的对象。
固定可作为GC Roots的节点主要在全局性的引用（例如常量或类静态属性） 与执行上下文（例如栈帧中的本地变量表） 中， 尽管目标明确， 但查找过程要做到高效并非一件容易的事情，里面的类、 常量等恒河沙数，若要逐个检查以这里为起源的引用肯定得消耗不少时间。
目前，所有收集器在根节点枚举这一步骤时都是必须暂停用户线程的，因此毫无疑问根节点枚举与之前提及的整理内存碎片一样会面临相似的“Stop The World”的困扰。
虽然，现在可达性分析算法耗时最长的查找引用链的过程已经可以做到与用户线程一起并发，但根节点枚举始终还是必须在一个能保障一致性的快照中才得以进行。
这是导致垃圾收集过程必须停顿所有用户线程的其中一个重要原因，即使是号称停顿时间可控，或者（几乎） 不会发生停顿的CMS、 G1、ZGC等收集器， 枚举根节点时也是必须要停顿的。
关于一致性的说明
整个枚举期间执行子系统看起来就像被冻结在某个时间点上，不会出现分析过程中， 根节点集合的对象引用关系还在不断变化的情况，若这点不能满足的话，分析结果准确性也就无法保证。
如何加速内存回收？
主要解决为优化GC Roots的查找和并行可达性分析。
优化GC Roots的查找
由于目前主流Java虚拟机使用的都是准确式垃圾收集，所以当用户线程停顿下来之后，其实并不需要一个不漏地检查完所有执行上下文和全局的引用位置，虚拟机应当是有办法直接得到哪些地方存放着对象引用的。
解决方案：程序执行时采用安全点
在HotSpot的解决方案里， 是使用一组称为OopMap的数据结构来达到这个目的。一旦类加载动作完成的时候，HotSpot就会把对象内什么偏移量上是什么类型的数据计算出来， 在即时编译过程中，也会在特定的位置记录下栈里和寄存器里哪些位置是引用。
这样收集器在扫描时就可以直接得知这些信息了，并不需要真正一个不漏地从方法区等GC Roots开始查找。
在OopMap的协助下，HotSpot可以快速准确地完成GC Roots枚举，但一个很现实的问题随之而来： 可能导致引用关系变化，或者说导致OopMap内容变化的指令非常多，如果为每一条指令都生成对应的OopMap，那将会需要大量的额外存储空间。
实际上HotSpot也的确没有为每条指令都生成OopMap，只是在“特定的位置”记录了这些信息，这些位置被称为安全点（Safepoint） 。 有了安全点的设定，也就决定了用户程序执行时并非在代码指令流的任意位置都能够停顿下来开始垃圾收集，而是强制要求必须执行到达安全点后才能够暂停。
因此，安全点的选定既不能太少以至于让收集器等待时间过长，也不能太过频繁以至于过分增大运行时的内存负荷。
安全点的选取
安全点位置的选取基本上是以“是否具有让程序长时间执行的特征”为标准进行选定的，因为每条指令执行的时间都非常短暂，程序不太可能因为指令流长度太长这样的原因而长时间执行， “长时间执行”的最明显特征就是指令序列的复用， 例如方法调用、 循环跳转、 异常跳转等都属于指令序列复用， 所以只有具有这些功能的指令才会产生安全点。
对于安全点，另外一个需要考虑的问题是，如何在垃圾收集发生时让所有线程（这里其实不包括执行JNI调用的线程）都跑到最近的安全点， 然后停顿下来。
这里有两种方案可供选择： 抢先式中断（Preemptive Suspension） 和主动式中断（Voluntary Suspension） 。
- 抢先式中断不需要线程的执行代码主动去配合，在垃圾收集发生时，系统首先把所有用户线程全部中断，如果发现有用户线程中断的地方不在安全点上， 就恢复这条线程执行， 让它一会再重新中断， 直到跑到安全点上。 现在几乎没有虚拟机实现采用抢先式中断来暂停线程响应GC事件。
- 主动式中断的思想是当垃圾收集需要中断线程的时候，不直接对线程操作，仅仅简单地设置一个标志位， 各个线程执行过程时会不停地主动去轮询这个标志， 一旦发现中断标志为真时就自己在最近的安全点上主动中断挂起。 轮询标志的地方和安全点是重合的，另外还要加上所有创建对象和其他需要在Java堆上分配内存的地方，这是为了检查是否即将要发生垃圾收集，避免没有足够内存分配新对象。由于轮询操作在代码中会频繁出现，这要求它必须足够高效。HotSpot使用内存保护陷阱的方式，把轮询操作精简至只有一条汇编指令的程度。
解决方案：程序不执行时采用安全区域
使用安全点的设计似乎已经完美解决如何停顿用户线程，让虚拟机进入垃圾回收状态的问题了，但实际情况却并不一定。安全点机制保证了程序执行时， 在不太长的时间内就会遇到可进入垃圾收集过程的安全点。
但是，程序“不执行”的时候呢？ 所谓的程序不执行就是没有分配处理器时间，典型的场景便是用户线程处于Sleep状态或者Blocked状态，这时候线程无法响应虚拟机的中断请求，不能再走到安全的地方去中断挂起自己，虚拟机也显然不可能持续等待线程重新被激活分配处理器时间。对于这种情况，就必须引入安全区域（Safe Region） 来解决。
安全区域是指能够确保在某一段代码片段之中，引用关系不会发生变化，因此，在这个区域中任意地方开始垃圾收集都是安全的。 我们也可以把安全区域看作被扩展拉伸了的安全点。
当用户线程执行到安全区域里面的代码时，首先会标识自己已经进入了安全区域，那样当这段时间里虚拟机要发起垃圾收集时就不必去管这些已声明自己在安全区域内的线程了。
当线程要离开安全区域时，它要检查虚拟机是否已经完成了根节点枚举（或者垃圾收集过程中其他需要暂停用户线程的阶段）。
- 如果完成了，那线程就当作没事发生过，继续执行；
- 否则，它就必须一直等待，直到收到可以离开安全区域的信号为止。
如何保证内存回收正确性?
解决对象跨代引用问题：记忆集与卡表
为解决对象跨代引用所带来的问题， 垃圾收集器在新生代中建立了名为记忆集（Remembered Set） 的数据结构， 用以避免把整个老年代加进GC Roots扫描范围。
事实上并不只是新生代、 老年代之间才有跨代引用的问题， 所有涉及部分区域收集（Partial GC） 行为的垃圾收集器， 典型的如G1、 ZGC和Shenandoah收集器， 都会面临相同的问题。
记忆集是一种用于记录从非收集区域指向收集区域的指针集合的抽象数据结构。
如果我们不考虑效率和成本的话，最简单的实现可以用非收集区域中所有含跨代引用的对象数组来实现这个数据结构。这种记录全部含跨代引用对象的实现方案，无论是空间占用还是维护成本都相当高昂。伪代码如下所示：
class RememberedSet { Object[] set[OBJECT_INTERGENERATIONAL_REFERENCE_SIZE]; } 复制代码
而在垃圾收集的场景中，收集器只需要通过记忆集判断出某一块非收集区域是否存在有指向了收集区域的指针就可以了，并不需要了解这些跨代指针的全部细节。
那设计者在实现记忆集的时候， 便可以选择更为粗犷的记录粒度来节省记忆集的存储和维护成本，下面列举了一些可供选择（当然也可以选择这个范围以外的） 的记录精度：
- 字长精度： 每个记录精确到一个机器字长（就是处理器的寻址位数， 如常见的32位或64位，这个精度决定了机器访问物理内存地址的指针长度），该字包含跨代指针。
- 对象精度： 每个记录精确到一个对象，该对象里有字段含有跨代指针。
- 卡精度： 每个记录精确到一块内存区域， 该区域内有对象含有跨代指针
其中， 第三种“卡精度”所指的是用一种称为“卡表”（Card Table） 的方式去实现记忆集， 这也是目前最常用的一种记忆集实现形式。
记忆集与卡表的区别：
记忆集其实是一种“抽象”的数据结构， 抽象的意思是只定义了记忆集的行为意图， 并没有定义其行为的具体实现。
卡表就是记忆集的一种具体实现， 它定义了记忆集的记录精度、 与堆内存的映射关系等。
卡表最简单的形式可以只是一个字节数组， 而HotSpot虚拟机确实也是这样做的。 以下这行代码是HotSpot默认的卡表标记逻辑。
CARD_TABLE [this address >> 9] = 0; 复制代码
字节数组CARD_TABLE的每一个元素都对应着其标识的内存区域中一块特定大小的内存块， 这个内存块被称作“卡页”（Card Page） 。
一般来说， 卡页大小都是以2的N次幂的字节数，通过上面代码可以看出HotSpot中使用的卡页是2的9次幂， 即512字节（地址右移9位， 相当于用地址除以512）。
那如果卡表标识内存区域的起始地址是0x0000的话，数组CARD_TABLE的第0、 1、 2号元素，分别对应了地址范围为0x0000～0x01FF、 0x0200～0x03FF、 0x0400～0x05FF的卡页内存块， 如下图所示。
一个卡页的内存中通常包含不止一个对象，只要卡页内有一个（或更多） 对象的字段存在着跨代指针， 那就将对应卡表的数组元素的值标识为1， 称为这个元素变脏（Dirty） ， 没有则标识为0。 在垃圾收集发生时，只要筛选出卡表中变脏的元素， 就能轻易得出哪些卡页内存块中包含跨代指针， 把它们加入GC Roots中一并扫描。
卡表元素如何维护：写屏障
我们已经解决了如何使用记忆集来缩减GC Roots扫描范围的问题，但还没有解决卡表元素如何维护的问题，例如它们何时变脏、谁来把它们变脏等。
卡表元素何时变脏的答案是很明确的——有其他分代区域中对象引用了本区域对象时， 其对应的卡表元素就应该变脏， 变脏时间点原则上应该发生在引用类型字段赋值的那一刻。
但问题是如何变脏，即如何在对象赋值的那一刻去更新维护卡表呢？
- 假如是解释执行的字节码，那相对好处理，虚拟机负责每条字节码指令的执行，有充分的介入空间；
- 但在编译执行的场景中呢？经过即时编译后的代码已经是纯粹的机器指令流了， 这就必须找到一个在机器码层面的手段，把维护卡表的动作放到每一个赋值操作之中。
在HotSpot虚拟机里是通过写屏障（Write Barrier） 技术维护卡表状态的。
写屏障可以看作在虚拟机层面对“引用类型字段赋值”这个动作的AOP切面，在引用对象赋值时会产生一个环形（Around）通知， 供程序执行额外的动作， 也就是说赋值的前后都在写屏障的覆盖范畴内。
在赋值前的部分的写屏障叫作写前屏障（Pre-Write Barrier）， 在赋值后的则叫作写后屏障（Post-Write Barrier） 。
HotSpot虚拟机的许多收集器中都有使用到写屏障， 但直至G1收集器出现之前，其他收集器都只用到了写后屏障。
写后屏障更新卡表代码如下所示：
void oop_field_store(oop* field, oop new_value) { // 引用字段赋值操作 *field = new_value; // 写后屏障， 在这里完成卡表状态更新 post_write_barrier(field, new_value); } 复制代码
写屏障存在的一些问题
应用写屏障后，虚拟机就会为所有赋值操作生成相应的指令，一旦收集器在写屏障中增加了更新卡表操作，无论更新的是不是老年代对新生代对象的引用，每次只要对引用进行更新，就会产生额外的开销，不过这个开销与Minor GC时扫描整个老年代的代价相比还是低得多的。
除了写屏障的开销外，卡表在高并发场景下还面临着“伪共享”（False Sharing） 问题。 伪共享是处理并发底层细节时一种经常需要考虑的问题，现代中央处理器的缓存系统中是以缓存行（Cache Line）为单位存储的， 当多线程修改互相独立的变量时，如果这些变量恰好共享同一个缓存行，就会彼此影响（写回、无效化或者同步）而导致性能降低，这就是伪共享问题。
假设处理器的缓存行大小为64字节， 由于一个卡表元素占1个字节， 64个卡表元素将共享同一个缓存行。
这64个卡表元素对应的卡页总的内存为32KB（64×512字节） ，也就是说如果不同线程更新的对象正好处于这32KB的内存区域内， 就会导致更新卡表时正好写入同一个缓存行而影响性能。
为了避免伪共享问题，一种简单的解决方案是不采用无条件的写屏障，而是先检查卡表标记， 只有当该卡表元素未被标记过时才将其标记为变脏。
将卡表更新的逻辑变为以下代码所示：
if (CARD_TABLE [this address >> 9] != 0) CARD_TABLE [this address >> 9] = 0 复制代码
