【JVM 2】HotSpot VM GC 的种类

今天药忘吃喽~ 2021-08-19 18:10 307阅读 0赞

本系列是用来记录《深入理解Java虚拟机》这本书的读书笔记。方便自己查看，也方便大家查阅。

**欲速则不达，欲达则欲速！**

# 一、collector种类 #

GC在 HotSpot VM 5.0里有四种：

incremental (sometimes called train) low pause collector已被废弃,不在介绍

<table> 
 <tbody> 
 <tr> 
 <td>类别</td> 
 <td>serial collector</td> 
 <td>parallel collector (&nbsp;throughput collector&nbsp;)</td> 
 <td>concurrent collector (concurrent low pause collector)</td> 
 </tr> 
 <tr> 
 <td>介绍</td> 
 <td> 单线程收集器 使用单线程去完成所有的GC工作，没有线程间的通信，这种方式会相对高效 </td> 
 <td> 并行收集器 使用多线程的方式，利用CUP来提高GC的效率，主要以到达一定的吞吐量为目标 </td> 
 <td> 并发收集器 使用多线程的方式，利用多CPU来提高GC的效率，并发完成大部分工作，使得GC pause短 </td> 
 </tr> 
 <tr> 
 <td>试用场景</td> 
 <td>单处理器机器且没有pause time的要求</td> 
 <td> 适用于科学技术和后台处理有中大规模数据集的应用 且运行在多处理器上，关注吞吐量（throughput） </td> 
 <td>适合中规模/大规模数据集大小的应用，应用服务器，电信领域。关注response time，而不是throughput</td> 
 </tr> 
 <tr> 
 <td>使用</td> 
 <td>Client模式下默认 可使用 可用-XX:+UseSerialGC强制使用 优点:对server应用没什么优点 缺点:慢,不能充分发挥硬件资源</td> 
 <td> Server模式下默认 --YGC:PS FGC:Parallel MSC 可用-XX:+UseParallelGC 或-XX:+UseParallelOldGC强制指定 --ParallelGC代表FGC为Parallel MSC --ParallelOldGC代表FGC为Parallel Compacting 优点:高效 缺点:当heap变大后,造成的暂停时间会变得比较长 </td> 
 <td> 可用-XX:+<code>UseConcMarkSweepGC强制指定</code> <code>优点： 对old进行回收时,对应用造成的暂停时间非常短,适合对延迟要求比较高的应用</code> <code>缺点：</code> 1.内存碎片和浮动垃圾 2.old去的内存分配效率低 3.回收的整个耗时比较长 4.和应用争抢CPU </td> 
 </tr> 
 <tr> 
 <td>内存回收触发</td> 
 <td> YGC eden空间不足 FGC old空间不足 perm空间不足 显示调用System.gc() ， 包括RMI等的定时触发 </td> 
 <td>YGC eden空间不足 FGC old空间不足 perm空间不足 显示调用System.gc() ,包括RMI等的定时触发</td> 
 <td> YGC eden空间不足 CMS GC 1.old Gen的使用率大的一定的比率 默认为92% 2.配置了CMSClassUnloadingEnabled,且Perm Gen的使用达到一定的比率 默认为92% 3.Hotspot自己根据估计决定是否要触法 4.在配置了ExplictGCInvokesConcurrent的情况下显示 调用了System.gc. Full GC(Serial MSC) promotion failed 或 concurrent Mode Failure时; </td> 
 </tr> 
 <tr> 
 <td> 内存回收触发 时发生了什么 </td> 
 <td> YGC 清空eden+from中所有no ref的对象占用的内存 将eden+from中的所有存活的对象copy到to中 在这个过程中一些对象将晋升到old中: --to放不下的 --存活次数超过tenuring threshold的 重新计算Tenuring Threshold; 单线程做以上动作 全程暂停应用 FGC 如果配置了CollectGen0First,则先触发YGC 清空heap中no ref的对象,permgen中已经被卸载的classloader 中加载的class的信息 单线程做以上动作 全程暂停应用 </td> 
 <td> YGC 同serial动作基本相同,不同点: 1.多线程处理 2.YGC的最后不仅重新计算Tenuring Threshold,还会重新调整Eden和From的大小 FGC 1.如配置了ScavengeBeforeFullGC(默认),则先触发YGC(??) 2.MSC:清空heap中的no ref对象,permgen中已经被卸载的classloader中加载的 class信息,并进行压缩 3.Compacting:清空heap中部分no ref的对象,permgen中已经被卸载的classloader中加载的 class信息,并进行部分压缩 多线程做以上动作. </td> 
 <td> YGC 同serial动作基本相同,不同点: 1.多线程处理 CMSGC: 1.old gen到达比率时只清除old gen中no ref的对象所占用的空间 2.perm gen到达比率时只清除已被清除的classloader 加载的class信息 FGC 同serial </td> 
 </tr> 
 <tr> 
 <td>细节参数</td> 
 <td>可用-XX:+UseSerialGC强制使用 -XX:SurvivorRatio=x,控制eden/s0/s1的大小 -XX:MaxTenuringThreshold,用于控制对象在新生代存活的最大次数 -XX:PretenureSizeThreshold=x,控制超过多大的字节的对象就在old分配.</td> 
 <td>-XX:SurvivorRatio=x,控制eden/s0/s1的大小 -XX:MaxTenuringThreshold,用于控制对象在新生代存活的最大次数 -XX:UseAdaptiveSizePolicy 去掉YGC后动态调整eden from已经tenuringthreshold的动作 -XX:ParallelGCThreads 设置并行的线程数 </td> 
 <td>XX:CMSInitiatingOccupancyFraction 设置old gen使用到达多少比率时触发 -XX:CMSInitiatingPermOccupancyFraction,设置Perm Gen使用到达多少比率时触发 -XX:+UseCMSInitiatingOccupancyOnly禁止hostspot自行触发CMS GC</td> 
 </tr> 
 </tbody> 
