Java GC问题排查的一些个人总结和问题复盘

个人博客

Java GC问题排查的一些个人总结和问题复盘 | iwts’s blog

是否存在GC问题判断指标

有的比较明显，比如发布上线后内存直接就起飞了，这种也是比较好排查的，也是最多的。如果单纯从优化角度，看当前应用是否需要优化，有一些指标判断：

1. 延迟（Latency）：也可以理解为最大停顿时间，即STW最长时间。
2. 吞吐量（Throughput）：例如系统运行了 100 min，GC 耗时 1 min，则系统吞吐量为 99%。

两者是结合的，延迟越低越好，而吞吐量一般有各个业务指标，例如TP999，即99.9%的吞吐量，TP9999则是99.99%。

一般来说尤其是技术还不错的大厂，除了发布是很难碰到相关问题的。。尤其是阿里这种比较卷比的，早就优化甚至为了ppt而优化给整完了，确实没啥优化空间。

包括JVM在内，这种东西能不碰就不碰，真的性价比不高。不过日常代码还是要注意，比如内存泄露这种代码就别写出来了。

这里主要还是聊聊如果真碰到了问题，或者性能不是很行，想要分析是否是GC的话，有一些我个人工作的经验总结以及之前看到的解决方案的分析。

通用排查流程

GC日志分析

有一些网站，dump下来GC日志后上传上去，各种可视化信息。例如：Universal JVM GC analyzer - Java Garbage collection log analysis made easy

分析JVM内存配置

jmap -heap {
   
   pid}

先看看JVM启动参数&各代内存分配情况：

先看看分代参数不合理是否会影响本次GC问题。

堆内存对象大小分析

查看存活对象中的实例数量&具体占用内存大小：

jmap -histo 7276 | head -n20

后面的可以忽略，只看前面一部分就ok。

或者直接>重定向写到log中，慢慢看。</