有问题地阅读垃圾回收时，是否需要暂停非GC线程的线程？ 内存那么大，HotSpot怎么快速找到对象？
指南判断虚拟机如何利用可达性算法，是否需要回收某个对象，而HotSpot在实现该算法时，为了保证虚拟机的有效运行，对算法的运行效率要求很严格那么，HotSpot如何实现呢？
本文是Effective Java专栏Java虚拟机主题的第五集。 如果你觉得阅读后对你有帮助，请订阅本专栏。 也欢迎你把这个专栏分享给你身边的工程师同学。
在听这门课之前，我们建议您了解以下知识点：
什么是可达性分析算法？
快速找到GC路线
可达性分析算法首先需要找到GC Roots (什么是GC Roots？ 那么，如何在那么大的内存中找到适合GC Roots的对象呢？ 如果每次GC时都需要遍历所有内存，必然会消耗很多时间。
在GC期间，需要知道除GC线程以外的其他线程必须被冻结。 (是否需要修复、STW与垃圾收集器策略有关(why-does-the-JVM-full-GC-need-to-stop-the-world ) )，出现GC进程对象引用关系那么，相对于GC Roots，HotSpot是如何迅速确定的呢？
这时，出现了精确的GC的作用，它采用称为Stop The World的数据结构来存储对象引用的位置。 因此，在GC时，虚拟机不需要在广袤的内存大海中寻找引用，只需要拥有一个名为OopMap的词典，就可以快速地寻找所有的引用，确定GC roots (GC roots )
安全点通过OopMap，HotSpot可以立即完成GC Roots的搜索。 但是，如果代码中的每一行都可能出现GC，则必须为代码中的每一行指令生成OopMap，这会占用大量空间。 其实，HotSpot也不会那样做。
HotSpot只在特定的位置记录了OopMap。 这些位置称为OopMap。 也就是说，程序并不是可以随时停止进行GC，只能在达到安全点后进行。 安全点通常出现在方法调用、循环跳转和异常跳转等命令中。
发生GC时，虚拟机将中断标志设置为true，各线程在运行时，到达安全点后自行轮询该标志，发现中断标志为true时自行进行中断挂起； 否则，继续执行。
安全区域中的上述安全点在线程正常运行的前提下是有效的。 如果线程处于安全点（Safepoint）或sleep的状态，则无法进入安全点挂起，但JVM无法等待线程恢复正常
安全区域是指在一个代码片段中，blocked保持不变，而安全区域（Safe Region）
当线程进入Safe Region时，首先识别自己进入了Safe Region。 这样，当HotSpot启动GC时，就不需要管理这些安全区域中的线程。 当线程离开Safe Region时，检查系统是否完成了GC。 某些垃圾收集器可能只需要检查GC Roots查找是否已完成。 如果完成，线程将继续。 否则，继续等待，直到收到安全离开Safe Region的信号。
该课程介绍了HotSpot实现可达性分析算法时的算法，并说明了OopMap、安全点、安全区域等概念。 通过这两个讲座，你知道垃圾回收是怎么开始的，开始后是怎么回收的吗？ 这是接下来要说的内容。
上节课后，考题答案为——“GC开始后，是否需要暂停GC线程以外的线程？ 为什么？ ”
答案正如在本演讲中已经提到的，在GC期间，GC线程以外的其他线程必须被冻结，GC进程对象的引用关系不能不断变化。 因此，在GC正在进行时，所有Java执行线程(Sun称为“Stop The World”)。
想想看。 如果在GC期间没有其他线程暂停，则对于这两行代码：
obj=null；
obj=new Object (；
obj.dosomething (；
代码执行到第1行时，GC线程将obj标记为需要回收，但此时其他线程不暂时中断，继续执行第2行的代码，执行后，GC在回收对象中巡回回收obj。 接下来发生的事情很了解——NullPointerException吧。
参考资料《深入理解Java虚拟机》 tsdlz