一,常用的垃圾收集器
如果说收集算法是内存回收的方法论,那么垃圾收集器就是内存回收的具体实现。
如下图为年轻代和老年代的垃圾回收器,划线表示可以同时存在。
1,Serial
Serial收集器是最基本、发展历史最悠久的收集器,曾经(在JDK1.3.1之前)是虚拟机新生代收集的唯一选择。
它是一种单线程收集器,不仅仅意味着它只会使用一个CPU或者一条收集线程去完成垃圾收集工作,更重要的是其在进行垃圾收集的时候需要暂停其他线程。
优点:简单高效,拥有很高的单线程收集效率缺点:收集过程需要暂停所有线程算法:复制算法适用范围:新生代应用:Client模式下的默认新生代收集器
2,Serial Old
Serial Old收集器是Serial收集器的老年代版本,也是一个单线程收集器,不同的是采用"标记-整理算 法",运行过程和Serial收集器一样。
3,ParNew
可以把这个收集器理解为Serial收集器的多线程版本
优点:在多CPU时,比Serial效率高。缺点:收集过程暂停所有应用程序线程,单CPU时比Serial效率差。算法:复制算法适用范围:新生代应用:运行在Server模式下的虚拟机中首选的新生代收集器
4,Parallel Scavenge
Parallel Scavenge收集器是一个新生代收集器,它也是使用复制算法的收集器,又是并行的多线程收集器看上去和ParNew一样,但是Parallel Scanvenge更关注系统的吞吐量。
吞吐量=运行用户代码的时间/(运行用户代码的时间+垃圾收集时间)比如虚拟机总共运行了100分钟,垃圾收集时间用了1分钟,吞吐量=(100-1)/100=99%。若吞吐量越大,意味着垃圾收集的时间越短,则用户代码可以充分利用CPU资源,尽快完成程序的运算任务。
-XX:MaxGCPauseMillis控制最大的垃圾收集停顿时间
-XX:GCRatio直接设置吞吐量的大小
5,Parallel Old
Parallel Old收集器是Parallel Scavenge收集器的老年代版本,使用多线程和标记-整理算法进行垃圾回 收,也是更加关注系统的吞吐量。
6,CMS
官网 : https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/cms.html#con
current_mark_sweep_cms_collector
CMS(Concurrent Mark Sweep)收集器是一种以获取 最短回收停顿时间为目标的收集器。 采用的是"标记-清除算法",整个过程分为4步
(1)初始标记 CMS initial mark 标记GC Roots直接关联对象,不用Tracing,速度很快(2)并发标记 CMS concurrent mark 进行GC Roots Tracing(3)重新标记 CMS remark 修改并发标记因用户程序变动的内容(4)并发清除 CMS concurrent sweep 清除不可达对象回收空间,同时有新垃圾产生,留着下次清理称为浮动垃圾由于整个过程中,并发标记和并发清除,收集器线程可以与用户线程一起工作,所以总体上来说, CMS收集器的内存回收过程是与用户线程一起并发地执行的。
优点:并发收集、低停顿缺点:产生大量空间碎片、并发阶段会降低吞吐量
7,G1(Garbage-First)
官网 : https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/g1_gc.html#ga rbage_first_garbage_collection
使用G1收集器时,Java堆的内存布局与就与其他收集器有很大差别,它将整个Java堆划分为多个
大小相等的独立区域(Region),虽然还保留有新生代和老年代的概念,但新生代和老年代不再
是物理隔离的了,它们都是一部分Region(不需要连续)的集合。
每个Region大小都是一样的,可以是1M到32M之间的数值,但是必须保证是2的n次幂
如果对象太大,一个Region放不下[超过Region大小的50%],那么就会直接放到H中
设置Region大小:-XX:G1HeapRegionSize=M
所谓Garbage-Frist,其实就是优先回收垃圾最多的Region区域
(1)分代收集(仍然保留了分代的概念)(2)空间整合(整体上属于“标记-整理”算法,不会导致空间碎片)(3)可预测的停顿(比CMS更先进的地方在于能让使用者明确指定一个长度为M毫秒的时间片段内,消耗在垃圾收集上的时间不得超过N毫秒)
工作过程可以分为如下几步
初始标记(Initial Marking) 标记以下GC Roots能够关联的对象,并且修改TAMS的值,需要暂 停用户线程
并发标记(Concurrent Marking) 从GC Roots进行可达性分析,找出存活的对象,与用户线程并发执行最终标记(Final Marking) 修正在并发标记阶段因为用户程序的并发执行导致变动的数据,需暂停用户线程筛选回收(Live Data Counting and Evacuation) 对各个Region的回收价值和成本进行排序,根据 用户所期望的GC停顿时间制定回收计划
8,ZGC
官网 : https://docs.oracle.com/en/java/javase/11/gctuning/z-garbage-collector1.html#GUID -A5A42691-095E-47BA-B6DC-FB4E5FAA43D0
JDK11新引入的ZGC收集器,不管是物理上还是逻辑上,ZGC中已经不存在新老年代的概念了
会分为一个个page,当进行GC操作时会对page进行压缩,因此没有碎片问题
只能在64位的linux上使用,目前用得还比较少。
(1)可以达到10ms以内的停顿时间要求(2)支持TB级别的内存(3)堆内存变大后停顿时间还是在10ms以内
二,垃圾收集器分类
垃圾收集器分类
- 串行收集器
Serial
和
Serial Old
只能有一个垃圾回收线程执行,用户线程暂停。
适用于内存比较小的嵌入式设备
。
- 并行收集器[吞吐量优先]
Parallel Scanvenge
、
Parallel Old
多条垃圾收集线程并行工作,但此时用户线程仍然处于等待状态。
适用于科学计算、后台处理等若交互场景
。
- 并发收集器[停顿时间优先]
CMS
、
G1
用户线程和垃圾收集线程同时执行
(
但并不一定是并行的,可能是交替执行的
)
,垃圾收集线程在执行的时 候不会停顿用户线程的运行。
适用于相对时间有要求的场景,比如
Web
。