**1 *stop the world***

**2 **减少stop the world的时间-OopMap

3 OopMap数据结构的维护-安全点-安全区域

3.1安全点

*3.2在垃圾回收时如何让所有线程到达最近的安全点(不包括执行JNI调用的线程)*

3.3 安全区域

4 记忆集和卡表的细节

4.1简要说明

4.2记忆集的记录精度选择

4.3卡表

4.4卡表的维护

5.并发的可达性分析

GCRoots根节点枚举细节

1 stop the world

　　迄今为止，所有垃圾收集器在根节点枚举这个步骤都是需要暂停用户线程：stop the world。这样子是为了保证根节点集合对象引用关系保持不变，保证根节点枚举的准确性。

2 减少stop the world的时间

　　目前主流Java虚拟机使用的都是准确式垃圾收集，当用户线程停顿下来之后，并不需要一个不漏地检查完所有执行上下文和全局的引用位置，虚拟机应当是有办法直接得到哪些地方存放着对象引用的。

　　在HotSpot的解决方案里，是使用一组称为OopMap的数据结构来达到这个目的。一旦类加载动作完成的时候，HotSpot就会把对象内什么偏移量上是什么类型的数据计算出来，在即时编译过程中，也会在特定的位置记录下栈里和寄存器里哪些位置是引用。这样收集器在扫描时就可以直接得知这些信息了，并不需要真正一个不漏地从方法区等GC Roots开始查找

　　总体来说就是HotSpot使用OopMap来快速正确找到内存中的引用而不用全内存扫描，这样子可以加快引用链的枚举

3 OopMap数据结构的维护-安全点-安全区域

3.1安全点

　　可能导致引用关系变化，或者说导致OopMap内容变化的指令非常多，如果为每一条指令都生成对应的OopMap，那将会需要大量的额外存储空间

　　 HotSpot没有为每条指令都生成OopMap，只是在“特定的位置”记录了这些信息，这些位置被称为安全点（Safepoint）。也就是说不是每一次引用的变化都会立刻更新到OopMap，只有到达了安全点才会去更新。

　　而且强制要求用户程序必须执行到达安全点后才能够暂停，也就是说程序的所有线程必须到达安全点才可以进行垃圾回收。

　　因此，安全点的选定既不能太少以至于让收集器等待时间过长，也不能太过频繁以至于过分增大运行时的内存负荷。

　　安全点位置的选取基本上是以“是否具有让程序长时间执行的特征”为标准进行选定的，因为每条指令执行的时间都非常短暂，程序不太可能因为指令流长度太长这样的原因而长时间执行，“长时间执行”的最明显特征就是指令序列的复用，例如方法调用、循环跳转、异常跳转等都属于指令序列复用，所以只有具有这些功能的指令才会产生安全点。

*3.2在垃圾回收时如何让所有线程到达最近的安全点(不包括执行JNI调用的线程)*

1）抢先式中断

　　抢先式中断不需要线程的执行代码主动去配合，在垃圾收集发生时，系统首先把所有用户线程全部中断，如果发现有用户线程中断的地方不在安全点上，就恢复这条线程执行，让它一会再重新中断，直到跑到安全点上。现在几乎没有虚拟机实现采用抢先式中断来暂停线程响应GC事件。

2）主动式中断

　　当垃圾收集需要中断线程的时候，不直接对线程操作，仅仅简单地设置一个标志位，各个线程执行过程时会不停地主动去轮询这个标志，一旦发现中断标志为真时就自己在最近的安全点上主动中断挂起。轮询标志的地方和安全点是重合的，另外还要加上所有创建对象的地方和其他需要在Java堆上分配内存的地方，这是为了检查是否即将要发生垃圾收集，避免没有足够内存分配新对象。

　　由于轮询操作在代码中会频繁出现，这要求它必须足够高效。HotSpot使用内存保护陷阱的方式，把轮询操作精简至只有一条汇编指令的程度。

3.3 安全区域

　　使用安全点的设计似乎已经完美解决如何停顿用户线程，让虚拟机进入垃圾回收状态的问题了，但实际情况却并不一定。

　　安全点机制保证了程序执行时，在不太长的时间内就会遇到可进入垃圾收集过程的安全点。但是，程序“不执行”的时候呢？所谓的程序不执行就是没有分配处理器时间，典型的场景便是用户线程处于Sleep状态或者Blocked状态，这时候线程无法响应虚拟机的中断请求，不能再走到安全的地方去中断挂起自己，虚拟机也显然不可能持续等待线程重新被激活分配处理器时间。对于这种情况，就必须引入安全区域（Safe Region）来解决。

