为什么初始标记停顿时间与堆大小无关，只与GCROOTS的数量相关

问题如标题所示，复习到Shenandoah收集器时，关于初始标记，书中的描述是：

• 与G1一样，首先标记与GC Roots直接关联的对象，这个阶段仍是“Stop The World”的，但停顿时间与堆大小无关，只与GC Roots的数量相关。

上面强调了红字描述的内容，先了解下GC Roots对象包括那些内容：

• 所有虚拟机栈的所有栈桢中的本地变量表中引用的对象，譬如各个线程被调用的方法中使用的参数、局部变量、临时变量等。
• 在方法区中类静态属性引用的对象，譬如Java类的引用类型静态变量。
• 在方法区中常量引用的对象。
• 在本地方法栈中JNI（即通常所说的Native方法）引用的对象。
• Java虚拟机内部的引用，如基本数据类型对应的Class对象，一些常驻的异常对象（比如NullPointException、OutOfMemoryError）等，还有系统类加载器。
• 所有同步锁（synchronized关键字）持有的对象。
• 反映Java虚拟机内部情况的JMXBean、JVMTI中注册的回调、本地代码缓存等。

以上是基本描述信息，收集器标记的GC Roots可能会在以上描述基础上增加GC Roots对象范围，比如CMS进行老年代收集时，会把年轻代对象作为GC Roots对象进行处理。不同收集器的GC Roots不尽相同。该文章以Shenandoah为重点关注对象。与Shenandoah相同的地方可以参考思考，不同的地方需要自己额外去探索。

列举具体情况比较，相同的应用，cpu不变，系统环境相同、应用请求量也是一样的，堆内存变大，注G1和Shenandoah收集器年轻代和老年代不是物理隔离，不存在设置年轻代和老年代堆大小问题。

4核cpu     2g堆内存      app1(相同的应用)

4核cpu    8g堆内存      app2(相同的应用)

质疑的问题是：app2、app1触发垃圾回收时，app2堆中的对象数量肯定比app1多，那么app2堆中的GCRoots对象也比app1堆中的多。说明堆内存变大，GCRoots数量增多，初始标记时间变长。与文中描述的不一致。

 

大家先思考下以上描述，先看是否认同以上说法，如果不认同思考下原因。

 

开始解答：以上的描述前半句是对的，app2、app1触发垃圾回收时，app2堆中的对象数量肯定比app1多。然而GCRoots对象却没有增加。

首先，GC Roots中的内容变化频繁的肯定是虚拟机栈，线上每一次请求都会创建一个虚拟机栈，请求中的方法便是栈桢，压入到栈中，方法执行过程中会在堆中创建对象，栈桢中局部变量引用指向创建的对象。

但是虚拟机栈（包括本地方法栈）是线程私有的，也就是说线程执行结束后，该线程的虚拟机栈就会被释放，此时堆中留下上次线程创建的对象，由于该线程的虚拟机栈释放掉了，这些对象没有引用指向。虚拟机栈都不存在，这些对象当然也不会计入到GC Roots对象集合中。

就是说GCRoots对象只与当前正在执行的线程数有关（即应用的请求数量），这就为什么上面强调线上请求量也是一样的，

就是app1和app2在垃圾回收时，都是当前各有1000个线程在执行，假设1000个是相同的线程，那么这两拨线程的虚拟机栈关联的GCRoots都是一样的。

 

以上就是全部内容，如有什么疑问，请及时留言。