垃圾回收器是垃圾回收算法的具体实现。
由于垃圾回收器分为年轻代和老年代,除了G1
之外其他垃圾回收器必须成对组合
进行使用
垃圾回收器的组合使用关系图如下。
常用的组合如下:
Serial(新生代)
+Serial Old(老年代)
ParNew(新生代)
+CMS(老年代)
Parallel Scavenge(新生代)
+Parallel Old(老年代)
Serial
是一种单线程串行回收年轻代
的垃圾回收器,使用"复制算法
"
优点:单CPU处理器下吞吐量非常出色
缺点:多CPU下吞吐量不如其他垃圾回收器,堆如果偏大会让用户线程处于长时间的等待
适用场景:Java编写的客户端程序或者硬件配置有限的场景
SerialOld
是Serial垃圾回收器的老年代
版本,采用单线程串行回收
,采用"标记-整理算法
"
启动参数:-XX:+UseSerialGC 新生代、老年代都使用串行回收器
优点:单CPU处理器下吞吐量非常出色
缺点:多CPU下吞吐量不如其他垃圾回收器,堆如果偏大会让用户线程处于长时间的等待
适用场景:与Serial
垃圾回收器搭配使用,或者在CMS
特殊情况下使用
ParNew
垃圾回收器本质上是对Serial在多CPU下的优化,使用多线程
进行年轻代
垃圾回收,采用"复制算法
"
启动参数:-XX:+UseParNewGC
新生代使用ParNew
回收器, 老年代使用串行回收器(Serial Old
)
优点:多CPU处理器下停顿时间较短
缺点:吞吐量和停顿时间不如G1,所以在JDK9之后不建议使用
适用场景:JDK8及之前的版本中,与CMS老年代垃圾回收器搭配使用
关注系统的暂停时间
,允许用户线程和垃圾回收线程在某些步骤中同时执行,减少了用户线程的等待时间。适用老年代
,采用"标记-清除算法
"(实际是标记整理)
启动参数:XX:+UseConcMarkSweepGC
老年代使用CMS垃圾回收器
优点:系统由于垃圾回收出现的停顿时间较短
,用户体验好
缺点:1、内存碎片问题 2、退化问题 3、浮动垃圾问题
适用场景:大型的互联网系统中用户请求数、数据量大、频率高
的场景,比如订单接口、商品接口等
CMS执行步骤:
1)初始标记,用极短的时间标记出GC Roots能直接关联到的对象。
2)并发标记, 标记所有的对象,用户线程不需要暂停。
3)重新标记,由于并发标记阶段有些对象会发生了变化,存在错标、漏标等情况,需要重新标记。
4)并发清理,清理死亡的对象,用户线程不需要暂停。
缺点:
1、CMS使用了标记-清除
算法,在垃圾收集结束之后会出现大量的内存碎片,CMS会在Full GC时进行碎片的整理。这样会导致用户线程暂停,可以使用-XX:CMSFullGCsBeforeCompaction=N 参数(默认0)
调整N次Full GC之后再整理。
2.、无法处理在并发清理过程中产生的“浮动垃圾”(即并发清理的时候,用户线程仍在进行而产生的垃圾对象),不能做到完全的垃圾回收。
3、如果老年代内存不足无法分配对象,CMS
就会退化成Serial Old单线程
回收老年代。
在CMS中并发阶段运行时的线程数可以通过
-XX:ConcGCThreads
参数设置,默认值为0,由系统计算得出。
计算公式为(-XX:ParallelGCThreads定义的线程数 + 3) / 4
,ParallelGCThreads
是STW
停顿之后的并行线程数
ParallelGCThreads是由处理器核数决定的:
1、当cpu核数小于8时,ParallelGCThreads = CPU核数
2、否则ParallelGCThreads = 8 + (CPU核数 – 8 )*5/8
由于CPU的核心数有限,就会影响用户线程执行的性能
Parallel Scavenge
是JDK8
默认的年轻代
垃圾回收器,多线程
并行回收,关注的是系统的吞吐量
。具备自动调整堆内存大小的特点。适用年轻代
,采用"复制算法
"
优点:吞吐量高,而且手动可控。为了提高吞吐量,虚拟机会动态调整堆的参数
缺点:不能保证单次的停顿时间
适用场景:后台任务,不需要与用户交互,并且容易产生大量的对象比如:大数据的处理,大文件导出
Parallel Scavenge
允许手动设置最大暂停时间和吞吐量。Oracle官方建议在使用这个组合时,不要设置堆内存的最大值,垃圾回收器会根据最大暂停时间和吞吐量自动调整内存大小。
最大暂停时间:-XX:MaxGCPauseMillis=n
设置每次垃圾回收时的最大停顿毫秒数(默认不设置)
吞吐量:-XX:GCTimeRatio=n
设置吞吐量为n(用户线程执行时间 = n/n + 1)(默认99)
自动调整内存大小:-XX:+UseAdaptiveSizePolicy
设置可以让垃圾回收器根据吞吐量和最大停顿的毫秒数自动调整内存大小(默认开启)
Parallel Old
是JDK8
默认的老年代
垃圾回收器,Parallel Old
是为Parallel Scavenge
收集器设计的老年代
版本,利用多线程
并发收集。适用老年代,采用"标记-整理算法
"
启动参数: -XX:+UseParallelGC
或-XX:+UseParallelOldGC
这两个参数可以设置为使用 Parallel Scavenge + Parallel Old
这种组合
优点:并发收集,在多核CPU下效率较高
缺点:暂停时间会比较长
使用场景:与Parallel Scavenge配套使用
JDK8默认会带启动参数 -XX:+UseParallelGC
,也就是PS+PO组合(图8)。Oracle官方建议在使用这个组合时,不要设置堆内存的最大值,垃圾回收器会根据最大暂停时间和吞吐量自动调整内存大小
JDK9
之后默认的垃圾回收器是G1
(Garbage First
)垃圾回收器。由于Parallel Scavenge
关注吞吐量,允许用户设置最大暂停时间 ,但是会减少年轻代可用空间的大小。CMS
关注暂停时间,但是吞吐量方面会下降。而G1设计目标就是将上述两种垃圾回收器的优点融合:
1)支持巨大的堆空间回收,并有较高的吞吐量。
2)支持多CPU并行垃圾回收。
3)允许用户设置最大暂停时间。
JDK9之后强烈建议使用G1垃圾回收器。
G1出现之前的垃圾回收器,堆内存结构一般是连续的。如下:
而G1的堆内存结构如下:
G1的整个堆会被划分成多个大小相等的区域,称之为区(Region),区域不要求是连续的。分为Eden、Survivor、Old
区。Region的大小通过堆空间大小/2048计算得到,也可以通过参数-XX:G1HeapRegionSize=32m
指定(其中32m指定region大小为32M),Region size
必须是2的指数幂,取值范围从1M到32M。
G1垃圾回收有两种方式:年轻代回收和混合回收
Young GC
)回收Eden区和Survivor区中不用的对象。会导致STW。G1中可以通过参数 -XX:MaxGCPauseMillis=n(默认200)
设置每次垃圾回收时的最大暂停时间毫秒数,G1垃圾回收器会尽可能地保证暂停时间。
G1垃圾回收器 – 执行流程:
Eden
区。当G1判断年轻代区不足(max默认60%),无法分配对象时需要回收时会执行Young GC
。Eden
和Survivor
区域中的存活对象,Survivor
区中(年龄+1),清空这些区域。G1在进行Young GC的过程中会去记录每次垃圾回收时每个Eden区和Survivor区的平均耗时,以作为下次回收时的
参考依据。这样就可以根据配置的最大暂停时间计算出本次回收时最多能回收多少个Region区域了。
比如 -XX:MaxGCPauseMillis=n(默认200),每个Region回收耗时40ms,那么这次回收最多只能回收4个Region。
后续Young GC
时与之前相同,只不过Survivor
区中存活对象会被搬运到另一个Survivor
区。
当某个存活对象的年龄到达阈值(默认15),将被放入老年代。
部分对象如果大小超过Region的一半,会直接放入老年代,这类老年代被称为Humongous区
。比如堆内存是4G,每个Region
是2M,只要一个大对象超过了1M就被放入Humongous区,如果对象过大会横跨多个Region
。
Old
老年代区,此时总堆占有率达到阈值时(-XX:InitiatingHeapOccupancyPercent
默认45%)会触发混合回收MixedGC
。回收所有年轻代和部分老年代的对象以及大对象区。采用复制算法
来完成。混合回收分为四个阶段(图4):初始标记(nitial mark
)、并发标记(concurrent mark
)、最终标记(remark
或者Finalize Marking
)、并发清理(cleanup
)
G1对老年代的清理会选择存活度最低的区域来进行回收,这样可以保证回收效率最高,这也是G1
(Garbage first
)名称的由来。
最后清理阶段使用复制算法,不会产生内存碎片。
注意:如果清理过程中发现没有足够的空Region存放转移的对象,会出现Full GC
。单线程执行标记-整理算法,此时会导致用户线程的暂停。所以尽量保证应该用的堆内存有一定多余的空间。
G1 – Garbage First 垃圾回收器 回收年轻代+老年代
采用复制算法
启动参数:
参数1: -XX:+UseG1GC
打开G1的开关,JDK9之后默认不需要打开
参数2:-XX:MaxGCPauseMillis=毫秒值
最大暂停的时间
优点:对比较大的堆如超过6G的堆回收时,延迟可控。不会产生内存碎片,并发标记的SATB算法效率高
缺点:JDK8之前还不够成熟
适用场景:JDK8最新版本、JDK9之后建议默认使用
线程不共享区:程序计数器、Java虚拟机栈、本地方法栈,不需要回收,跟随线程的生命周期随着线程回收而回收
线程共享区域:主要回收堆区域。方法区一般不需要回收,JSP等技术会通过回收类加载器去回收方法区。
强引用,最常见的引用方式,由可达性分析算法来判断
软引用,对象在没有强引用情况下,内存不足时会回收
弱引用,对象在没有强引用情况下,会直接回收
虚引用,通过虚引用知道对象被回收了
终结器引用,对象回收时可以自救,不建议使用
标记-清除算法 Mark Sweep GC
:标记之后再清除,容易产生内存碎片
复制算法Copying GC
:从一块区域复制到另一块区域(From中存活对象复制到To),容易造成只能使用一部分
标记-整理算法Mark Compact GC
:标记之后将存活的对象推到一边,对象会移动,效率不高
分代GC Generational GC
:将内存区域划分成年轻代、幸存者区、老年代进行回收,可以使用多种回收算法
JDK8及之前:
1)ParNew + CMS
:关注暂停时间。暂停时间较短,适用于大型互联网应用中与用户交互的部分
2)Parallel Scavenge + Parallel Old
:关注吞吐量。吞吐量高,适用于后台进行大量数据操作
3)G1
:JDK8之前不建议,较大堆并且关注暂停时间。适用于较大的堆,具有可控的暂停时间
4)Serial + Serial Old
:单线程回收,主要适用于单核CPU场景(不推荐,目前基本为多核服务器)
JDK9之后:
1)G1
:JDK9之后,G1日趋成熟,JDK默认的垃圾回收器已经修改为G1,所以强烈建议在生产环境使用G1。
其他几种组合,官方已废弃,不推荐