垃圾收集器的各种分类
-
按线程数分类: 分为单核(串行收集器)和多核(并行收集器)
- 单核 CPU中适合使用串行收集器
- 多核 CPU中适合使用并行收集器
两种收集器共同点都是采用独占式, 也就是回收时都会 STW
-
按工作模式分类: 分为独占式(串行& 并行)垃圾收集器和并发式垃圾收集器
- 独占式垃圾收集器, 一旦开始回收, 会将所有的用户线程 STW, 直到结束
- 并发式垃圾收集器是收集器与应用程序线程交替工作, 以尽可能减少应用程序的停顿时间
按碎片处理方式分类: 分为压缩式垃圾收集器和非压缩式垃圾收集器
按内存区间分类: 分为新年代, 老年代垃圾收集器
-
按性能指标分类:
- 吞吐量(throughput)是指运行用户代码的时间, 在 CPU的总消耗时间的比值 公式为:
吞吐量 = 运行用户代码的时间 / (运行用户代码的时间 + 垃圾回收的时间)
* 吞吐量优先, 一般意味着垃圾回收相对不频繁, 所以一次回收的垃圾会更多, 因此用户线程暂停的时间会更长, 由此导致响应时间相对慢* 相对于响应时间优先的程序, 省了线程间频繁切换的性能消耗, 所以程序的运行速度会更快- 暂停时间(pause times)是指垃圾回收时用户线程暂停的时间
* 暂停时间优先约等于响应时间优先, 就是相对吞吐量优先的程序垃圾回收更频繁
* 每次垃圾回收时间比较短, 所以程序暂停的时间短, 因此用户交互响应快- 内存占用: 堆中所占的内存大小
* 值得注意的是大的内存空间, 也会导致暂停时间加长, 因为触发回收的条件会更宽松或面积大了需要扫描垃圾的范围更广 - 吞吐量(throughput)是指运行用户代码的时间, 在 CPU的总消耗时间的比值 公式为:
7款经典收集器
image.png
组合关系
image.png
* 注: 当老年代配了CMS收集器时, 如果内存使用率超过了一定的比例, 系统会抛出 Concurrent Mode Failure, 此时会自动采用Serial Old收集器做Full GC
-
红色虚线在Jdk8时, 将Serial与 CMS的组合和ParNew与 Serial Old的组合声明为废弃, 并在 Jdk9时完全弃用了 -
黄色虚线在Jdk14时, 弃用了 Parallel Scavenge与 Serial Old的组合 -
绿色虚线在Jdk14时, 完全弃用了 CMS垃圾收集器
近期垃圾收集器发展过程
- Jdk1.7u4开始全面支持 G1垃圾收集器
- Jdk9时 G1成为了, 默认的垃圾收集器, 替代了 CMS. (CMS声明为废弃)
- Jdk10时 G1垃圾收集器, 实现了并行性来改善了最坏情况下的延迟
- Jdk11时引入了 Epsilon垃圾收集器, 又称为 No-Op(无操作)收集器. 同时, 引入了 ZGC(The Z Garbage Collector), Oracle公司的可伸缩的低延迟垃圾收集器
- Jdk12时增强了 G1垃圾收集器, 自动返回未用的堆内存给操作系统. 同时, OpenJDK引入了 红帽公司开发的 Shenandoah GC低延迟垃圾收集器(试验性阶段)
- Jdk13时增强了 ZGC, 自动返回未用堆内存给操作系统
- Jdk14时完全弃用了 CMS垃圾收集器(如果显式设置会提示警告, 但不会中断. 而会自动选择默认收集器就是 G1). 扩展了 ZGC在 MacOS和 Windows上的应用
