java-jvm

G1日志详解_Deegue-CSDN博客_g1日志分析YongGC

截取一条日志进行分析（为了更好的展示，将单挑日志拆分为三段，并使用上标表示每个字段的位置）：

2019-10-24T15:33:42.076+08001: 4.7262:
[GC3 (Allocation Failure4) [PSYoungGen5: 65536K->10738K6(132608K7)] 71711K->64480K8(232960K9), 0.0512660 secs10]
[Times: user=0.06 sys=0.42, real=0.05 secs11]

针对此条日志，进行具体分析：

(1) 2019-10-24T15:33:42.076+0800:当前GC事件发生时的UTC时间戳；
(2) 4.726: 当前GC发生时，JVM的启动事件(单位为s)；
(3) GC: 用于区分Young GC与Full GC，当前GC为Young GC；
(4) Allocation Failure: 当前GC的产生原因(新生代中空间不足以为新对象分配空间)；
(5) PSYoungGen: 垃圾收集器的名称；
(6) 65536K->10738K: GC前后新生代的内存空间使用量；
(7) 132608K: 新生代总内存量；
(8) 71711K->64480K: GC前后应用堆内存的变化情况(包括新生代和老年代)；
(9) 232960K: JVM堆的可用内存；
(10) 0.0512660 secs: 本次GC耗时，单位为s；
(11) [Times: user=0.06 sys=0.42, real=0.05 secs]:GC事件的耗时;

• user: 此次GC，所有GC线程消耗的CPU事件总和；
• sys: 此次GC，操作系统调用等事件所消耗的时间总和；
• real: 应用停顿的总时间，在并行的GC中，此数值应该接近(user + sys) / GCThreads，即单核上的平均停顿时间。

综上所述，在GC前总共使用了71711K堆内存，其中新生代使用了65536K，则老年代使用了6175K。GC后，新生代释放了65536-10738=54798K内存，但是堆内存仅释放了71711-64480=7231K内存，说明此次GC，有47567K的对象从新生代升级到了老年代。变化情况如下图所示：

Full GC

截取一条日志进行分析（为了更好的展示，将单挑日志拆分为三段，并使用上标表示每个字段的位置）：

2019-10-24T15:33:46.099+08001: 8.7492:
[Full GC3 (Metadata GC Threshold4) [PSYoungGen5: 172709K->0K6(544768K7)] [ParOldGen8: 230678K->398712K9(628224K10)] 403387K->398712K10(1172992K11),
[Metaspace12: 36781K->36523K13(1081344K14)], 0.2291498 secs15] [Times: user=0.20 sys=1.25, real=0.23 secs]16

针对此条日志，进行具体分析：

(1) 2019-10-24T15:33:46.099+0800: 当前GC事件发生时的UTC时间戳；
(2) 8.749: 当前GC发生时，JVM的启动事件(单位为s)；
(3) Full GC: 用于区分Young GC与Full GC，当前GC为Full GC；
(4) Metadata GC Threshold: 当前GC的产生原因(Metaspace空间占用达到阈值)；
(5) PSYoungGen: 新生代垃圾收集器名称；
(6) 172709K->0K: Full GC时，新生代内存空间将被清空；
(7) 544768K: 新生代总内存量；
(8) ParOldGen: 老年代垃圾收集器名称；
(9) 230678K->398712K: Full GC时，老年代内存空间变化情况；
(10) 628224K: 老年代总内存量；
(11) 403387K->398712K: GC前后堆内存的变化情况；
(12) 1172992K: JVM堆的可用内存；
(13) Metaspace: metaspace空间；
(14) 36781K->36523K: metaspace空间的变化情况；
(15) 1081344K: metadata的保留空间（metaspace时从jvm进程的虚拟地址空间中分离出来的）；
(16) 0.2291498 secs: 当前GC的耗时，单位为s；
(17) [Times: user=0.20 sys=1.25, real=0.23 secs]: 具体含义参见Young GC解释。

由以上数据可知，在此次Full GC的过程中，Young区域的数据被清空，但是Old区以及Metaspace区均进行扩容以便存放更多数据。

JVM内存分配

对照上面的图，GC日志中的PSYoungGen（PS是指Parallel Scavenge）为Eden+FromSpace，而整个YoungGeneration为Eden+FromSpace+ToSpace。

我们设置的新生代大小为10240K，这包括9216K大小的PSYoungGen和1024K大小的ToSpace。其中，PSYoungGen中的Eden:FromSpace为8:1，

这包括8192K的Eden和1024K的FromSpace。

官方链接Java SE 6 HotSpot[tm] Virtual Machine Garbage Collection Tuninghttps://www.oracle.com/java/technologies/javase/gc-tuning-6.html

参考链接

G1日志详解_Deegue-CSDN博客_g1日志分析为什么要看GC日志？因为JVM的GC状态能在很大程度上衡量一个Java应用是否健康，在相同条件下能否持续稳定运行。G1和CMS在日志上会有些许的区别，由于平时用G1为主，这边就不提CMS了。G1日志详解本文参考了RedHat Blog的Collecting and reading G1 garbage collector logs，并结合了现实场景和自己的理解来分析。其中的GC日志例子为线...https://blog.csdn.net/zyzzxycj/article/details/101380660

Java垃圾收集器——Parallel、G1收集器日志分析及性能调优示范 - 从此寂静无声 - 博客园开发过程中，经常需要对GC的垃圾收集器参数不断的进行动态调整，从而更充分的压榨机器性能，提升应用效率。本文将从常见的Parallel/G1垃圾收集器的GC日志着手，分析GC日志的具体含义，以及示范如何https://www.cnblogs.com/jason1990/p/11736779.html