垃圾收集器总览
收集器名称 | 收集器特点 | 新生代特点 | 老年代特点 | 适合场景 |
---|
Serial收集器 | 全程单线程、简单高效、会触发STW | 复制算法 | - | 客户端JVM | ParNew收集器 | 多线程收集回收但仍要STW、其余和Serial无太大区别 | 复制算法 | 标记整理算法 | 服务端JVM | Parallel Scavenge | 聚焦高吞吐量 | 复制算法 | _ | 服务端JVM | Serial Old | 单线程 作为Serial收集器老年代版本,会在CMS并发失败时使用 | - | 标记整理算法 | 服务端JVM | Parallel Old | 多线程回收,配合ParNew一起工作 | - | 标记整理算法 | 服务端JVM | CMS | 聚焦最短停顿时间、追求响应速度、可以与用户线程并发执行但会产生一些垃圾碎片 | - | 标记清理 算法 | 服务端JVM | Garbage first | 低停顿,可预测的停顿、并发回收 | 局部标记复制总体标记整理 | 局部标记复制总体标记整理 | 服务端JVM |
垃圾收集器搭配
横线上方是主要作用于年轻代收集器下方是主要作用于老年代收集器,连线表示可以搭配,G1则对两者分代的假说没有太大的限制,使用了Region作为单位。
Serial GC
ParNew GC
ParNew收集器与Serial收集器相比无太多创新之处,但是他不少运行在服务端JVM中,由于在新生代的多线程回收可与CMS收集器在老年代回收互相配合。
ParNew默认开启的线程数是机器的核心线程数,但如果在单核中设置多线程由于线程的切换开销甚至不如Serial收集器。使用-XX: ParallelGCThreads 指定并发线程数。
Parallel Scavenge
作用于年轻代,主要关注吞吐量,具有如下调节参数
参数名 | 作用 |
---|
-XX: MaxGCPauseMills | 大于0 、表示期望的最大回收停顿时间 | -XX: GCTimeRatio | 大于0小于100整数、表示期望的垃圾收集时间比例 。如果为19 则 1/(1+19) 允许垃圾收集时间占5% | +XX: +UseAdaptiveSizePolicy | 使用自适应大小的策略,无需指定各种堆大小,老年代大小等参数 |
Serial Old
Parallel Old
本收集器出现在JDK6 以后,在之前 由于Parallel Scavenge在新生代的多线程回收,而且只能选择Serial Old作为老年代回收,会受到老年代单线程回收的拖累,无法提高GC的效率。Parallel Old 的出现让其有了合适搭配。
同时,我们最常用的LTS版本JDK8也是默认使用了本收集器+ParallelScavenge作为回收
CMS
采用了并发回收的机制,为老年代提供了很好的回收支持。它主要采用标记清除算法提高回收的时延,由于是与用户进程并行回收,会产生部分的碎片,造成空间的浪费,在无法进行回收时会转变为Serial Old的标记整理算法进行空间回收。
- 初始阶段 停止所有线程进行GC ROOT标记
- 并发标记 对相应的GC ROOT 进行图遍历
- 重新标记 对程序并发期间产生的对象进行标记
- 并发清除 由于不移动对象地址 直接进行并发清除
Garbage first
采用了独特的region分区,可以预测的回收耗时时间,会将回收块按优先级进行排序根据指定时间决定回收的大小,在JDK9后默认为该垃圾回收器。使用写屏障维护卡表(用来记录跨代的引用)
Shenandoah
使用了转移指针解决对于对象整理引用地址的变化
ZGC
使用染色指针解决对象引用地址变化
参考《深入理解JAVA虚拟机》
|