GC 分类与日志剖析

╰半橙微兮° 2022-09-10 13:20 157阅读 0赞

# 一 点睛 #

针对 HotSpot VM 的实现，它里面的 GC 按照回收区域又分为两大种类型：一种是部分收集（Partial GC），一种是整堆收集（Full GC）

### 1 部分收集（Partial GC） ###

不是完整收集整个 Java 堆的垃圾收集。其中又分为：

*  新生代收集（Minor GC / Young GC）：只是新生代（Eden / S0, S1）的垃圾收集
 *  老年代收集（Major GC / Old GC）：只是老年代的垃圾收集。目前，只有 CMS GC 会有单独收集老年代的行为。注意，很多时候 Major GC 会和 Full GC 混淆使用，需要具体分辨是老年代回收还是整堆回收。
 *  混合收集（Mixed GC）：收集整个新生代以及部分老年代的垃圾收集。目前，只有 G1 GC 会有这种行为。

### 2 整堆收集（Full GC） ###

收集整个 java 堆和方法区的垃圾收集。

# 二 哪些情况会触发 Full GC #

### 1 老年代空间不足 ###

### 2 方法区空间不足 ###

### 3 显示调用 System.gc() ###

### 4 Minor GC 进行老年代的数据的平均大小大于老年代的可用内存 ###

### 5 大对象直接进入老年代，而老年代的可用空间不足 ###

# 三 GC日志分类 #

### 1 MinorGC ###

MinorGC（或 young GC 或 YGC）日志：

> \[GC (Allocation Failure) \[PSYoungGen: 31744K->2192K (36864K) \] 31744K->2200K (121856K), 0.0139308 secs\] \[Times: user=0.05 sys=0.01, real=0.01 secs\]

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAY2hlbmdxaXVtaW5n_size_20_color_FFFFFF_t_70_g_se_x_16][]

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAY2hlbmdxaXVtaW5n_size_13_color_FFFFFF_t_70_g_se_x_16][]

### 2 FullGC ###

> \[Full GC (Metadata GC Threshold) \[PSYoungGen: 5104K->0K (132096K) \] \[Par01dGen: 416K->5453K (50176K) \]5520K->5453K (182272K), \[Metaspace: 20637K->20637K (1067008K) \], 0.0245883 secs\] \[Times: user=0.06 sys=0.00, real=0.02 secs\]

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAY2hlbmdxaXVtaW5n_size_20_color_FFFFFF_t_70_g_se_x_16 1][]

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAY2hlbmdxaXVtaW5n_size_13_color_FFFFFF_t_70_g_se_x_16 1][]

## 四 GC 日志结构剖析 ##

### 1 透过日志看垃圾收集器 ###

*  Serial 收集器：新生代显示 "\[DefNew"，即 Default New Generation
 *  ParNew 收集器：新生代显示 "\[ParNew"，即 Parallel New Generation
 *  Parallel Scavenge 收集器：新生代显示"\[PSYoungGen"，JDK1.7 使用的即 PSYoungGen
 *  Parallel Old 收集器：老年代显示"\[ParoldGen"
 *  G1 收集器：显示”garbage-first heap“

### 2 透过日志看 GC 原因 ###

*  Allocation Failure：表明本次引起 GC 的原因是因为新生代中没有足够的区域存放需要分配的数据
 *  Metadata GCThreshold：Metaspace 区不够用了
 *  FErgonomics：JVM 自适应调整导致的 GC
 *  System：调用了 System.gc()方法

### 3 透过日志看 GC 前后情况 ###

通过图示，我们可以发现 GC 日志格式的规律一般都是：GC 前内存占用-＞ GC 后内存占用（该区域内存总大小）

> \[PSYoungGen: 5986K->696K (8704K) \] 5986K->704K (9216K)

*  中括号内：GC 回收前年轻代堆大小，回收后大小，（年轻代堆总大小）
 *  括号外：GC 回收前年轻代和老年代大小，回收后大小，（年轻代和老年代总大小）

注意：Minor GC 堆内存总容量 = 9/10 年轻代 + 老年代。原因是 Survivor 区只计算 from 部分，而 JVM 默认年轻代中 Eden 区和 Survivor 区的比例关系，Eden:S0:S1=8:1:1。

### 4 透过日志看 GC 时间 ###

GC 日志中有三个时间：user，sys 和 real

*  user：进程执行用户态代码（核心之外）所使用的时间。这是执行此进程所使用的实际 CPU 时间，其他进程和此进程阻塞的时间并不包括在内。在垃圾收集的情况下，表示 GC 线程执行所使用的 CPU 总时间。
 *  sys：进程在内核态消耗的 CPU 时间，即在内核执行系统调用或等待系统事件所使用的 CPU 时间
 *  real：程序从开始到结束所用的时钟时间。这个时间包括其他进程使用的时间片和进程阻塞的时间（比如等待 I/O 完成）。对于并行 gc，这个数字应该接近（用户时间＋系统时间）除以垃圾收集器使用的线程数。

由于多核的原因，一般的 GC 事件中，real time 是小于 sys time ＋ user time 的，因为一般是多个线程并发的去做 GC，所以 real time 是要小于 sys ＋ user time 的。如果 real ＞ sys ＋ user 的话，则你的应用可能存在下列问题：IO 负载非常重或 CPU 不够用。

[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAY2hlbmdxaXVtaW5n_size_20_color_FFFFFF_t_70_g_se_x_16]: /images/20220829/01b308d2905e4415908447935ec9cfcc.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAY2hlbmdxaXVtaW5n_size_13_color_FFFFFF_t_70_g_se_x_16]: /images/20220829/328b77efa6ca43eeacc658cd9201c962.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAY2hlbmdxaXVtaW5n_size_20_color_FFFFFF_t_70_g_se_x_16 1]: /images/20220829/d5270f77747544b5997ee76340bc90e2.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAY2hlbmdxaXVtaW5n_size_13_color_FFFFFF_t_70_g_se_x_16 1]: /images/20220829/d92afca29cf445338b070343032da507.png