JVM垃圾收集器（1）

亦凉 2022-04-11 13:57 223阅读 0赞

此文已由作者赵计刚薪授权网易云社区发布。

欢迎访问[网易云社区][Link 1]，了解更多网易技术产品运营经验。

说明：垃圾回收算法是理论，垃圾收集器是回收算法的实现，关于回收算法，见《[第四章 JVM垃圾回收算法][JVM]》

**1、七种垃圾收集器**

*  Serial（串行GC）-- 复制
 *  ParNew（并行GC）-- 复制
 *  Parallel Scavenge（并行回收GC）-- 复制
 *  Serial Old（MSC）（串行GC）-- 标记-整理
 *  CMS（并发GC）-- 标记-清除
 *  Parallel Old（并行GC）--标记-整理
 *  G1（JDK1.7update14才可以正式商用）

说明：

*  1~3用于年轻代垃圾回收：年轻代的垃圾回收称为minor GC
 *  4~6用于年老代垃圾回收（当然也可以用于方法区的回收）：年老代的垃圾回收称为full GC
 *  G1独立完成"分代垃圾回收"

注意：并行与并发

*  并行：多条垃圾回收线程同时操作
 *  并发：垃圾回收线程与用户线程一起操作

**2、常用五种组合**

*  Serial/Serial Old
 *  ParNew/Serial Old：与上边相比，只是比年轻代多了多线程垃圾回收而已
 *  ParNew/CMS：当下比较高效的组合
 *  Parallel Scavenge/Parallel Old：自动管理的组合
 *  G1：最先进的收集器，但是需要JDK1.7update14以上

**2.1、Serial/Serial Old：**

![20181206152012d5965914-0626-46ff-b642-d053c6572cf0.jpg][]

**特点：**

*  年轻代Serial收集器采用单个GC线程实现"复制"算法（包括扫描、复制）
 *  年老代Serial Old收集器采用单个GC线程实现"标记-整理"算法
 *  Serial与Serial Old都会暂停所有用户线程（即STW）

**说明：**

*  STW（stop the world）：编译代码时为每一个方法注入safepoint（方法中循环结束的点、方法执行结束的点），在暂停应用时，需要等待所有的用户线程进入safepoint，之后暂停所有线程，然后进行垃圾回收。

适用场合：

*  CPU核数<2，物理内存<2G的机器（简单来讲，单CPU，新生代空间较小且对STW时间要求不高的情况下使用）
 *  \-XX:UseSerialGC：强制使用该GC组合
 *  \-XX:PrintGCApplicationStoppedTime：查看STW时间

**2.2、ParNew/Serial Old：**

![201812061520228ee1e2a7-9553-4612-94aa-a899fb31f54f.jpg][]

**说明：**

*  ParNew除了采用多GC线程来实现复制算法以外，其他都与Serial一样，但是此组合中的Serial Old又是一个单GC线程，所以该组合是一个比较尴尬的组合，在单CPU情况下没有Serial/Serial Old速度快（因为ParNew多线程需要切换），在多CPU情况下又没有之后的三种组合快（因为Serial Old是单GC线程），所以使用其实不多。
 *  \-XX:ParallelGCThreads：指定ParNew GC线程的数量，默认与CPU核数相同，该参数在于CMS GC组合时，也可能会用到

**2.3、Parallel Scavenge/Parallel Old：**

![2018120615203200d46b55-874a-4489-96ad-f3277611d62b.jpg][]

**特点：**

*  年轻代Parallel Scavenge收集器采用多个GC线程实现"复制"算法（包括扫描、复制）
 *  年老代Parallel Old收集器采用多个GC线程实现"标记-整理"算法
 *  Parallel Scavenge与Parallel Old都会暂停所有用户线程（即STW）

**说明：**

*   吞吐量：CPU运行代码时间/(CPU运行代码时间+GC时间)
 *  CMS主要注重STW的缩短（该时间越短，用户体验越好，所以主要用于处理很多的交互任务的情况）
 *  Parallel Scavenge/Parallel Old主要注重吞吐量（吞吐量越大，说明CPU利用率越高，所以主要用于处理很多的CPU计算任务而用户交互任务较少的情况）