</table>

注：

* throughput collector与concurrent low pause collector的区别是throughput collector只在young area使用使用多线程，而concurrent low pause collector则在tenured generation也使用多线程。
 * 根据官方文档，他们俩个需要在多CPU的情况下，才能发挥作用。在一个CPU的情况下，会不如默认的serial collector，因为线程管理需要耗费CPU资源。而在两个CPU的情况下，也提高不大。只是在更多CPU的情况下，才会有所提高。当然 concurrent low pause collector有一种模式可以在CPU较少的机器上，提供尽可能少的停顿的模式，见**CMS GC Incremental mode**。
 * 当要使用throughput collector时，在java opt里加上-XX:+UseParallelGC，启动throughput collector收集。也可加上-XX:ParallelGCThreads=<desired number>来改变线程数。还有两个参数 -XX:MaxGCPauseMillis=<nnn>和 -XX:GCTimeRatio=<nnn>，MaxGCPauseMillis=<nnn>用来控制最大暂停时间，而-XX: GCTimeRatio可以提高GC说占CPU的比，以最大话的减小heap。

# **二、CMS GC Incremental mode** #

当要使用 concurrent low pause collector时，在java的opt里加上 -XX:+UseConcMarkSweepGC。concurrent low pause collector还有一种为CPU少的机器准备的模式，叫Incremental mode。这种模式使用一个CPU来在程序运行的过程中GC，只用很少的时间暂停程序，检查对象存活。

在Incremental mode里，每个收集过程中，会暂停两次，第二次略长。第一次用来，简单从root查询存活对象。第二次用来，详细检查存活对象。整个过程如下：

* stop all application threads; do the initial mark; resume all application threads（第一次暂停，初始话标记）
    * do the concurrent mark (uses one procesor for the concurrent work)（运行是标记）
    * do the concurrent pre-clean (uses one processor for the concurrent work)（准备清理）
    * stop all application threads; do the remark; resume all application threads（第二次暂停，标记，检查）
    * do the concurrent sweep (uses one processor for the concurrent work)(运行过程中清理)
    * do the concurrent reset (uses one processor for the concurrent work)(复原)

当要使用Incremental mode时，需要使用以下几个变量：

-XX:+CMSIncrementalMode default: disabled 启动i-CMS模式（must with -XX:+UseConcMarkSweepGC）
 -XX:+CMSIncrementalPacing default: disabled 提供自动校正功能
 -XX:CMSIncrementalDutyCycle=<N> default: 50 启动CMS的上线
 -XX:CMSIncrementalDutyCycleMin=<N> default: 10 启动CMS的下线
 -XX:CMSIncrementalSafetyFactor=<N> default: 10 用来计算循环次数
 -XX:CMSIncrementalOffset=<N> default: 0 最小循环次数（This is the percentage (0-100) by which the incremental mode duty cycle is shifted to the right within the period between minor collections.）
 -XX:CMSExpAvgFactor=<N> default: 25 提供一个指导收集数

SUN推荐的使用参数是：

-XX:+UseConcMarkSweepGC \
    -XX:+CMSIncrementalMode \
    -XX:+CMSIncrementalPacing \
    -XX:CMSIncrementalDutyCycleMin=0 \
    -XX:CMSIncrementalDutyCycle=10 \
    -XX:+PrintGC Details \
    -XX:+PrintGCTimeStamps \
    -XX:-TraceClassUnloading
    注：如果使用throughput collector和concurrent low pause collector，这两种垃圾收集器，需要适当的挺高内存大小，以为多线程做准备。

# **三、如何选择collector** #

app运行在单处理器机器上且没有pause time的要求，让vm选择单线程收集器serial collector。

重点考虑peak application performance(高性能)，没有pause time太严格要求，选择并行收集器*parallel collector。*

重点考虑response time,pause time要小，选择并发收集器*concurrent collector。*

*往期精彩内容：*

*[Java知识体系总结（2021版）][Java_2021]*

*[Java多线程基础知识总结][Java]*

*[【全栈最全Java框架总结】SSH、SSM、Springboot][Java_SSH_SSM_Springboot]*

*[超详细的springBoot学习笔记][springBoot]*

*[常见数据结构与算法整理总结][Link 1]*

*[Java设计模式：23种设计模式全面解析][Java_23]*

*[Java面试题总结（附答案）][Java 1]*

[Java_2021]: https://blog.csdn.net/guorui_java/article/details/112391105
[Java]: https://blog.csdn.net/guorui_java/article/details/107599455
[Java_SSH_SSM_Springboot]: https://blog.csdn.net/guorui_java/article/details/104018528
[springBoot]: https://blog.csdn.net/guorui_java/article/details/104137262
[Link 1]: https://blog.csdn.net/guorui_java/article/details/106217472
[Java_23]: https://blog.csdn.net/guorui_java/article/details/104026988
[Java 1]: https://blog.csdn.net/guorui_java/article/details/107803283