一. 前言
今天总结与分享的是垃圾收集算法与垃圾收集器. 有了前几篇的文章的铺垫, 我们知道, 这些知识是Jvm调优的前提, 也是面试时高频提问的重点. 其实说白了, Jvm调优就是尽量减少Full gc, 因为它非常耗时. 而触发Full gc的前提大多是堆内存中的老年代满了, 所以我们需要通过选择垃圾收集器, 调整Jvm内存分代区域大小等方法让大多数对象不进入老年代, 使之在Minor gc时就被回收掉.
二. 垃圾收集算法
Jvm中的垃圾收集算法总共有四种: 复制算法、标记清除算法、标记整理算法、分代收集算法
1. 复制算法
个人习惯, 先上图:
可以看到, 复制算法就是把一整块内存, 平分成两半. 使用时, 只使用其中之一, 垃圾收集时, 直接将有用的对象复制到另一半内存中, 然后清空掉之前使用的这一半内存.
优点: 效率十分之高 缺点: 内存空间使用率低, 能使用的内存只有一半, 1个G就剩512M了.
2. 标记清除算法
图:
我们的标记清除算法很直观, 就是将无用对象标记一下, 然后清除.
优点: 简单 缺点: ① 空间使用率低(几次垃圾收集后, 会产生大量不连续的内存碎片) ② 效率问题(如果内存较大, 需要收集的对象较多, 那么标记与收集将会比较耗时)
3. 标记整理算法
图:
其实标记整理算法和标记清除算法差不多, 只不过它是标记出有用的对象, 然后将这些对象向内存的一端移动. 说不上优缺点, 但肯定, 效率是没有复制算法高的.
####4. 分代收集算法
这其实不是一种算法, 就是之前说的将内存分为不同的区域, 再针对这些区域采用不同的垃圾收集算法. 分区域是指年轻代和老年代, 年轻代又分为3块儿, eden区和2个survivor区. 一般情况下, 年轻代会采用复制算法, 因为有多个区域, 复制算法效率上很占优势. 又因为2个survivor区总共只占用了年轻代的2/10(默认情况下), 所以空间上也没有很大的问题. 老年代一般就是采用标记整理或标记清除算法.
三. 垃圾收集器
常见及常用的垃圾收集器总共有如下五种: Serial收集器、Parallel收集器、ParNew收集器、CMS收集器 和 G1收集器 其中CMS收集器和G1收集器是面试提问的重点, 下面我就来一一描述一下这些垃圾收集器的特点吧.
1. Serial垃圾收集器
图:
Serial垃圾收集器收集垃圾, 会STW(stop the world), 停止掉用户的所有工作线程, 然后开启一个线程收集垃圾. 收集完毕后, 再恢复用户线程的运行.
Serial垃圾收集器可以用在年轻代, 也可以用在老年代. 这是很多年前才会使用的垃圾收集器, 因为它停掉用户线程, 然后却只开了一个线程收集垃圾, 效率可想而知.
如果要使用该垃圾收集器, 可以配置如下参数: 年轻代算法: 复制算法; 年轻代参数: -XX:+UseSerialGC
老年代算法: 标记整理算法; 老年代参数: -XX:+UseSerialOldGC
2. Parallel垃圾收集器
图:
为了优化Serial垃圾收集器的性能, 出现了Parallel垃圾收集器. 但其实并没有提供很高深的优化, 可以看出, 和Serial垃圾收集器过程几乎是一样的, 只不过是在垃圾收集时多加了几个线程.
可以用在年轻代, 也能用在老年代
如果要使用该垃圾收集器, 可以配置如下参数: 年轻代算法: 复制算法; 年轻代参数: -XX:+UseParallelGC 老年代算法: 标记整理算法; 老年代参数: -XX:+UseParallelOldGC
3. ParNew垃圾收集器
图:
可能会有小伙伴儿懵圈儿了...哎? 你这图和Parallel收集器不是一样的吗? 哈哈哈, 确实. ParNew收集器和Parallel收集器的过程是一样的. 区别在于: ParNew只能用在年轻代, 且除了Serial收集器, 只有它能和CMS垃圾收集器配合使用.
如果要使用该垃圾收集器, 可以配置如下参数: 年轻代算法: 复制算法; 年轻代参数: -XX:+UseParNewGC
4. CMS垃圾收集器(重点)
CMS垃圾收集器, 全称Concurrent Mark Sweep. 从名字就可以看出它不简单, 并发标记清除. 它是第一款真正意义上并发的垃圾收集器, 并不是说它就不stop the world了.而是说它可以一边收集垃圾, 一边运行应用程序. 还是先看图再解释吧:
这个可就比前面说的垃圾收集器复杂多了, 而且整个垃圾收集过程分为了五个阶段: 初始标记、并发标记、重新标记、并发清理、并发重置 下面详细说说这几个阶段的事.
1. 初始标记: 停止应用程序线程, 开启一个回收线程标记非垃圾对象. 使用可达性分析算法(前几篇文章讲过), 但只会标记GC Roots, 所以速度非常快.
2. 并发标记: 恢复工作线程, 与回收线程并发执行. 接着上一阶段的GC Roots继续向下标记, 这个过程的耗时非常长, 几乎可以占到整个垃圾收集过程的80%. 由于没有停止工作线程, 所以可能会发生标记的非垃圾对象在下一时刻又变成垃圾的问题.
3. 重新标记: 又停机工作线程. 因为并发标记阶段可能产生一些标记错误, 所以这一阶段主要是修复这些错误的标记. 如: 上一阶段标记的非垃圾对象, 这一时刻已经失去引用, 又沦为了垃圾对象.
4. 并发清理: 恢复工作线程, 启动回收线程, 清理掉未被标记的垃圾对象. 可能有同学会疑惑, 工作线程恢复了, 那不是又会有新的对象产生, 那这新产生的对象也没被标记, 会不会被回收掉呢? 答案是肯定不会, 不然CMS收集器没人敢用了. 在这个阶段新产生的对象会被直接标记. 具体下面的三色标记算法会讲到.
5. 并发重置: 这一阶段很简单, 就是将之前的标记清除掉.从以上阶段可以看处, 这个CMS收集器, 把整个垃圾收集过程打散了. 这样就使得用户的感知没那么明显. 把这个时间放大个几十上百倍来理解就是...本来是一次性等10秒, 现在却变成了总体十分钟, 每分钟等1秒. 当然..垃圾收集的过程是很快的, 可能整个才耗时1秒左右, 这里不过是放大了收集时间, 便于理解.
关于CMS收集器必须要注意的是, 它可能会并发失败. 什么是并发失败? 因为垃圾收集和应用程序是并发执行的. 就有可能发生垃圾收集时, 应用程序又在不断的new对象, 导致老年代放满, 又触发了full gc. 这时, CMS不会再走前面说的阶段, 而是采用本文介绍的第一个垃圾收集器: Serial收集器来收集垃圾. 所以为避免这种情况的发生, 可以使用参数来调整老年代触发full gc的内存占用比例, 比如调成80%就触发full gc, 这样在并发清理时, 应用程序新new的对象把剩下的内存占满的概率就会大大降低了.
CMS收集器只能用在老年代, 采用的是标记清除算法(会产生内存碎片, 可通过参数设置整理内存碎片) 优点: 分散垃圾收集过程, 用户体验好. 缺点: 收集线程会抢占cpu资源; 无法处理浮动垃圾(并发收集时产生的垃圾); 采用标记清除算法, 会产生内存碎片(不连续的内存空间)
CMS核心参数:
- -XX:+UseConcMarkSweepGC：启用cms
- -XX:ConcGCThreads：并发的GC线程数
- -XX:+UseCMSCompactAtFullCollection：FullGC之后进行压缩整理
- -XX:CMSFullGCsBeforeCompaction：多少次FullGC之后压缩一次, 默认是0, 代表每次FullGC后都会压缩一次
- -XX:CMSInitiatingOccupancyFraction: 当老年代使用达到该比例时会触发FullGC（默认是92, 这是百分比）
- -XX:+UseCMSInitiatingOccupancyOnly：只使用设定的回收阈值(上一参数设定的值), 如果不指定, Jvm仅在第一次使用设定值，后续又会自动调整.
- -XX:+CMSScavengeBeforeRemark：在CMS GC前先进行一次minor gc，目的在于减少老年代对年轻代的引用，降低CMS GC的标记阶段时的开销，一般CMS的GC耗时 80%都在标记阶段.
- -XX:+CMSParallellnitialMarkEnabled：表示在初始标记的时候多线程执行
- -XX:+CMSParallelRemarkEnabled：在重新标记的时候多线程执行
- 更多参数请自行百度 ^^
5. G1垃圾收集器
想了想, 还是放在下一篇文章写吧. 下面先说说收集器的标记算法.
四. 垃圾收集器底层算法-三色标记算法
我们之前说过可达性分析算法标记非垃圾对象的过程, 这个可达性分析算法已经详细讲解过了, 就是根据gc roots向下查找并标记非垃圾对象. 那这个标记具体是怎么做的呢? 其实底层就是接下来要将的三色标记算法了, 老规矩, 先上图:
三色标记算法根据对象的扫描完整度, 分为了黑灰白三种颜色:
- 黑色: 已经将一个对象的全部成员变量扫描完毕.
- 灰色: 已经扫描过该对象, 但是还未将对象的全部变量扫描完毕.
- 白色: 还未扫描过该对象.
以上图说明:
- 对象A包含了对象B和对象C两个成员变量, 并将B和C都扫描到了, 所以将A对象标记为黑色.
- 对象B没有成员变量, 直接标记为黑色
- 对象C包含对象D和对象E两个成员变量, 但只扫描了D对象, 并未来得及扫描E对象, 所以此时C对象的颜色被标记为灰色.
- 对象E还未来得及扫描, 所以是初始颜色: 白色(后续会扫描到)
- 所以垃圾回收主要收集的颜色就是白色, 也就是可达性分析算法扫描结束后, 并未被标记的对象.
看上去好像设计的相当好, 可也存在一些问题:
前面我们说过CMS收集器是一款..收集线程和应用程序线程并发执行的垃圾收集器, 那么它就不可避免的会产生一些"浮动垃圾". 所谓浮动垃圾就是在可达性分析算法标记非垃圾对象后, 因为应用程序线程的同步运行, 这部分非垃圾对象失去引用又变成了垃圾对象的一种现象. 对于CMS, 它是无法完全清理这部分对象的. 这种现象也被称之为**"多标"**, 就是多标记了.
其实还有一种少标记了的情况, 也称为**"漏标"**. 多标还好, 只是有一部分垃圾在这一次垃圾回收时无法清理掉, 在下一次垃圾回收时就没问题了. 可是对于漏标, 那问题就严重了, 因为我们的可达性分析算法是对标记的对象不进行被回收. 那么, 漏标的非垃圾对象如果被回收了...可想而知, 我们的程序处处都是空指针异常.
那漏标是怎么产生的呢? 假设我们有A, B两种类型的对象...还是看图吧...
由上图可以一句话总结: 漏标就是因为应用程序线程和收集线程的并行, 导致已标记为黑色对象的引用指向了未标记完成的对象上.
多标和漏标如何解决?
针对多标和漏标, Jvm提供了两种解决方式: 一叫做增量更新, 二叫做原始快照.
增量更新: 在并发收集过程中, 将每一次引用变更的对象重新标记为灰色, 这样一来, 在并发标记阶段结束后, 在重新标记阶段开始时, 会将这些对象重新扫描并标记. 由于重新标记是会停止用户线程的, 所以在重新标记结束时, 内存就不存在任何一个为白色的非垃圾对象. 注意: 新new的对象会被直接标记为黑色.
原始快照: 在并发收集过程中, 将每一次引用变更的白色对象都标记成黑色. 这样就彻底避免了漏标的情况, 不过可能会产生大量的浮动垃圾.
增量更新和原始快照底层是怎么做的呢?
其实Jvm底层运用了读写屏障, 此处的读写屏障并不是内存中的读写屏障. 而是类似于AOP一样的思想, 再引用的变更前后, 对该引用做了一些手脚. 如将其以另外的形式保存起来.
增量更新: 在引用变更前, 利用写屏障将引用保存起来. 在重新标记阶段重新扫描引用对象所在的根节点.
原始快照: 在引用变更前, 利用写屏障将引用保存起来. 在重新标记阶段直接将保存的引用对象标记为黑色.
不同的垃圾收集器, 底层采用了不同的实现:
- CMS采用的是增量更新
- 下篇文章将要讲的G1采用的是原始快照
- 至于为什么? 可能是因为G1的内存分散, 对象处于不同的region, 如果采用增量更新, 扫描起来付出的性能较大. 而CMS的老年代处于一块独立的内存, 使用增量更新虽然也会重新扫描变更引用的对象, 但相较于G1性能开销会节省很多, 且能处理掉更多的浮动垃圾.
ok, 今天的知识总结就到这里. 如果有写的不对的地方, 仍然希望小伙伴儿们能不吝赐教~
