频繁Full GC（Ergonomics）----自动选择和调优引发的FullGC

刺骨的言语ヽ痛彻心扉 2022-10-01 09:52 290阅读 0赞

通过GC日志可以获取JVM在GC时的详细信息。GC日志既可以直接在命令行输出，也可生成到指定的日志文件中。关于GC日志，可以由很多JVM参数来控制

-XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -Xloggc:/home/logs/gc.log

199.879: [Full GC (Ergonomics) [PSYoungGen: 64000K->63998K(74240K)] [ParOldGen: 169318K->169318K(169472K)] 233318K->233317K(243712K), [Metaspace: 20427K->20427K(1067008K)],0.1473386 secs] [Times: user=0.43 sys=0.01, real=0.15 secs]
    200.027: [Full GC (Ergonomics) [PSYoungGen: 64000K->63998K(74240K)] [ParOldGen: 169318K->169318K(169472K)] 233318K->233317K(243712K), [Metaspace: 20427K->20427K(1067008K)],0.1567794 secs] [Times: user=0.41 sys=0.00, real=0.16 secs]
    200.184: [Full GC (Ergonomics) [PSYoungGen: 64000K->63998K(74240K)] [ParOldGen: 169318K->169318K(169472K)] 233318K->233317K(243712K), [Metaspace: 20427K->20427K(1067008K)],0.1621946 secs] [Times: user=0.43 sys=0.00, real=0.16 secs]
    200.346: [Full GC (Ergonomics) [PSYoungGen: 64000K->63998K(74240K)] [ParOldGen: 169318K->169318K(169472K)] 233318K->233317K(243712K), [Metaspace: 20427K->20427K(1067008K)],0.1547695 secs] [Times: user=0.41 sys=0.00, real=0.15 secs]
    200.502: [Full GC (Ergonomics) [PSYoungGen: 64000K->63999K(74240K)] [ParOldGen: 169318K->169318K(169472K)] 233318K->233317K(243712K), [Metaspace: 20427K->20427K(1067008K)],0.1563071 secs] [Times: user=0.42 sys=0.01, real=0.16 secs]
    200.659: [Full GC (Ergonomics) [PSYoungGen: 64000K->63999K(74240K)] [ParOldGen: 169318K->169318K(169472K)] 233318K->233317K(243712K), [Metaspace: 20427K->20427K(1067008K)],0.1538778 secs] [Times: user=0.42 sys=0.00, real=0.16 secs]

从上面这段输出日志中可以看到，

*  这段日志输出的是JVM启动后200秒左右的信息
 *  在这780毫秒的实际内，JVM由于GC暂停了5次，这5次暂停都是Full GC导致的暂停。
 *  暂停的总时间为777毫秒，几乎是应用运行时间的99.6%
 *  同时，可以观察到老年代空间容量和消耗情况，在进行GC后整个老年代共169.472KB的空间被使用了169.318KB

从上面这段输出日志中我们可以知道这个应用运行状况不好，JVM几乎被垃圾回收给停止了，GC消耗了应用运行的99%的时间。并且Full GC也已经无法回收到多少内存空间了。这个应用在运行几分钟后，也抛出java.lang.OutOfMemoryError: GC overhead limit exceeded的错误并终止了。

通过分析GC日志可以发现：

1.  应用的GC负载过高。GC暂停时间越长，应用的吞吐量越低。一般来说，GC暂停时间超过应用运行时间的10%时，该应用已经处于不正常状况了
2.  单次暂停时间过长。单个暂停耗时越长，应用的延迟越显著。当应用的延迟性能要求应用的每次事务处理必须在1000毫秒内完成时，我们就要确保GC暂停时间不能超过1000毫秒
3.  **老年代内存使用达到极限**。当发生几次Full GC后，老年代空间的内存使用仍然达到其容量极限时，我们可以知道老年代空间已经成为应用的瓶颈了。这可能是由于老年代空间分配不足，或者应用发生了内存泄漏。

文章来源：[https://blog.csdn.net/dabokele/article/details/61430633][https_blog.csdn.net_dabokele_article_details_61430633]

[https_blog.csdn.net_dabokele_article_details_61430633]: https://blog.csdn.net/dabokele/article/details/61430633