如果说收集算法是内存回收的方法论,那么垃圾收集器就是内存回收的具体实现。Java虚拟机规范中对垃圾收集器应该如何实现并没有任何规定,因此不同的厂商、不同版本的虚拟机所提供的垃圾收集器都可能会有很大差别。这里仅讨论HotSpot虚拟机中的垃圾收集器。
HotSpot虚拟机的所有收集器如下:
新生代收集器:Serial、ParNew、Parallel Scavenge
老年代收集器:CMS、Serial Old(MSC)、Parallel Old
整堆收集器:G1
图中连线的收集器表示可以搭配使用,Serial Old 可以作为CMS出现(Concurrent Mode Failed)失败的后备方案
指多条垃圾收集线程并行工作,但此时用户线程仍然处于等待态。
如:ParNew、Parallel Scavenge、Parallel Old;
指用户线程与垃圾收集线程同时执行(但不一定是并行的,可能会交替执行),用户程序在继续运行,而垃圾收集程序运行于另一个CPU上。
Serial/Serial Old组合收集器运行过程,Serial在新生代使用复制算法收集,Serial Old在老年代使用标记-整理收集
ParNew是Serial收集器的多线程版本,除了使用多条线程进行垃圾收集意外,其余行为包括Serial收集器可用的所有控制参数(例如:-XX:SurvivorRatio、-XX:PretenureSizeThreshold、-XX:HandlePromotionFailure等)、收集算法、Stop The World、对象分配规则、回收策略等都与Serial收集器一样
ParNew/Serial Old组合收集器运行过程如下:
在Server模式下,ParNew是一个非常重要的收集器,因为除了Serial外,只有ParNew能够和CMS进行组合。
Parallel Scavenge垃圾收集器因为与吞吐量关系密切,也称为吞吐量优先收集器(Throughput Collector)。
吞吐量:CPU运行于用户代码的时间与CPU总消耗时间的比值,即吞吐量=运行用户代码时间/(运行用户代码时间 + 垃圾收集时间)
停顿时间越短就越适合需要与用户交互的程序,良好的响应速度能提升用户体验,而高吞吐量则可以高效率地利用CPU时间,尽快完成程序的运算任务,主要适合后台运算而不需要太多交互的任务。
Parallel Scavenge收集器提供两个参数用于精确控制吞吐量:
还有一个-XX:+UseAdptiveSizePolicy参数,相当于一个开关,参数打开之后,GC自适应的调节策略,不用手工指定一些细节参数,如新生代的大小(-Xmn)、Eden与Survivor区的比例(-XX:SurvivorRation)、晋升老年代的对象年龄(-XX:PretenureSizeThreshold)等;
主要用于Client模式;
而在Server模式有两大用途:
Parallel Old是Parallel Scavengeh收集器的老年代版本。,在JDK1.6中开始提供
Parallel Scavengeh/Parallel Old收集器工作过程如下:
在注重吞吐量以及CPU资源敏感的场合,都可以优先考虑Parallel Scavengeh/Parallel Old收集器
CMS是一种以获取最短回收停顿时间为目标的收集器,也叫做并发低停顿收集器
是HotSpot在JDK1.5推出的第一款真正意义上的并发(Concurrent)收集器;第一次实现了让垃圾收集线程与用户线程(基本上)同时工作;
由于整个过程中耗时最长的并发标记和并发清除过程收集器线程都是和用户线程一起工作,所以总体上来说,CMS收集器的内存回收过程是与用户线程一起并发执行的。
并发收集虽然不会导致用户线程停顿,但是会占用一部分线程(或者CPU资源),会导致应用程序变慢,总吞吐量降低。CMS的默认收集线程数量是=(CPU数量+3)/4;当CPU数量多于4个,收集线程占用的CPU资源多于25%,对用户程序影响可能较大;不足4个时,影响更大,可能无法接受。
解决方案:采用增练市并发收集器,类似使用抢占式来模拟多任务机制的思想,让收集线程和用户线程交替运行,减少收集线程运行时间。但是效果不理想,JDK1.6后被弃用。
由于CMS并发清理阶段用户线程还在运行着,伴随程序运行自然就还会有新的垃圾不断产生,这部分垃圾在标记过程之后,CMS无法再档次收集集中处理掉它们,只好留待到下一次GC时处理,这就是“浮动垃圾”。
由于在垃圾收集阶段用户线程还需要运行,那也就需要预留有足够的内存空间给用户线程使用,因此CMS收集器不能想起他收集器那样等到老年代几乎完全被填满了在进行收集,需要预留一部分 空间提供并发收集时的程序运作使用。
解决方案:CMS运行期间预留的内存无法满足程序需要,就会出现一次“Concurrent Mode Failed”失败,这时候虚拟机将启动后备预案:临时启用Serial Old收集器来重新进行老年代的垃圾收集,这样收集时间就比较长了。
空间碎片产生太多,无法找到足够大的连续空间来分配当前对象,提前触发一次Full GC。
解决方案:CMS提供了一个-XX:+UseCMSCompactAtFullCollection开关参数(默认是开启的),用于CMS收集器在顶不住要记性Full GC时,开启内存碎片合并整理过程。内存整理过程是无法并发的,停顿时间变长。
与用户交互较多的场景,希望系统停顿时间最短,注重服务的响应速度,以给用户带来较好的体验,如常见WEB、B/S系统的服务器上的应用;
G1是一款面向服务端应用的垃圾收集器。
G1收集器将整个Java堆内存划分为多个大小相等的区域(Region),虽然还保留有新生代和老年代的概念,但是新生代和老年代不在是物理隔离的了,它们都是一部分Region的集合。
这就保证了再有限时间内可以获取尽可能稿的收集效率。
标记一下GC Roots能直接关联到的对象
可达性分析,耗时较长,按时可以与用户线程并发,
修正在并发标记期间因用户线程继续运作而导致标记产生变动的那一部分标记记录。
对各个Region回收价值和成本进行排序,根据用户所期望的GC停顿时间来定制回收计划。可以与用户程序并发进行,但是因为指挥手一部分Region,时间用户可控制的,停顿用户线程将大幅度提高收集效率,所以不需要并发。
不同区之间的对象引用问题、不同年代对象引用问题。
问题描述:一个Region不可能是孤立的,不同Region之间存在互相引用,判断对象是否存活,是否要扫描整个Java堆才能保证正确。
其他垃圾收集器也存在类似的问题:回收新生代是否需要扫描老年代,从而降低Minor GC效率。
解决方案:使用Remembered Set避免全堆扫描
G1中每个区都有一个Remembered Set,在对Reference类型数据进行写操作时,就会产生一个Write Barrier暂时中断写操作,检查Reference引用的对象是否处于不同的Region(在分代中是否老年代中的对象引用了新生代的对象),如果是,便将相关引用记录到被饮用对象所属的Region的Remembered Set之中,在GC根节点的枚举范围中加入Remembered Set即可保证不对全堆扫描也不会有遗漏。
面向服务端应用,针对具有大内存、多处理器的机器;
最主要的应用是为需要低GC延迟,并具有大堆的应用程序提供解决方案;
原文地址:https://www.cnblogs.com/wangziqiang123/p/11696919.html