java

关注公众号 jb51net

关闭
首页 > 软件编程 > java > JDK1.8垃圾回收器和执行GC时长及GC频率

JDK1.8使用的垃圾回收器和执行GC的时长以及GC的频率方式

作者：Cx_轩

这篇文章主要介绍了JDK1.8使用的垃圾回收器和执行GC的时长以及GC的频率方式，具有很好的参考价值，希望对大家有所帮助。如有错误或未考虑完全的地方，望不吝赐教

JDK1.8使用的垃圾回收器和执行GC的时长以及GC的频率

GC介绍        

GC就是垃圾回收器。因为内存空间是有限的，创建的每个对象和变量都会占据内存，gc做的就是对象清除将内存释放出来。其中堆是虚拟机中进行垃圾回收的主要场所，其次是方法区。

垃圾回收器 

新生代收集器：       

老年代收集器：       

新生代和老年代收集器：

G1收集器：G1收集器是一款面向服务端应用的垃圾收集器，目前是JDK9的默认垃圾收集器。

Java详细信息

java -XX:+PrintCommandLineFlags -version

cmd展示信息：

C:\Users\xx>java -XX:+PrintCommandLineFlags -version
-XX:InitialHeapSize=266295296 -XX:MaxHeapSize=4260724736 -XX:+PrintCommandLineFlags -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:-UseLargePagesIndividualAllocation -XX:+UseParallelGC
java version "1.8.0_91"
Java(TM) SE Runtime Environment (build 1.8.0_91-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.91-b14, mixed mode)

JDK1.8默认使用的垃圾回收器是-XX:+UseParallelGC，代表为 “Parallel Scavenge” + “Parallel Old”。

在JVM中垃圾回收器配置实现的搭配组合如下：

默认垃圾回收方式代表垃圾回收器
UseSerialGC“Serial” + “Serial Old”
UseParNewGC“ParNew” + “Serial Old”
UseConcMarkSweepGC“ParNew” + “CMS”
UseParallelGC“Parallel Scavenge” + “Parallel Old”

GC优化条件

若满足一下条件，则GC一般不需要优化。

垃圾收集器分类与GC性能指标

概述

垃圾收集器没有在规范中进行过多的规定，可以由不同的厂商、不同版本的JVM来实现。

由于JDK的版本处于高速迭代过程中，因此Java发展至今已经衍生了众多的GC版本。

从不同角度分析垃圾收集器，可以将GC分为不同的类型。

Java不同版本新特性：

垃圾收集器分类

(一)、按线程数分（垃圾回收线程数），可以分为：串行垃圾回收器和并行垃圾回收器

串行回收指的是在同一时间段内只允许有一个CPU用于执行垃圾回收操作，此时工作线程被暂停（STW），直至垃圾收集工作结束。

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

(二)、按工作模式，可以分为：并发式垃圾回收器和独占式垃圾回收器。

(三)、按碎片处理方式分，可以分为：压缩式垃圾回收器和非压缩式垃圾回收器

(四)、按工作的内存区间分，可以分为：年轻代垃圾回收器和老年代垃圾回收器

评估GC的性能指标

吞吐量、暂停时间、内存占用 这三者共同构成一个“不可能三角”。三者总体的表现会随着技术进步而越来越好。一款优秀的收集器通常最多同时满足其中的两项。 这三项里，暂停时间的重要性日益凸显。因为随着硬件发展，内存占用多些越来越能容忍，硬件性能的提升也有助于降低收集器运行时对应用程序的影响，即提高了吞吐量。而内存的扩大，对延迟反而带来负面效果。 简单来说，主要抓住两点：

这三项里，暂停时间的重要性日益凸显。因为随着硬件发展，内存占用多些越来越能容忍，硬件性能的提升也有助于降低收集器运行时对应用程序的影响，即提高了吞吐量。而内存的扩大，对延迟反而带来负面效果。 简单来说，主要抓住两点：

