JVM-17(垃圾回收器)上_jdk17默认垃圾收集器-CSDN博客

本文链接：https://blog.csdn.net/qq_44447372/article/details/122354331

17.1 GC分类与性能指标

17.1.1 JVM的发展

垃圾收集器没有在规范中进行过多的规定,可以有不同的厂商,不同的版本的JVM来实现
由于JDK的版本处于高速迭代中,因此Java发展至今已经衍生了众多的GC版本
从不同的角度分析垃圾收集器,可以将GC分为不同的类型
- 按线程数分,可以分为串行垃圾回收器和并行垃圾回收器

串行回收指的是同一时间段内只允许有一个CPU用于执行垃圾回收操作,此时工作线程被暂停,直至垃圾收集工作结束;在诸如单CPU处理器或者较小的应用内存等硬件平台不是特别优越的场合,串行回收器的性能表现可以超过并行回收器和并发回收器.所以,串行回收默认被应用在客户端的Client模式下的JVM中

并行回收可以运行多个CPU同时执行垃圾回收,因此提升了应用的吞吐量,不过并行回收仍然可以与串行回收一样,采用独占式,使用了”Stop-the-world”机制

按照工作模式分,可以分为并发式垃圾回收器和独占式垃圾回收器.

并发式垃圾回收器可以与应用线程交替执行,以尽可能较少减少应用程序的停顿时间

独占式垃圾回收器(Stop-the-world)一旦运行,就停止应用程序中的所有用户线程,知道垃圾回收过程完全结束

按碎片方式分,可分为压缩式垃圾回收器和非压缩式垃圾回收器
- 压缩式垃圾回收器会在回收完成后,对存活对象进行压缩处理,消除回收后的碎片.
  - 再分配对象空间使用:指针碰撞
- 非压缩式的垃圾回收器不进行压缩整理.
  - 再分配对象空间:空闲列表
按照工作的内存区间分,又可以分为年轻代垃圾回收器和老年代垃圾回收器

17.1.2评估GC的性能指标

吞吐量:运行用户代码的时间占总运行时间的比例
- (总运行时间=程序的运行时间+内存回收的时间)
暂停时间:执行垃圾收集时,程序的工作线程被暂停的时间
内存占用:Java堆区所占的内存大小
快速:一个对象从诞生到被回收所经历的时间
垃圾收集开销:吞吐量的补数,垃圾收集所用时间与总运行时间的比例
收集频率:相对于应用程序的执行,收集操作发生的频率;收集频率低,暂停时间可能长一些(一天洗一次衣服,七天洗一次衣服)
简单来说,主要抓住两点
- 吞吐量
- 暂停时间
吞吐量

吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值,即吞吐量=运行用户代码时间/(运行用户代码时间+垃圾收集时间).
- 比如:虚拟机总共运行了100分钟,其中垃圾收集花掉1分钟,那吞吐量就是99%
- 这种情况下,应用程序能容忍较高的暂停时间,因此,高吞吐量的应用程序有更长的时间基准,快速响应是不必考虑的.
- 吞吐量优先,意味着在单位时间内,STW的时间最短

暂停时间
- “暂停时间”是一个时间段内应用程序线程暂停,让GC线程执行的状态
  - 例如,GC期间100毫秒的暂停时间意味着100毫秒内没有应用程序线程是活动的
  - 暂停时间优先,意味着尽可能让单次STW的时间最短

吞吐量VS 暂停时间
- 高吞吐量比较好因为这会让应用程序的最终用户感觉只有应用程序在做”生产性”工作.直觉上,吞吐量越高程序越快
- 低暂停时间(低延迟)较好因为从应用程序的最终用户的角度来看不管是GC还是其他原因导致一个应用被挂起始终是不好的.这取决于应用程序的类型,有时候甚至短暂的200毫秒都可能打断终端用户体验.
“高吞吐量”和”低暂停时间”是一对相互竞争的矛盾
- 因为如果选择以吞吐量优先,那么必须需要降低内存回收的执行频率,但是这样会导致GC需要更长的暂停时间来执行内存回收
- 相反的,如果选择以低延迟优先为原则,那么为了降低每次执行内存回收的暂停时间,也只能频繁的执行内存回收,但这又引起了年轻代内存的缩减和导致程序吞吐量的下降.
- 在最大吞吐量优先的情况下,降低停顿时间.