　　安全区域是指能够确在某一段代码片段之中，引用关系不会发生变化，因此，在这个区域中任意地方开始垃圾收集都是安全的。我们也可以把安全区域看作被扩展拉伸了的安全点。当用户线程执行到安全区域里面的代码时，首先会标识自己已经进入了安全区域，那样当这段时间里虚拟机要发起垃圾收集时就不必去管这些已声明自己在安全区域内的线程了。当线程要离开安全区域时，它要检查虚拟机是否已经完成了根节点枚举（或者垃圾收集过程中其他需要暂停用户线程的阶段），如果完成了，那线程就当作没事发生过，继续执行；否则它就必须一直等待，直到收到可以离开安全区域的信号为止

4.记忆集和卡表的细节

4.1简要说明

　　解决对象跨代引用所带来的问题，垃圾收集器在新生代中建立了名为记忆集（Remembered Set）的数据结构，用以避免把整个老年代加进GC Roots扫描范围。事实上并不只是新生代、老年代之间才有跨代引用的问题，所有涉及部分区域收集（Partial GC）行为的垃圾收集器，都会面临相同的问题。

　　因此我们有必要进一步理清记忆集的原理和实现方式。

　　记忆集是一种用于记录从非收集区域指向收集区域的指针集合的抽象数据结构。

4.2记忆集的记录精度选择

　　如果我们不考虑效率和成本的话，最简单的实现可以用非收集区域中所有含跨代引用的对象数组来实现这个数据结构，这种方案，无论是空间占用还是维护成本都相当高昂。而在垃圾收集的场景中，收集器只需要通过记忆集判断出某一块非收集区域是否存在有指向了收集区域的指针就可以了。所以可以选择更为粗犷的记录粒度来节省记忆集的存储和维护成本，下面列举了一些可供选择（当然也可以选择这个范围以外的）的记录精度

1）字长精度：每个记录精确到一个机器字长（就是处理器的寻址位数，如常见的32位或64位，这个精度决定了机器访问物理内存地址的指针长度），该字包含跨代指针。

2）对象精度：每个记录精确到一个对象，该对象里有字段含有跨代指针。

3）卡精度：每个记录精确到一块内存区域，该区域内有对象含有跨代指针

4.3卡表

4.3.1简介

　　“卡精度”所指的是用一种称为“卡表”（Card Table）的方式去实现记忆集，这也是目前最常用的一种记忆集实现形式。

　　卡表就是记忆集的一种具体实现，它定义了记忆集的记录精度、与堆内存的映射关系等。关于卡表与记忆集的关系，读者不妨按照Java语言中HashMap与Map的关系来类比理解。

4.3.2卡表的形式

　　卡表最简单的形式可以只是一个字节数组，而HotSpot虚拟机确实也是这样做的。

　　

　　字节数组CARD_TABLE的每一个元素都对应着其标识的内存区域中一块特定大小的内存块，这个内存块被称作“卡页”（Card Page）。一般来说，卡页大小都是以2的N次幂的字节数，HotSpot中使用的卡页是2的9次幂，即512字节。

　　一个卡页的内存中通常包含不止一个对象，只要卡页内有一个（或更多）对象的字段存在着跨代指针，那就将对应卡表的数组元素的值标识为1，称为这个元素变脏（Dirty），没有则标识为0。在垃圾收集发生时，只要筛选出卡表中变脏的元素，就能轻易得出哪些卡页内存块中包含跨代指针，把它们加入GC Roots中一并扫描。

　　简单来说，卡表是个数组结构。把内存分为多个特定大小区域，这些内存区域叫做卡页，每个卡页对应卡表的一个元素。而每个卡页有一个或者多个对象，当卡页中存在跨区域引用时，就把它对应的卡表元素标为1。垃圾收集时，只需要找这些标为1的区域即可

4.4卡表的维护

4.4.1写屏障

　　卡表元素变脏时间点原则上应该发生在引用类型字段赋值的那一刻。如何在对象赋值的那一刻去更新维护卡表呢？

　　假如是解释执行的字节码，那相对好处理，虚拟机负责每条字节码指令的执行，有充分的介入空间；但在编译执行的场景中呢？经过即时编译后的代码已经是纯粹的机器指令流了，这就必须找到一个在机器码层面的手段，把维护卡表的动作放到每一个赋值操作之中。

　　在HotSpot虚拟机里是通过写屏障（Write Barrier）技术维护卡表状态的。写屏障可以看作在虚拟机层面对“引用类型字段赋值”这个动作的AOP切面，在引用对象赋值时会产生一个环形（Around）通知，供程序执行额外的动作，也就是说赋值的前后都在写屏障的覆盖范畴内。在赋值前的部分的写屏障叫作写前屏障（Pre-Write Barrier），在赋值后的则叫作写后屏障（Post-Write Barrier）。HotSpot虚拟机的许多收集器中都有使用到写屏障，但直至G1收集器出现之前，其他收集器都只用到了写后屏障。

