JVM 垃圾回收器

垃圾回收算法:

标记 - 清除:清除垃圾速度最佳,但是含有碎片。

复制算法: 以空间换取时间。

标记 - 整理:相当于标记清理加上双指针整理。

Stop-The-World:GC停顿,用户工作线程全部暂停。

吞吐量 :运行业务代码时间 /(运行业务代码时间 + 垃圾回收时间)

暂停时间 :暂停所有业务线程,只运行其垃圾回收线程的时间

补充: 为什么暂停时间和吞吐量不能兼得。

场景:业务代码相同,业务单位时间生产的垃圾对象相同

吞吐量优先:假设业务代码执行99秒,那么产生的垃圾对象就是99x(x为单位时间产生的垃圾对象),垃圾回收必须回收完99x的垃圾回收量,最优选择是:前面99s全部给业务代码,执行完后进行只运行垃圾线程回收垃圾,我只需要进行一次标记,然后回收,就可以完成垃圾回收,我就不需要考虑多次标记然后回收,那么暂停时间就会增加(内存充足,足以容纳99x的垃圾量)。

暂停时间优先(暂停时间少):同理业务代码执行99秒,那么产生的垃圾对象就是99x,最优选择是:在业务代码运行的时候,就进行并发的标记清理(标记清理过程中必要时进行暂停所有用户线程),但是需要考虑清理垃圾线程运行中是否重新产生垃圾和垃圾清理错误问题,而进行多次标记清理,需要的垃圾回收时间就会增多,吞吐量就会就会减小(内存较小,空间需要及时清理)。

响应时间:与暂停时间不同,是指一个请求响应到返回时间。与吞吐量比较,若是我刚好在99s之后发送请求,那么我将会等待垃圾回收运行完成之后才进行响应。所以可以得出,吞吐量优先是指在一段时间内,专注与完成业务代码。但是响应时间优先不允许长时间的暂停时间,则与吞吐量有一定的矛盾,但是不是绝对矛盾(吞吐量优先,没有进行垃圾回收时,响应速度应该是最快的)。

垃圾回收器根据内存模型可以分为:

分代模型:

新生代收集器(复制算法)  Serial,ParNew,Parallel Scavenge

老年代收集器 SerialOld ,Parallel Old ,CMS

分区模型:G1

Serial收集器:历史最悠久的收集器,针对于年轻代,串行收集器,

特点:收集垃圾时,会暂停所有用户线程并且是单线程,没有线程交互,专心收集垃圾,单线程收集效率高。

适用场景:单个CPU,并且内存足够,不需要频繁发生垃圾收集的应用。

ParNew收集器:针对于年轻代,Serial升级版,并行(多线程收集垃圾)收集器

特点:收集垃圾时,会暂停所有用户线程并且是多线程收集,有线程交互,多线程收集效率高。

适用场景:多个CPU(单核CPU效率没有Serial高),并且内存足够,不需要频繁发生垃圾回收的应用。

Parallel Scavenge收集器:与ParNew收集器收集时采用策略相同,采用的垃圾收集框架不同,但是更加关注与吞吐量(关注吞吐量不代表吞吐量最好,需要根据自己的应用和计算机决定,只是关注于是吞吐量优先)。

特点 :可以设置最大垃圾回收时间,和垃圾收集时间占比总时间比率(相当于吞吐量)。

适用场景:多个CPU,注重吞吐量以及CPU资源敏感,需要自己控制的吞吐量应用。

Serial Old收集器:针对于老年代的收集器,串行收集器

特点:与Serial相同,采用算法不一致,使用标记整理算法

适用场景:与Serial一致

Parallel Old收集器:针对于老年代的收集器,并行收集器

特点:与Parallel相同,采用算法不一致,使用标记整理算法

适用场景:与Parallel一致

CMS 收集器:针对于老年代收集器,并发收集器

特点:最短停顿时间为目标的收集器,收集过程相对于前面几种比较复杂,采用标记清除,含有内存碎片,需要单独配置整理参数。

适用场景:注重服务的响应速度,停顿时间最短,给用户良好体验的应用。

G1收集器:取消分代回收,采用分区策略。

特点:可并发,可并行,可以利用多核CPU来缩短暂停时间。

适用场景:大内存,多处理的机器,主要应用于服务端应用,GC低延迟。

  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值