「译文」Java 垃圾收集参考手册（五）：Parallel GC

本文最后更新于：2024年7月25日下午

Parallel GC (并行 GC)

并行垃圾收集器这一类组合，在年轻代使用标记 - 复制 (mark-copy) 算法 , 在老年代使用标记 - 清除 - 整理 (mark-sweep-compact) 算法。年轻代和老年代的垃圾回收都会触发 STW 事件，暂停所有的应用线程来执行垃圾收集。两者在执行标记和复制 / 整理阶段时都使用多个线程，因此得名 “(Parallel)”。通过并行执行，使得 GC 时间大幅减少。

通过命令行参数 -XX:ParallelGCThreads=NNN 来指定 GC 线程数。其默认值为 CPU 内核数。

可以通过下面的任意一组命令行参数来指定并行 GC:

1
2
3

java -XX:+UseParallelGC com.mypackages.MyExecutableClass
java -XX:+UseParallelOldGC com.mypackages.MyExecutableClass
java -XX:+UseParallelGC -XX:+UseParallelOldGC com.mypackages.MyExecutableClass

并行垃圾收集器适用于多核服务器，主要目标是增加吞吐量。因为对系统资源的有效使用，能达到更高的吞吐量:

在 GC 期间，所有 CPU 内核都在并行清理垃圾，所以暂停时间更短
在两次 GC 周期的间隔期，没有 GC 线程在运行，不会消耗任何系统资源

另一方面，因为此 GC 的所有阶段都不能中断，所以并行 GC 很容易出现长时间的停顿。如果延迟是系统的主要目标，那么就应该选择其他垃圾收集器组合。

译者注: 长时间卡顿的意思是，此 GC 启动之后，属于一次性完成所有操作，于是单次 pause 的时间会较长。

让我们看看并行垃圾收集器的 GC 日志长什么样，从中我们可以得到哪些有用信息。下面的 GC 日志中显示了一次 minor GC 暂停和一次 major GC 暂停:

2015-05-26T14:27:40.915-0200: 116.115: [GC (Allocation Failure)
        [PSYoungGen: 2694440K->1305132K(2796544K)]
    9556775K->8438926K(11185152K)
    , 0.2406675 secs]
    [Times: user=1.77 sys=0.01, real=0.24 secs]
2015-05-26T14:27:41.155-0200: 116.356: [Full GC (Ergonomics)
        [PSYoungGen: 1305132K->0K(2796544K)]
        [ParOldGen: 7133794K->6597672K(8388608K)] 8438926K->6597672K(11185152K),
        [Metaspace: 6745K->6745K(1056768K)]
    , 0.9158801 secs]
    [Times: user=4.49 sys=0.64, real=0.92 secs]

Minor GC (小型 GC)

第一次 GC 事件表示发生在年轻代的垃圾收集:

2015-05-26T14:27:40.915-02001: 116.1152: [ GC3 (Allocation Failure4)
[PSYoungGen5: 2694440K->1305132K6 (2796544K)7] 9556775K->8438926K8
(11185152K)9, 0.2406675 secs10]
[Times: user=1.77 sys=0.01, real=0.24 secs]11

2015-05-26T14:27:40.915-0200 – GC 事件开始的时间。其中 -0200 表示西二时区，而中国所在的东 8 区为 +0800。

116.115 – GC 事件开始时，相对于 JVM 启动时的间隔时间，单位是秒。

GC – 用来区分 Minor GC 还是 Full GC 的标志。GC 表明这是一次小型 GC(Minor GC)

Allocation Failure – 触发垃圾收集的原因。本次 GC 事件，是由于年轻代中没有适当的空间存放新的数据结构引起的。

PSYoungGen – 垃圾收集器的名称。这个名字表示的是在年轻代中使用的：并行的标记 - 复制 (mark-copy), 全线暂停 (STW) 垃圾收集器。

2694440K->1305132K – 在垃圾收集之前和之后的年轻代使用量。