17.2 不同的垃圾回收器概述

如果说收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现。

虽然我们对各个收集器进行比较，但并非为了挑选出一个最好的收集器。因为直到现在为止还没有最好的垃圾收集器出现，更加没有万能的垃圾收集器，我们能做的就是根据具体应用场景选择适合自己的垃圾收集器。试想一下：如果有一种四海之内、任何场景下都适用的完美收集器存在，那么我们的Java虚拟机就不会实现那么多不同的垃圾收集器了。

经典的垃圾收集器
- 串行回收器: Serial,Serial Old
- 并行回收器:ParNew,Parallel Scavenge,Parallel Old
- 并发回收器:CMS,G1

组合关系

查看默认的垃圾收集器
- -XX:+PrintCommondLineFlags:查看命令行相关参数(包含使用的垃圾收集器)
- 使用命令行指令:jinfo -flag 相关垃圾回收器参数进程ID

17.3 Serial回收器:串行回收

-XX:+UseSerialGC -XX:+UseSerialOldGC==>新生代采用复制算法,老年代采用标记-整理算法
这个收集器是一个单线程的收集器,但他的”单线程”的意义并不仅仅说明它只会使用一个CPU或者一条收集线程去完成垃圾收集工作,更重要的是在他进行垃圾收集时必须暂停,必须暂停其他所有的工作线程,直到它收集结束.

Serial回收器:串行回收
- 优势:简单而高效(与其他收集器的单线程比),对于限定单个CPU的环境来说,Serial收集器由于没有线程交互的开销.专心做垃圾收集自然可以获得最高的单线程收集效率(运行在client模式下的虚拟机是一个不错的选择)
- 在用户的桌面应用场景中,可用内存一般不大(几十MB至一两百MB),可以在较短的
- 时间内完成垃圾收集(几十ms至一百多ms),只要不频繁发生,使用串行回收器是可以接受的
- 在HotSpot虚拟机中,使用-XX:+UseSerialGC参数可以指定年轻代和老年代都使用串行收集器 ==>新生代用Serial GC且老年代用Serial Old GC
总结
- 现在已经不用串行的了

17.4 ParNew回收器: 并行回收

如果是Serial GC是年轻代中的单线程收集器,那么ParNew收集器则是Serial收集器的多线程版本
- Par是Parallel的缩写,New:只能处理的是新生代
- ParNew收集器除了采用并行回收的方式执行内存回收,两款垃圾收集器之间几乎没有任何区别,ParNew收集器在年轻代中同样也是采用复制算法,STW机制
- ParNew是很多JVM运行在Server模式下的新生代的默认垃圾收集器

对于新生代,回收次数频繁,使用并行方式高效.
对于老年代,回收次数少,使用串行方式节省资源.(CPU并行需要切换线程,串行可以省去切换线程的资源)
由于ParNew收集器是基于并行回收,那么是否可以断定ParNew收集器的回收效率在任何场景下都会比Serial收集器更高效
- ParNew收集器运行在多CPU的环境下,由于可以充分利用多CPU,多核心等物理硬件资源优势,可以更快速的完成垃圾收集,提升程序的吞吐量
- 但是在单个CPU的环境下,ParNew收集器不比Serial收集器更高效,虽然Serial收集器是基于串行回收,但是由于CPU不需要频繁的做任务切换,因此可以有效地避免多线程交互过程中产生的一些额外开销.
因为除了Serial外,目前只有ParNew GC能与CMS收集器配合工作(ParNew收集器跟Parallel收集器区别)
可以通过-XX:UseParNewGC手动指定使用ParNew收集器执行内存回收任务.它表示年轻代使用并行收集器,不影响老年代
-XX:ParallelGCThreads 限制线程数量,默认开启和CPU数据相同的线程数
新生代采用复制算法,老年代采用标记-整理算法

