JAVA GC日志的相关知识有哪些

本文主要讲解“JAVA GC日志的相关知识有哪些”，感兴趣的朋友不妨看看。本文介绍的方法简单、快速、实用。让边肖带你学习“JAVA GC日志的相关知识有哪些”！

GC环境模拟

首先，我们给出以下代码来触发垃圾收集

public Void Main(string[]args){//每100毫秒创建100个线程，每个线程创建一个1M对象，即申请100 m堆空间执行器。新计划的池(1)。scheduleatfixedrate(()-{ for(int I=0；i 100I) {new Thread(()-{try {//申请1字节[]temp=new byte[1024 * 1024]；Thread.sleep(新的随机数()。nextInt(1000))；//1秒内随机休眠} Catch(中断异常){ e . printstacktrace()；}}).start()；}}，1000，100，TimeUnit。毫秒)；}

我们要模拟的场景是年轻一代不断Young GC，一些对象提升到老年，老年空间不足时触发Full GC。

逻辑：每100毫秒创建100个线程，每个线程创建一个1M对象，即每100毫秒申请100Ms堆空间。每个线程随机休眠1s的原因是为了避免对象的突然死亡，保证一些对象可以提升到老年，更好的触发Young GC和FULL GC。注意，如果这个睡眠时间太长，会导致OOM，如果太小，很难触发Full GC。

虚拟机参数解释

启动Java进程：Java-xms 200m-xmx 200m-xmn 100m-verbose : GC-xx3360 print gcdetails-xlog GC 3360。/GC . log-xx3360 pringcdatestals-jardemo-0 . 0 . 1-snapshot . jar。

-Xms200M -Xmx200M最小/最大堆内存200m

-Xmn100M年轻一代内存100M

-verbose:gc打开gc日志

-xx3360 print gcdetails-xlog GC 3360。/gc . log-xx: printcgdatestamps将GC日志详细信息输入gc.log。

jmap分析

Jcmd获取我们的Java进程的ID:6264

jmap-堆6264查看堆信息

我们第一次发现伊甸园面积是98M，S0和S1是1M。

第二次，伊甸园面积99M，S0和S1 0.5M

伊甸园面积与幸存者面积的比例是动态变化的，不是默认的8:133601。

本来我们用的是默认的垃圾收集器Parallel cleave Parallel Old组合，但是在这个收集器下——XX 3360 use adaptive Sizepolicy默认是开启的，也就是说，Eden区域和Survivor区域的比例会根据GC情况自适应的变化。

我们增加一个参数关闭年轻一代适配，年轻一代比例设置为8:133601。

-XX :-use adaptiveSizePolicy-XX : survivorratio=8

另外，为了尽快触发FULL GC，我们增加了虚拟机参数。

-xx: maxteningthreshold=10

晋升年龄由默认的15岁改为10岁，年轻一代更容易晋升到老年。

重新启动虚拟机以查看jmap

年轻代

伊甸区80M已使用51M，目前使用率为63.8%，S0区10M已使用0.43M，使用率为4.37%。10M区利用率为空。

老年代

100M已用18.39M，利用率18.9%。

GC日志内容分析

查看我们的输出GC日志gc.log并选择两段。

2019-06-09t 02:55:30.993 08003360 330.811:【GC(分配失败)】【psyonggen : 82004k-384k(92160k)】184303k-102715k(194560k)，0.0035647秒】【时间3333

6914K(1064960K)], 0.0213953 secs] [Times: user=0.02 sys=0.00, real=0.02 secs]

Young GC

2019-06-09T02:55:30.993+0800: 330.811: [GC (Allocation Failure) [PSYoungGen: 82004K->384K(92160K)] 184303K->102715K(194560K), 0.0035647 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]2019-06-09T02:55:30.997+0800: 330.815: [Full GC (Ergonomics) [PSYoungGen: 384K->0K(92160K)] [ParOldGen: 102331K->5368K(102400K)] 102715K->5368K(194560K), [Metaspace: 16941K->16914K(1064960K)], 0.0213953 secs] [Times: user=0.02 sys=0.00, real=0.02 secs]

解释:

年轻代GC：[GC前年轻代80.08M->GC后0.37M(年轻代总大小90M)]GC前堆179.98M->GC后堆100.3M(堆总大小190M)，用时]  其中年轻代总大小是90M而不是100M，这里我理解是年轻代当前最大申请到90M  100M*80%=80M 是Eden区大小  80M*80% = 64M Eden区默认占用超过8成即64M就会触发YoungGC

Full GC

[Full GC (Ergonomics) [PSYoungGen: 384K->0K(92160K)] [ParOldGen: 102331K->5368K(102400K)] 102715K->5368K(194560K), [Metaspace: 16941K->16914K(1064960K)], 0.0213953 secs] [Times: user=0.02 sys=0.00, real=0.02 secs]

解释：

[GC前年轻代0.375M->GC后年轻代0M(年轻代总大小90M)][GC前老年代99.93M->GC后老年代5.24M(老年代总大小100M)]GC前堆100.3M->GC后堆5.24M（堆总大小190M）,[元数据区:GC前16.5,GC后16.5(元数据区总大小1040M)]，用时]  可以推测出此次FullGC原因是年轻代晋升老年代空间不足导致

利用可视化工具分析

这里我们利用 gceasy.io/ 分析一下

(1)统计年轻代、老年代、元数据区最大可用空间以及峰值，这里元数据区大小在我们的虚拟机参数没有配置，所以取的是默认值

(2)吞吐量、GC平均延迟、最大延迟以及延迟区间的统计

(3)堆所用大小的实时分析，红色位置是发生了FullGC使得堆总量直线下降

会发现虚拟机在刚启动不久的阶段触发大量的FULL GC，我的理解是我们申请的对象都随机睡眠一秒以内，刚启动时大部分还存在线程的引用，GCRoot可达。在刚启动的时候触发FULL GC并不会完整清理掉老年代空间并由于空间不足不断触发FULL GC。

(4)GC空间总量和时间的统计

(5)各类GC时间、GC次数、GC总量等指标

到此，相信大家对“JAVA GC日志的相关知识有哪些”有了更深的了解，不妨来实际操作一番吧！这里是网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！