(2796544K) – 年轻代的总大小。

9556775K->8438926K – 在垃圾收集之前和之后整个堆内存的使用量。

(11185152K) – 可用堆的总大小。

0.2406675 secs – GC 事件持续的时间，以秒为单位。

[Times: user=1.77 sys=0.01, real=0.24 secs] – GC 事件的持续时间，通过三个部分来衡量:

user – 在此次垃圾回收过程中，由 GC 线程所消耗的总的 CPU 时间。

sys – GC 过程中中操作系统调用和系统等待事件所消耗的时间。

real – 应用程序暂停的时间。在 Parallel GC 中，这个数字约等于: (user time + system time)/GC 线程数。这里使用了 8 个线程。请注意，总有一定比例的处理过程是不能并行进行的。

所以，可以简单地算出，在垃圾收集之前，堆内存总使用量为 9,556,775K。其中年轻代为 2,694,440K。同时算出老年代使用量为 6,862,335K. 在垃圾收集之后，年轻代使用量减少为 1,389,308K, 但总的堆内存使用量只减少了 1,117,849K。这表示有大小为 271,459K 的对象从年轻代提升到老年代。

Full GC (完全 GC)

学习了并行 GC 如何清理年轻代之后，下面介绍清理整个堆内存的 GC 日志以及如何进行分析:

2015-05-26T14:27:41.155-0200 : 116.356 : [Full GC (Ergonomics)
[PSYoungGen: 1305132K->0K(2796544K)] [ParOldGen :7133794K->6597672K
(8388608K)] 8438926K->6597672K (11185152K),
[Metaspace: 6745K->6745K(1056768K)], 0.9158801 secs,
[Times: user=4.49 sys=0.64, real=0.92 secs]

2015-05-26T14:27:41.155-0200 – GC 事件开始的时间。其中 -0200 表示西二时区，而中国所在的东 8 区为 +0800。

116.356 – GC 事件开始时，相对于 JVM 启动时的间隔时间，单位是秒。我们可以看到，此次事件在前一次 MinorGC 完成之后立刻就开始了。

Full GC – 用来表示此次是 Full GC 的标志。Full GC 表明本次清理的是年轻代和老年代。

Ergonomics – 触发垃圾收集的原因。Ergonomics 表示 JVM 内部环境认为此时可以进行一次垃圾收集。

[PSYoungGen: 1305132K->0K(2796544K)] – 和上面的示例一样，清理年轻代的垃圾收集器是名为 “PSYoungGen” 的 STW 收集器，采用标记 - 复制 (mark-copy) 算法。年轻代使用量从 1305132K 变为 0, 一般 Full GC 的结果都是这样。

ParOldGen – 用于清理老年代空间的垃圾收集器类型。在这里使用的是名为 ParOldGen 的垃圾收集器，这是一款并行 STW 垃圾收集器，算法为标记 - 清除 - 整理 (mark-sweep-compact)。

7133794K->6597672K – 在垃圾收集之前和之后老年代内存的使用情况。

(8388608K) – 老年代的总空间大小。

8438926K->6597672K – 在垃圾收集之前和之后堆内存的使用情况。

(11185152K) – 可用堆内存的总容量。

[Metaspace: 6745K->6745K(1056768K)] – 类似的信息，关于 Metaspace 空间的。可以看出，在 GC 事件中 Metaspace 里面没有回收任何对象。

0.9158801 secs – GC 事件持续的时间，以秒为单位。

[Times: user=4.49 sys=0.64, real=0.92 secs] – GC 事件的持续时间，通过三个部分来衡量:

user – 在此次垃圾回收过程中，由 GC 线程所消耗的总的 CPU 时间。

sys – GC 过程中中操作系统调用和系统等待事件所消耗的时间。

real – 应用程序暂停的时间。在 Parallel GC 中，这个数字约等于: (user time + system time)/GC 线程数。这里使用了 8 个线程。请注意，总有一定比例的处理过程是不能并行进行的。