17.5 Parallel回收器: 吞吐量优先

-XX:+UseParallelGC(年轻代),-XX:+UseParallelOldGC(老年代)
HotSpot的年轻代中除了拥有ParNew收集器是基于并行回收的以外,Parallel Scavenge收集器同样采用了复制算法,并行回收和STW机制.
Parallel收集器的出现是否多此一举
- 和ParNew收集器不同,Parallel Scavenge收集器的目标则是达到一个可控制的吞吐量(Throughput),他也被称为吞吐量有限的垃圾收集器
- 自适应调节策略也是Parallel Scavenge与ParNew一个重要区别
高吞吐量则可以高效率的利用CPU时间,尽快完成程序的运算任务,主要适合在后台运算而不需要太多交互的任务.因此,常见在服务器环境中使用.例如,那些执行批量处理,订单处理,工资支付,科学计算的应用程序
Parallel收集器在JDK1.6时提供了用于执行老年代垃圾收集Parallel Old收集器,用来替代老年代的Serial Old收集器.
- Parallel Old收集器采用了标记-压缩算法,但同时也是基于并行回收和STW机制

在程序吞吐量(用于执行用户代码的时间与CPU总消耗时间的比值)最优先的应用场景下,Parallel收集器和Parallel Old收集器的组合,在Server模式下的内存回收性能很不错.
在Java8中,默认是此垃圾收集器
参数配置:帮助用户找到最合适的停顿时间或最大吞吐量
- -XX:+UseParallelGC 手动指定年轻代使用Parallel并行收集器执行内存回收任务.
- -XX:+UseParallelOldGC 手动指定老年代使用并行回收器/
  - 分别适用于新生代和老年代,默认jdk8开启的
  - 上面两个参数,默认开启一个,另外一个也会被开启(互相激活)
- -XX:ParallelGCThreads 设置年轻代并行收集器的线程数.一般的,最好与CPU数量相同,以避免过多的线程数影响垃圾收集性能
  - 在默认情况下,当CPU数量小于8个ParallelGCThreads的值等于CPU数量
  - 当CPU数量大于8个,ParallelGCThreads的值等于 3+[5*CPU_Count]/8
- -XX:MaxGCPauseMillis 设置垃圾收集器最大停顿时间(即STW的时间).单位是毫秒
  - 为了尽可能地地把停顿时间控制在MaxGCPauseMillis以内,收集器在工作时会把Java堆大小或者其他一些参数
  - 对于用户来讲,停顿时间越短越好.但是在服务器端,我们注重高并发,整体的吞吐量.所以服务器端适合Parallel,进行控制.
  - 该参数使用谨慎
- -XX:GCTimeRatio 垃圾收集时间占总时间的比例(=1 /(N+1)).用于衡量11吞吐量的大小.
  - 取值范围(0,100).默认值是99,也就是垃圾回收时间不超过1%
  - 与前一个-XX:MaxGCPauseMillis参数有一定矛盾性.暂停时间越长,Ratio参数就容易超过设定的比例
- -XX:+UseAdaptiveSizePolicy 设置Parallel Scavenge 收集器具有自适应调节策略
  - 在这种模式下,年轻代的大小,Eden和Survivor的比例,晋升老年代的对象年龄等参数会被自动调整,以达到在堆大小,吞吐量和停顿时间之间的平衡点.
  - 在手动调节比较困难的场合,可以直接使用这种自适应的方式,仅5指定虚拟机的最大堆,目标的吞吐量(GCTimeRatio)和停顿时间(MaxGCPauseMills),让虚拟机自己完成调优工作.