(一)、吞吐量

吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值，即吞吐量 = 运行用户代码时间 /（运行用户代码时间 + 垃圾收集时间）。

比如：虚拟机总共运行了100分钟，其中垃圾收集花掉1分钟，那吞吐量就是99%。

这种情况下，应用程序能容忍较高的暂停时间，因此，高吞吐量的应用程序有更长的时间基准，快速响应是不必考虑的。

吞吐量优先，意味着在单位时间内，STW的时间最短：0.2+0.2 = 0.4。

(二)、暂停时间

“暂停时间”是指一个时间段内应用程序线程暂停，让GC线程执行的状态。

例如，GC期间100毫秒的暂停时间意味着在这100毫秒期间内没有应用程序线程是活动的。暂停时间优先，意味着尽可能让单次STW的时间最短：0.1+0.1 + 0.1+ 0.1+ 0.1 = 0.5。

(三)、吞吐量vs暂停时间

高吞吐量较好，因为这会让应用程序的最终用户感觉只有应用程序线程在做“生产性”工作。直觉上，吞吐量越高程序运行越快。

低暂停时间（低延迟）较好，因为从最终用户的角度来看不管是GC还是其他原因导致一个应用被挂起始终是不好的。这取决于应用程序的类型，有时候甚至短暂的200毫秒暂停都可能打断终端用户体验。因此，具有低的较大暂停时间是非常重要的，特别是对于一个交互式应用程序。

不幸的是”高吞吐量”和”低暂停时间”是一对相互竞争的目标（矛盾）。

因为如果选择以吞吐量优先，那么必然需要降低内存回收的执行频率，但是这样会导致GC需要更长的暂停时间来执行内存回收。

相反的，如果选择以低延迟优先为原则，那么为了降低每次执行内存回收时的暂停时间，也只能频繁地执行内存回收，但这又引起了年轻代内存的缩减和导致程序吞吐量的下降。

在设计（或使用）GC算法时，我们必须确定我们的目标：一个GC算法只可能针对两个目标之一（即只专注于较大吞吐量或最小暂停时间），或尝试找到一个二者的折衷。

现在标准：在最大吞吐量优先的情况下，降低停顿时间。

7种经典的垃圾收集器

7款经典收集器与垃圾分代之间的关系如下图：

垃圾收集器的组合关系

两个收集器间有连线，表明它们可以搭配使用：Serial/Serial old、Serial/CMS、ParNew/Serial old、ParNew/CMS、Parallel Scavenge/Serial 0ld、Parallel Scavenge/Parallel 0ld、G1；
其中Serial old作为CMS出现"Concurrent Mode Failure"失败的后备预案。

为什么要有很多收集器，一个不够吗？因为Java的使用场景很多，移动端，服务器等。所以就需要针对不同的场景，提供不同的垃圾收集器，提高垃圾收集的性能。

虽然我们会对各个收集器进行比较，但并非为了挑选一个最好的收集器出来。没有一种放之四海皆准、任何场景下都适用的完美收集器存在，更加没有万能的收集器。所以我们选择的只是对具体应用最合适的收集器。

如何查看默认垃圾收集器?

第一种方式：-XX:+PrintCommandLineFlags：查看命令行相关参数（包含使用的垃圾收集器）

输出结果如下：-XX:+UseParallelGC，可以看到，在JDK1.8中默认使用的Parallel Scavenge/Parallel 0ld这一对垃圾回收器。

-XX:InitialHeapSize=257920192 -XX:MaxHeapSize=4126723072 -XX:+PrintCommandLineFlags -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:-UseLargePagesIndividualAllocation -XX:+UseParallelGC 

第二种方式：使用命令行指令：jps查看进程ID +  jinfo -flag 相关垃圾回收器参数 进程ID。

总结

以上为个人经验，希望能给大家一个参考，也希望大家多多支持脚本之家。

您可能感兴趣的文章:
阅读全文