**参数设置：**

*  \-XX:+UseParallelOldGC：使用该GC组合
 *  \-XX:GCTimeRatio：直接设置吞吐量大小，假设设为19，则允许的最大GC时间占总时间的1/(1+19)，默认值为99，即1/(1+99)
 *  \-XX:MaxGCPauseMillis：最大GC停顿时间，该参数并非越小越好
 *  \-XX:+UseAdaptiveSizePolicy：开启该参数，-Xmn/-XX:SurvivorRatio/-XX:PretenureSizeThreshold这些参数就不起作用了，虚拟机会自动收集监控信息，动态调整这些参数以提供最合适的的停顿时间或者最大的吞吐量（GC自适应调节策略），而我们需要设置的就是-Xmx，-XX:+UseParallelOldGC或-XX:GCTimeRatio两个参数就好（当然-Xms也指定上与-Xmx相同就好）

**注意：**

*  \-XX:GCTimeRatio和-XX:MaxGCPauseMillis设置一个就好
 *  不开启-XX:+UseAdaptiveSizePolicy，-Xmn/-XX:SurvivorRatio/-XX:PretenureSizeThreshold这些参数依旧可以配置，以resin服务器为例
    
                    <jvm-arg>-Xms2048m</jvm-arg>
                    <jvm-arg>-Xmx2048m</jvm-arg>
                    <jvm-arg>-Xmn512m</jvm-arg>
                    <jvm-arg>-Xss1m</jvm-arg>
                    <jvm-arg>-XX:PermSize=256M</jvm-arg>
                    <jvm-arg>-XX:MaxPermSize=256M</jvm-arg>
                    <jvm-arg>-XX:SurvivorRatio=8</jvm-arg>
                    <jvm-arg>-XX:MaxTenuringThreshold=15</jvm-arg>
        
                    <jvm-arg>-XX:+UseParallelOldGC</jvm-arg>
                    <jvm-arg>-XX:GCTimeRatio=19</jvm-arg>
        
                    <jvm-arg>-XX:+PrintGCDetails</jvm-arg>
                    <jvm-arg>-XX:+PrintGCTimeStamps</jvm-arg>

适用场合：

*  很多的CPU计算任务而用户交互任务较少的情况
 *  不想自己去过多的关注GC参数，想让虚拟机自己进行调优工作

**2.4、ParNew/CMS**

![2018120615204366f9e4fd-f6dc-4cd3-8282-1eb781468ade.jpg][]

**说明：**

*  以上只是年老代CMS收集的过程，年轻代ParNew看"2.2、ParNew/Serial Old"就好
 *  CMS是多回收线程的，不要被上图误导，默认的线程数：(CPU数量+3)/4
 *  CMS主要注重STW的缩短（该时间越短，用户体验越好，所以主要用于处理很多的交互任务的情况）

**特点：**

*  年轻代ParNew收集器采用多个GC线程实现"复制"算法（包括扫描、复制）
 *  年老代CMS收集器采用多线程实现"标记-清除"算法
    
     *  初始标记：标记与根集合节点直接关联的节点。时间非常短，需要STW
     *  并发标记：遍历之前标记到的关联节点，继续向下标记所有存活节点。时间较长。
     *  重新标记：重新遍历trace并发期间修改过的引用关系对象。时间介于初始标记与并发标记之间，通常不会很长。需要STW
     *  并发清理：直接清除非存活对象，清理之后，将该线程占用的CPU切换给用户线程
 *  初始标记与重新标记都会暂停所有用户线程（即STW），但是时间较短；并发标记与并发清理时间较长，但是不需要STW

关于并发标记期间怎样记录发生变动的引用关系对象，在重新标记期间怎样扫描这些对象，见《[第六章 JVM垃圾收集器（2）][JVM_2]》

缺点：