4.4.2写屏障的缺点

1）额外开销  

　　应用写屏障后，虚拟机就会为所有赋值操作生成相应的指令，一旦收集器在写屏障中增加了更新卡表操作，无论更新的是不是老年代对新生代对象的引用，每次只要对引用进行更新，就会产生额外的开销，不过这个开销与Minor GC时扫描整个老年代的代价相比还是低得多的。

2）伪共享

　　除了写屏障的开销外，卡表在高并发场景下还面临着“伪共享”（False Sharing）问题。

　　现代中央处理器的缓存系统中是以缓存行（Cache Line）为单位存储的，当多线程修改互相独立的变量时，如果这些变量恰好共享同一个缓存行，就会彼此影响（写回、无效化或者同步）而导致性能降低。假设处理器的缓存行大小为64字节，由于一个卡表元素占1个字节，64个卡表元素将共享同一个缓存行。这64个卡表元素对应的卡页总的内存为32KB（64×512字节），也就是说如果不同线程更新的对象正好处于这32KB的内存区域内，就会导致更新卡表时正好写入同一个缓存行而影响性能。

　　为了避免伪共享问题，一种简单的解决方案是不采用无条件的写屏障，而是先检查卡表标记，只有当该卡表元素未被标记过时才将其标记为变脏。在JDK 7之后，HotSpot虚拟机增加了一个新的参数-XX：+UseCondCardMark，用来决定是否开启卡表更新的条件判断。开启会增加一次额外判断的开销，但能够避免伪共享问题，两者各有性能损耗，是否打开要根据应用实际运行情况来进行测试权衡

4.5 图示

 如上图，上面区域是新生代，下面区域是老年代，现在对新生代进行回收。如把老年代分为三个内存区域，对应卡表的三个元素，由于卡页1没有指向新生代的引用，所以记为0，卡页2和卡页3有指向新生代的引用，所以记为1。现在进行GCroots枚举，对象1指向对象2，对象2指向卡页1的里面的对象5，由于卡表1没有变脏，所以不继续从对象5往下扫描，这样子就节省了时间。对象2指向卡页2的对象6，由于对象6所在的卡页2变脏，所以需要继续扫描，对象6指向新生代的对象4，所以把对象4页扫描进来了。

5.并发的可达性分析

为什么必须在一个能保障一致性的快照上才能进行对象图的遍历？

白色：表示对象尚未被垃圾收集器访问过。显然在可达性分析刚刚开始的阶段，所有的对象都是白色的，若在分析结束的阶段，仍然是白色的对象，即代表不可达。

黑色：表示对象已经被垃圾收集器访问过，且这个对象的所有引用都已经扫描过。黑色的对象代表已经扫描过，它是安全存活的，如果有其他对象引用指向了黑色对象，无须重新扫描一遍。黑色对象不可能直接（不经过灰色对象）指向某个白色对象。

灰色：表示对象已经被垃圾收集器访问过，但这个对象上至少存在一个引用还没有被扫描过

当且仅当以下两个条件同时满足时，会产生“对象消失”的问题，即原本应该是黑色的对象被误标为白色：

1）赋值器插入了一条或多条从黑色对象到白色对象的新引用；

2）赋值器删除了全部从灰色对象到该白色对象的直接或间接引用(也可能是本来就没有灰色对象到这个白色对象的链)。

　　一个白色的对象，被已扫描完成的黑色对象引用，同时删除了正在被扫描的对象对它的引用，这样子，这个对象实际上在引用链上，却会被标记为白色-不可达，而实际上这个对象应该是黑色。

　　因此，我们要解决并发扫描时的对象消失问题，只需破坏这两个条件的任意一个即可。由此分别产生了两种解决方案：增量更新（ncremental Update）和原始快照（Snapshot At The Beginning，SATB）。

1）增量更新

　　增量更新要破坏的是第一个条件，当黑色对象插入新的指向白色对象的引用关系时，就将这个新插入的引用记录下来，等并发扫描结束之后，再将这些记录过的引用关系中的黑色对象为根，重新扫描一次。这可以简化理解为，黑色对象一旦新插入了指向白色对象的引用之后，它就变回灰色对象了

2）原始快照

　　原始快照要破坏的是第二个条件，当灰色对象要删除指向白色对象的引用关系时，就将这个要删除的引用记录下来，在并发扫描结束之后，再将这些记录过的引用关系中的灰色对象为根，重新扫描一次。

　　这个我不太理解，如果灰色对象删除指向白色对象的引用关系后，这个白色对象被某个黑色对象引用了。之后再重新扫描这个灰色对象，也扫描不到这个白色对象啊？？？？？？