JVM-垃圾收集器

垃圾收集器
收集算法是内存回收的方法论,垃圾收集器是内存回收的具体实现
Java虚拟机规范中没有对垃圾收集器做任何规定所以不同厂商不同版本虚拟机的垃圾收集器差别很大。这里讨论jdk1.7的 hotspot虚拟机
下图上边是新生代收集器,下边是老年代收集器,连线表示可以搭配使用。
在这里插入图片描述
serial收集器
serial 收集器时最基本、发展历史最悠久的收集器。只能使用一个CPU一个线程去完成垃圾收集工作。收集时必须暂停其他所有工作线程。
在这里插入图片描述
优势:简单而高效, 对于单个CPU来说没有线程交互开销,效率高。适合嵌入式内存小配置低的情况。

parNew 收集器

ParNew收集器是serial收集器的多线程版本,除了使用多线程进行垃圾收集之外,其余的行为包括serial 收集器可用控制参数(-XX:survivorRatio-XX:PretenureSizeThreshold–XX:HandlePromotionFailure)、收集算法、StopTheWorld 、对象分配规则、回收策略等都与serial收集器完全一样
在这里插入图片描述
parNew 在单核的环境中效果肯定没有serial好但是随着可以使用的CPU数量的增加,对于GC时系统资源的有效利用还是很有好处的。 -XX:parallelGCThreads参数控制垃圾回收的线程数。
jdk.1.5中使用cms 来收集老年代,新生代只能选parNew或者Serial中的一个。
并行:多条垃圾收集线程并行工作,用户线程处于等待装填
并发:用户线程和垃圾收集线程同时执行

Parallel Scavenges收集器
是一个新生代收集器,也是使用复制算法,也是并行的都线程收集器。
特点:它的关注点和其他收集器不同CMS等收集器关注点是尽可能缩短垃圾收集时用户线程的停顿时间,而它的目标是达到一个可控制的吞吐量,
吞吐量=运行用户代码时间/(运行用户代码时间+垃圾收集时间)
两个参数控制吞吐量
-XX:MaxGCPauseMills-最大垃圾收集停顿时间 大于0 的毫秒数
-XX:GCTimeRatio设置吞吐量的大小 0-100的整数 是吞吐量的倒数 99 的话 吞吐量为 1/(1+99) =1%
-XX:+UseAdaptiveSizePolicy. 这是一个开关参数,打开之后不需要手工指定新生代的大小 -Xmn Eden 和 Survivo 的比例,晋升老年代的年龄 等细节参数了,虚拟机会自动根据监控信息动态调整

serial Old 收集器
是serial 的老年代版本, 单线程收集器 标记整理算法。
如果再 Server 模式下有两大用途:
在jdk1.5及以前的版本中与parallel Scavenge收集器搭配使用,另一种用途就是作为CMS收集器的后背预案在并发手机发生时使用
在这里插入图片描述

parallel Old 收集器
是parallelScavenge 收集器的老年代版本,多线程 、标记整理算法
这个收集器时jdk1.6才提供的,之前新生代的parallel Scavenge 收集器一直处于比较尴尬的状态.一旦新生代选择了 PS收集器,老年代除了ServialOld 别无选择。由于老年代 serial Old 收集器在服务端应用性能上的拖累使得 PS收集器也未必能在整体应用上获得吞吐量最大化的效果。 直到 parallelOld 出现后 吞吐量优先的收集器终于有了名副其实的应用组合。
在注重吞吐量以及CPU资源敏感的场合,可以考虑 pS PO收集器。

在这里插入图片描述

CMS 收集器
CMS 收集器 是一种获取最短回收停顿时间为目标的收集器
目前很大一部分java应用集中在互联网站或者BS系统服务端上。重视响应速度,能带给用户较好的体验。
基于 标记清除算法。 整个过程分为4步
初始标记
会stop the word
初始标记仅仅是标记下GCRoots 能直接关联到的对象 速度很快
并发标记
并发标记就是进行GCRoots tracing 的过程
重新标记
会stop the word
是为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录,时间比初始标记稍长,但比并发标记时间短。由于并发标记过程和用户线程一起执行所以 总体上说,CMS回收过程和用户线程是并发执行的并发清除。

CMS是一款优秀的收集器:
优势:并发收集、低停顿、
缺点:对CPU资源敏感、无法处理浮动垃圾、产生垃圾碎片
所以当发现老年代最大连续空间,小于新生代每次垃圾收集移动到老年代对象大小的平均值时,就会启用 SerialOld 收集器做一次标记整理收集。这样就减少了碎片的数量。-XX:CMSFullGCsBeforeCompaction 配置执行多少次不压缩FullGC后 来一次带压缩的 0 表示每次都压

G1 收集器
是当今收集器技术发展的最前沿成果。 被视作jdk1.7中hotspot 虚拟机的一个重要进化特征。
G1是一款面向服务端应用的垃圾收集器 使命是:未来替换掉jdk1.5中发布的cms 收集器,
G1 特点:
并行与并发:充分利用多CPU来缩短 stw时间
分代收集:
空间整合:G1整体来看基于标记-整理
可预测停顿:降低停顿是G1和CMS共同的关注点但是G1除了追求低停顿还能建立可预测的停顿时间模型

如果不计算维护remembered set 的操作 G1收集操作分为以下几个步骤
初始标记
标记下 GC Roots 能直接关联到的对象并修改TAMS的值
需要停顿 耗时短
并发标记
从GC root开始对堆中对象进行可达性分析,找出存活对象,耗时长,可与用户线程并行执行

最终标记
是为了修正在并发标记期间因用户程序继续运作而导致标记产生变动的那一部分标记记录。 虚拟机将这段时间对象变化记录在线程remembered set logs 里面 。最终标记阶段需要把 rsl 中的数据合并到 remembered set 中
需要停顿线程,但是可以并行执行。
筛选回收
首先对各个region 的回收成本进行排序,根据用户期望的回收时间制定回收计划,
可以并发执行,但是停顿用户线程效率更高。

收集器总结:
串行收集器:Serial SerialOld 简单高效单线程 。适合 嵌入式中使用。
并行收集器:parNew、 Parallel Scavenges、Parallel Old 。Parallel适用于吞吐量优先的情况,比如科学计算。
并发收集器:CMS G1 并发收集,stw时间最短。适用于Web应用。用户体验好

工作原理对比图:
在这里插入图片描述

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

catch that elf

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值