Minor GC 日志解析
2020-11-20T17:19:43.265-0800
日志打印时间 日期格式 如
2013-05-04T21:53:59.234+0800
0.822:
gc发生时，Java虚拟机启动以来经过的秒数
[GC(Allocation Failure)
发生了一次垃圾回收，这是一次Minior GC。它不区分新生代还是老年代GC，括号里的内容是gc发生的原因，这里的Allocation Failure的原因是新生代中没有足够区域能够存放需要分配的数据而失败
[PSYoungGen:76800K->8433K(89600K)
PSYoungGen：表示GC发生的区域，区域名称与使用的GC收集器是密切相关的
Serial收集器：Default New Generation 显示Defnew
ParNew收集器：ParNew
Parallel Scanvenge收集器：PSYoung
老年代和新生代同理，也是和收集器名称相关
76800K->8433K(89600K)：GC前该内存区域已使用容量->GC后盖区域容量(该区域总容量)
如果是新生代，总容量则会显示整个新生代内存的9/10，即eden+from/to区
如果是老年代，总容量则是全身内存大小，无变化
76800K->8449K(294400K)
在显示完区域容量GC的情况之后，会接着显示整个堆内存区域的GC情况：GC前堆内存已使用容量->GC后堆内存容量（堆内存总容量），并且堆内存总容量 = 9/10 新生代 + 老年代，然后堆内存总容量肯定小于初始化的内存大小
,0.0088371
整个GC所花费的时间，单位是秒
[Times：user=0.02 sys=0.01,real=0.01 secs]
user：指CPU工作在用户态所花费的时间
sys：指CPU工作在内核态所花费的时间
real：指在此次事件中所花费的总时间
Full GC 日志解析
2020-11-20T17:19:43.794-0800
日志打印时间 日期格式 如
2013-05-04T21:53:59.234+0800
1.351
gc发生时，Java虚拟机启动以来经过的秒数
Full GC(Metadata GCThreshold)
括号中是gc发生的原因，原因：Metaspace区不够用了。
除此之外，还有另外两种情况会引起Full GC，如下：
1、Full GC(FErgonomics)
原因：JVM自适应调整导致的GC
2、Full GC（System）
原因：调用了System.gc()方法
[PSYoungGen: 100082K->0K(89600K)]
PSYoungGen：表示GC发生的区域，区域名称与使用的GC收集器是密切相关的
Serial收集器：Default New Generation 显示DefNew
ParNew收集器：ParNew
Parallel Scanvenge收集器：PSYoungGen
老年代和新生代同理，也是和收集器名称相关
10082K->0K(89600K)：GC前该内存区域已使用容量->GC该区域容量(该区域总容量)
如果是新生代，总容量会显示整个新生代内存的9/10，即eden+from/to区
如果是老年代，总容量则是全部内存大小，无变化
ParOldGen：32K->9638K(204800K)
老年代区域没有发生GC，因此本次GC是metaspace引起的
10114K->9638K(294400K),
在显示完区域容量GC的情况之后，会接着显示整个堆内存区域的GC情况：GC前堆内存已使用容量->GC后堆内存容量（堆内存总容量），并且堆内存总容量 = 9/10 新生代 + 老年代，然后堆内存总容量肯定小于初始化的内存大小
[Meatspace:20158K->20156K(1067008K)],
metaspace GC 回收2K空间
