垃圾收集算法
已经能够确定一个对象为垃圾之后,接下来要考虑的就是回收,怎么回收呢?得要有对应的算法,
下面介绍常见的垃圾回收算法。
标记-清除(Mark-Sweep)
标记
找出内存中需要回收的对象(黑色标记),并且把它们标记出来
此时堆中所有的对象都会被扫描一遍,从而才能确定需要回收的对象,比较耗时
清除
清除掉被标记需要回收的对象,释放出对应的内存空间
缺点
标记清除之后会产生大量不连续的内存碎片,空间碎片太多可能会导致以后在程序运行过程中需要分配较大对象时,无法找到足够的连续内存而不得不提前触发GC。(CMS中的致命问题)
(1)标记和清除两个过程都比较耗时,效率不高
(2)会产生大量不连续的内存碎片,空间碎片太多可能会导致以后在程序运行过程中需要分配较大对象时,无
法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。
标记-复制(Mark-Copying)
将内存划分为两块相等的区域,每次只使用其中一块,如下图所示:
当其中一块内存使用完了,就将还存活的对象复制到另外一块上面,然后把已经使用过的内存空间一次
清除掉。
缺点:
空间利用率降低。
标记-整理(Mark-Compact)
复制收集算法在对象存活率较高时就要进行较多的复制操作,效率将会变低。更关键的是,如果不想浪费50%的空间,就需要有额外的空间进行分配担保,以应对被使用的内存中所有对象都有100%存活的极端情况,所以老年代一般不能直接选用标记-复制算法。
标记过程仍然与"标记-清除"算法一样,但是后续步骤不是直接对可回收对象进行清理,而是让所有存活****的对象都向一端移动,然后直接清理掉端边界以外的内存。
其实上述过程相对"复制算法"来讲,少了一个"保留区"
让所有存活的对象都向一端移动,清理掉边界意外的内存。
分代收集算法
既然上面介绍了3中垃圾收集算法,那么在堆内存中到底用哪一个呢?
Young区:标记-复制算法(对象在被分配之后,可能生命周期比较短,Young区复制效率比较高)
Old区:标记-清除或标记-整理(Old区对象存活时间比较长,复制来复制去没必要,不如做个标记再清理)
Serial Old,Parallel Old:标记整理
CMS:追求停顿时间–>标记清除、
卡表(Card Table)
前置知识
JVM在进行GC时,要对可达对象标记,那么是如何实现寻找的呢?
GC ROOT
记忆集
记忆集是一种用于记录从非收集区域指向收集区域的指针集合的数据结构。
如果我们不考虑效率和成本问题,我们可以用一个数组存储所有有指针指向新生代的老年代对象。但是如果这样的话我们维护成本就很好,打个比方,假如所有的老年代对象都有指针指向了新生代,那么我们需要维护整个老年代大小的记忆集,毫无疑问这种方法是不可取的。因此我们引入了卡表的数据结构
如果是这种情况,如下图
root为根对象,obj1和obj2都间接引用了,那么他们都是可达对象,在进行Young GC时,扫描到root时,会根据引用去寻找old区中的obj1,而这会扫描一次old区!
因为年轻代中发生minor gc的频率很高,如果在经常会扫描年轻代中的对象进行标记,如果老年代中有对象引用了年轻代中的对象,那岂不是每次进行minor gc时也要进行全堆的扫描?嘿嘿,其实不然,jvm引入了卡表(card table)技术来解决这个问题。
一个卡页中可能有多个对象,当存在上述问题时,会把该对象所在的卡页设置为脏卡,那么 扫描时不会扫描整个old区,而是只会扫描这个脏卡。
怎么设置为脏卡?卡表怎么表示的?
BitMap。卡表是一个字节数组,数组的每一项对应着内存中的某一块连续地址的区域,如果该区域中有引用指向了待回收区域的对象,卡表数组对应的元素将被置为1,没有则置为0;
垃圾收集器
如果说收集算法是内存回收的方法论,那么垃圾收集器就是内存回收的具体实现。
Serial
Serial收集器是最基本、发展历史最悠久的收集器,曾经(在JDK1.3.1之前)是虚拟机新生代收集的唯一选择。
它是一种单线程收集器,不仅仅意味着它只会使用一个CPU或者一条收集线程去完成垃圾收集工作,更重要的是其在进行垃圾收集的时候需要暂停其他线程。
优点:简单高效,拥有很高的单线程收集效率
缺点:收集过程需要暂停所有线程
算法:复制算法
适用范围:新生代
应用:Client模式下的默认新生代收集器
Serial Old
Serial Old收集器是Serial收集器的老年代版本,也是一个单线程收集器,不同的是采用"标记-整理算法",运行过程和Serial收集器一样。
ParNew
可以把这个收集器理解为Serial收集器的多线程版本。
优点:在多CPU时,比Serial效率高。
缺点:收集过程暂停所有应用程序线程,单CPU时比Serial效率差。( 因为多线程需要上下文切换)
算法:复制算法
适用范围:新生代
应用:运行在Server模式下的虚拟机中首选的新生代收集器
Parallel Scavenge
Parallel Scavenge收集器是一个新生代收集器,它也是使用复制算法的收集器,又是并行的多线程收集器,看上去和ParNew一样,但是Parallel Scanvenge更关注系统的吞吐量。
吞吐量=运行用户代码的时间/(运行用户代码的时间+垃圾收集时间)
比如虚拟机总共运行了100分钟,垃圾收集时间用了1分钟,吞吐量=(100-1)/100=99%。
若吞吐量越大,意味着垃圾收集的时间越短,则用户代码可以充分利用CPU资源,尽快完成程序的运算任务。
-XX:MaxGCPauseMillis控制最大的垃圾收集停顿时间,
-XX:GCRatio直接设置吞吐量的大小。
Parallel Old
Parallel Old收集器是Parallel Scavenge收集器的老年代版本,使用多线程和标记-整理算法进行垃圾回收,也是更加关注系统的吞吐量。
CMS
针对old区
官网
: https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/cms.html#concurrent_mark_sweep_cms_collectorCMS(Concurrent Mark Sweep)收集器是一种以获取
最短回收停顿时间
为目标的收集器。因为STW是相当耗时的,不能忍受,所以发明了CMS
采用的是"标记-清除算法",整个过程分为4步,"标记整理"更加耗时违背了目标
(1)初始标记 CMS initial mark 标记GC Roots对象,不用Tracing,速度很快 STW
(2)并发标记 CMS concurrent mark (开启GC进程和用户进程)进行GC Roots Tracing,同时用户线程运行产生新的垃圾
(3)重新标记 CMS remark 重新标记2中产生的新垃圾,清除掉已经不是垃圾的却被标记IDE对象 STW
由于在并发标记阶段,用户线程可能修改了一些对象的引用,因此需要重新标记这些在并发标记阶段发生变化的对象。
(4)并发清除 CMS concurrent sweep (开启GC进程和用户进程)清除不可达对象回收空间,同时有新垃圾产生,留着下次清理称为浮动垃圾
CMS的问题
1.对CPU资源敏感
低吞吐量,在并发标记阶段,虽然用户线程和GC线程并发进行,但是GC线程占用了一部分线程,导致用户使用体验卡顿。
2.内存碎片
看3.
3.无法处理浮动垃圾
浮动垃圾:在并发清理过程中,用户线程可能会产生一些垃圾,但是GC线程之前并没有标记它的root。
由于用户线程和GC线程同时运行,而CMS是处理Old区的,在并发清理过程中,CMS要给新来old区的对象留给足够的空间,但我们知道CMS,old区的算法是[标记-清除],会产生很多内存碎片(没有连续的内存空间),
所以新来的对象进入不到Old区,从而触发「 并发失败(Concurrent Mode Failure) 」,此时,JVM就会启动方案:冻结用户线程,启动Serial Old回收器去处理old区的垃圾,而Serial Old会导致STW且停顿时间是相当长的。。。
优点:并发收集、低停顿
缺点:产生大量空间碎片、并发阶段会降低吞吐量
G1(Garbage-First)–分而治之
官网
: https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/g1_gc.html#garbage_first_garbage_collection使用G1收集器时,Java堆的内存布局与就与其他收集器有很大差别,它将整个Java堆划分为多个大小相等的独立区域(Region),虽然还保留有新生代和老年代的概念,但新生代和老年代不再是物理隔离的了,它们都是一部分Region(不需要连续)的集合。
每个Region大小都是一样的,可以是1M到32M之间的数值,但是必须保证是2的n次幂
如果对象太大,一个Region放不下[超过Region大小的50%],那么就会直接放到H中
设置Region大小:-XX:G1HeapRegionSize=M
Garbage-Frist(G1)含义:优先回收垃圾最多的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停顿时间制定回收计划
对于G1收集
如果吞吐量在极限情况下,考虑停顿时间;
什么都不要求,优先设置最大吞吐(95%),降低停顿时间,如果牺牲很小吞吐量可以换来停顿时间吗,那么可以换。
垃圾收集器分类
- 串行收集器->Serial和Serial Old
只能有一个垃圾回收线程执行,用户线程暂停。
适用于内存比较小的嵌入式设备
。
- 并行收集器[吞吐量优先]->Parallel Scanvenge、Parallel Old
多条垃圾收集线程并行工作,但此时用户线程仍然处于等待状态。
适用于科学计算、后台处理等若交互场景
。
- 并发收集器[停顿时间优先]->CMS、G1
用户线程和垃圾收集线程同时执行(但并不一定是并行的,可能是交替执行的),垃圾收集线程在执行的时候不会停顿用户线程的运行。
适用于相对时间有要求的场景,比如Web
。
问题
吞吐量和停顿时间
- 停顿时间->垃圾收集器进行垃圾回收终端应用执行响应的时间
- 吞吐量->运行用户代码时间/(运行用户代码时间+垃圾收集时间)
停顿时间越短就越适合需要和用户交互的程序,良好的响应速度能提升用户体验;
高吞吐量则可以高效地利用CPU时间,尽快完成程序的运算任务,主要适合在后台运算而不需要太多交互的任务。
小结
:这两个指标也是评价垃圾回收器好处的标准。
根据业务情况设置: 如果停顿时间在可控制范围之内优先考虑吞吐量;如果吞吐量在极限情况下,考虑停顿时间;?什么都不要求,优先设置最大吞吐(95%),降低停顿时间,如果牺牲很小吞吐量可以换来停顿时间吗,那么可以换。
如何选择合适的垃圾收集器
https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/collectors.html#sthref28
- 优先调整堆的大小让服务器自己来选择
- 如果内存小于100M,使用串行收集器(Serial系列)
- 如果是单核,并且没有停顿时间要求,使用串行(Serial系列)或JVM自己选
- 如果允许停顿时间超过1秒,选择并行(Paraller 系列)或JVM自己选
- 如果响应时间最重要,并且不能超过1秒,使用并发收集器(CMS、G1)
对于G1收集
如果吞吐量在极限情况下,考虑停顿时间;
什么都不要求,优先设置最大吞吐(95%),降低停顿时间,如果牺牲很小吞吐量可以换来停顿时间吗,那么可以换。
如果吞吐量在极限情况下,考虑停顿时间;
什么都不要求,优先设置最大吞吐(95%),降低停顿时间,如果牺牲很小吞吐量可以换来停顿时间吗,那么可以换。
JDK 7开始使用,JDK 8非常成熟,JDK 9默认的垃圾收集器,适用于新老生代。
是否使用G1收集器?
(1)50%以上的堆被存活对象占用
(2)对象分配和晋升的速度变化非常大
(3)垃圾回收时间比较长
- G1中的RSet
全称Remembered Set,记录维护Region中对象的引用关系
试想,在G1垃圾收集器进行新生代的垃圾收集时,也就是Minor GC,假如该对象被老年代的Region中所引用,这时候新生代的该对象就不能被回收,怎么记录呢?
不妨这样,用一个类似于hash的结构,key记录region的地址,value表示引用该对象的集合,这样就能知道该对象被哪些老年代的对象所引用,从而不能回收。
- 如何开启需要的垃圾收集器
这里JVM参数信息的设置大家先不用关心,后面会学习到。
(1)串行
-XX:+UseSerialGC
-XX:+UseSerialOldGC
(2)并行(吞吐量优先):
-XX:+UseParallelGC
-XX:+UseParallelOldGC
(3)并发收集器(响应时间优先)
-XX:+UseConcMarkSweepGC
-XX:+UseG1GC