这是我参与11月更文挑战的第19天，活动详情查看：2021最后一次更文挑战

前言

来了来了，之前填的坑，现在都要补回来，之前的篇章我们讲了GC回收器回收之前需要判断垃圾，判断垃圾回收的算法有两个，一个是引用计数法，java虚拟机不采用这种，第二种可达性分析法，目前商用GC都采用这个。

垃圾探测

之前的篇章我们讲过GC的垃圾探测可达性分析法，需要遍历每个GC Roots来实现一致性，如果数量对象引用数量非常多，这个根节点枚举就会非常耗时，注意耗时也就算了，此时已经进入了GC的范畴了，这样就意味着虚拟机已经开始GC过程了，他要通知其他线程这个时候你们不准继续工作了，都必须给我暂停，当然这里的暂停也就是线程都要进入安全点， 这时候用户线程都被停止了，等于触发了STW，在加上根节点枚举的时间过长，好家伙你这虚拟机基本就是要宕机一会了，这一会对于WEB应用程序来说是非常致命的打击。

OOPMAP

JVM中的事故是非常不好找到问题的，所以才需要大家对JVM有一定的基础，就是为了防止这种事情的发生。为了避免。当然java的dalao们也是早就发现了这个情况，他们提出了特别多的方案来解决这个问题。首先是OOPMap，因为GC root 会涉及到所有的对象都进行遍历，这也就包括了老年代，而老年代引用的年轻代一般年轻代都会随着GC次数也会进入老年代，这是跨代应用的假说，OOpmap在特定的位置记录下栈里和寄存器里哪些位置是引用，实现其细节是使用了类似Spring 的AOP切面编程思想的写屏障，他有用写前屏障 与 写后屏障。用于记录在OopMap中的引用。

下一篇章我们继续讲解根节点枚举 与 安全点的故事。