对jvm中 GC Roots 枚举的理解 javajvmgc垃圾回收机制

对 GC Roots 枚举的理解啥是 GC Roots ？凡是有堆外引用的对象，都是 GC Root。
局部变量（栈里）、静态变量和常量（方法区里），它们都是堆外的，只要引用了对象，那这个对象就是 GC Root ，就会被加入GC Roots 集合。

设想，这个世界上还没有垃圾收集器，而我想要发明一个，那遇到的第一个问题就是，我该如何判断一个对象是否已经死了。有一个方法，就是从当前肯定活着的对象入手。如果，我能把所有活着的对象找齐了，那剩下的就是死的了，逻辑上就是这么简单。对于活对象，我更愿意称它们为有用的对象，因为这更能表达它不应该被清理的特征。

只要两个条件，就可以找到jvm里所有，有用的对象：
1、栈、方法区等，非堆的内存区域，持有的对象。

堆里存了所有的对象，它们就像仓库里的工具，只有被使用才是有用的。被哪里使用呢？被堆外的其他区域。

2、第一个条件里的对象，在堆内使用的所有对象。

使用的意思是，它调用的对象，所调用的对象，所调用的对象...（套娃中）。是一个调用链。

GC Roots 就是为了实现第一个条件，它要找到所有被堆外区域引用的对象。
可达性分析，就是为了实现第二个条件，它要找到 GC Roots 所使用的所有对象。

GC Roots 枚举的过程 stop the world GC Roots 枚举，必然需要暂停所有用户线程。

原因很好理解：GC Roots 枚举时，统计的就是 堆外 引用的对象。只拿栈中来说，如果客户线程依旧在运行，那么统计过程中，不断有栈帧出栈和入栈。新入栈的栈帧，其中的局部变量，也有可能是不会被统计到 GC Roots 里。（看完OopMap的机制，再更新详细内容）

safe point 在任何时候，都可以暂停用户线程。为啥要设置 safe point ？
理解这个问题，可能需要先搞懂 OopMap，但是，我的理解暂时还不透彻，所以只能笼统的讲。
用户线程暂停后，接下来会进行 GC Roots 枚举，而 GC Roots 枚举，却依赖 OopMap 存储的信息。但是，OppMap 不能每时每刻都更新数据，因为那样的话，对资源的消耗就太大了。
所以，要给 OopMap 更新数据，找一个节点，这个节点就是 safe point 。
【对jvm中 GC Roots 枚举的理解】在选取 safe point 时，只会选择在循环、调用、递归 。。。这是为什么呢？
JVM暂停用户线程的时候，都是采用 主动式暂停 ，所以以下就用 主动式暂停 来讨论。当 "stop the world"发生时，线程应该尽快跑到安全点，然后停下来。如果在选取安全点的时候，选在了 循环语句 的后面，那就太蠢了，白白增加了停顿时间。所以，肯定应该选在 循环语句 运行之前，基本就是在这个 循环语句 的地方。
总结，就是安全点的选择，会在长时间运行的地方，比如 循环、调用 等地方。并在这些代码运行之前，暂停线程，避免浪费时间。

safe region
safe region 是 safe point 的补丁。
如果，在 "stop the world" 发生时，有些用户线程没有运行，比如 sleep 了。那么，这条线程，在 "stop the world" 发生时，它不是运行状态，所以它并不能自行跑到安全点，并中断线程。而是，一直停在了非安全点的位置，一旦获取了时间片，它还是要运行的。
可能会在，下一个致命的时期，也就是 GC Roots 枚举时，这条线程如果又跑起来了。
那这个漏洞就太大了。
所以，又引入了 safe region，来补这个漏洞。

当用户线程执行到安全区域里面的代码时,首先会标识自己已经进入了安全区域,那样当这段时间里虚拟机要发起垃圾收集时就不必去管这些已声明自己在安区域内的线程了。
当线程要离开安全区域时,它要检查虚拟机是否已经完成了根节点枚举(或者垃圾收集过程中其他需要暂停用户线程的阶段),如果完成了,那线程就当作没事发生过,继续执行; 否则它就必须一直等待,直到收到可以离开安全区域的信号为止。
——摘抄自《深入理解java虚拟机》第三版

总结
GC Roots 枚举前。首先，要暂停用户线程，会使用 safe point 和 safe ragion ，辅助暂停用户线程。然后，开始 GC Roots 枚举，并不会去遍历方法区、栈里的引用，而是，直接从OopMap里获取引用。