*  并发标记与并发清理：按照说明的第二点来讲，假设有2个CPU，那么其中有一个CPU会用于垃圾回收，而另一个用于用户线程，这样的话，之前是两CPU运行用户线程，现在是一个，那么效率就会急剧下降。也就是说，降低了吞吐量（即降低了CPU使用率）。
 *  并发清理：在这一过程中，产生的垃圾无法被清理（因为发生在重新标记之后）
 *  并发标记与并发清理：由于是与用户线程并发的，所以用户线程可能会分配对象，这样既可能对象直接进入年老代（例如，大对象），也可能进入年轻代后，年轻代发生minor GC，这样的话，实际上要求我们的年老代需要预留一定空间，也就是说要在年老代还有一定空间的情况下就要进行垃圾回收，留出一定内存空间来供其他线程使用，而不能等到年老代快爆满了才进行垃圾回收，通过-XX:CMSInitiatingOccupancyFraction来指定当年老代空间满了多少后进行垃圾回收，如果在回收过程中，老年代已经不够使用了，这时候CMS回收失败，老年代使用serial Old进行GC
 *  标记-清理算法：会产生内存碎片，由于是在老年代，可能会提前触发Full GC（这正是我们要尽量减少的）

**参数设置：**

*  \-XX:+UseConcMarkSweepGC：使用该GC组合
 *  \-XX:CMSInitiatingOccupancyFraction：指定当年老代空间满了多少后进行垃圾回收
 *  \-XX:+UseCMSCompactAtFullCollection：（默认是开启的）在CMS收集器顶不住要进行FullGC时开启内存碎片整理过程，该过程需要STW
 *  \-XX:CMSFullGCsBeforeCompaction：指定多少次FullGC后才进行整理
 *  \-XX:ParallelCMSThreads：指定CMS回收线程的数量，默认为：(CPU数量+3)/4

适用场合：

*  用于处理很多的交互任务的情况
 *  方法区的回收一般使用CMS，配置两个参数：-XX:+CMSPermGenSweepingEnabled与-XX:+CMSClassUnloadingEnabled

**3、一些经验**

*  由于当下大型企业用的比较多的还是jdk1.6版本，所以G1用的还是不多
 *  用得最多的两种：ParNew/CMS和Parallel Scavenge/Parallel Old
 *  Full GC的四种情况
    
     *  增大survivor区
     *  增大年老区
     *  调低-XX:CMSInitiatingOccupancyFraction
     *  设置：-XX:CMSMaxAbortablePrecleanTime=5(单位:ms)，防止CMS在重新标记很久后才进行并发清理
     *  增大方法区
     *  使用CMS GC回收方法区
     *  不要创建过大的对象获数组
     *  尽量让对象在minor GC被回收
     *  让对象在年轻代多存活一段时间，可能这段时间内就会被minor GC回收
     *  旧生代空间不足
     *  方法区满了
     *  CMS GC中promotion failed（minor GC时，survivor区放不下，年老区也放不下）和concurrent mode failure
     *  空间担保机制（这一块儿见《深入理解Java虚拟机（第二版）》P98）

附：具体的配置参数查看《深入理解Java虚拟机（第二版）》P90

[免费领取验证码、内容安全、短信发送、直播点播体验包及云服务器等套餐][Link 2]

更多网易技术、产品、运营经验分享请[点击][Link 1]。

相关文章：  
【推荐】 [微服务监控探索][Link 3]

[Link 1]: https://sq.163yun.com/blog?tag=M_tg_904_72
[JVM]: http://www.cnblogs.com/java-zhao/p/5183261.html
[20181206152012d5965914-0626-46ff-b642-d053c6572cf0.jpg]: /images/20220411/75bb8fb1063144f084665459f89a6b7b.png
[201812061520228ee1e2a7-9553-4612-94aa-a899fb31f54f.jpg]: /images/20220411/e93eb097fd184c56be421e43c3f094a0.png
[2018120615203200d46b55-874a-4489-96ad-f3277611d62b.jpg]: /images/20220411/df161c5b65f24b7dadafe332f4a3d919.png
[2018120615204366f9e4fd-f6dc-4cd3-8282-1eb781468ade.jpg]: /images/20220411/34853bcb2ed84bbc83fe2638f9810df6.png
[JVM_2]: http://www.cnblogs.com/java-zhao/p/5183999.html
[Link 2]: https://www.163yun.com/free?tag=M_tg_904_72
[Link 3]: https://blog.csdn.net/wangyiyungw/article/details/81776804