记一次使用gdb诊断gc问题全过程

最新推荐文章于 2024-10-02 22:12:47 发布

扣钉日记

最新推荐文章于 2024-10-02 22:12:47 发布

阅读量111

点赞数

文章标签： linux java jvm

本文链接：https://blog.csdn.net/fm18771120556/article/details/128884534

版权

本文详细记录了一次使用gdb诊断并解决Java GC中大对象分配问题的过程，涉及async-profiler的局限性，如何编写gdb脚本追踪特定函数参数，以及最终如何发现并修复问题。

摘要由CSDN通过智能技术生成

简介

上次解决了GC长耗时问题后，系统果然平稳了许多，这是之前的文章《GC耗时高，原因竟是服务流量小？》
然而，过了一段时间，我检查GC日志时，又发现了一个GC问题，如下：
image_2023-02-04_20230204143644
从这个图中可以发现，我们GC有一些尖峰，有时会突然有大量的内存分配。

查看GC日志，发现有大对象分配的记录，如下：

$ grep 'concurrent humongous allocation' gc.log | awk 'match($0,/allocation request: (\w+) bytes/,a){print a[1]}' |sort -nr
1941835784
1889656848

image_2023-02-04_20230204143322
可以看到，一次大对象分配，分配大小竟然有1.9G，这谁能抗得住啊！

async-profiler定位大对象分配

上面提到的文章介绍过，使用async-profiler可以很容易的定位大对象分配的调用栈，方法如下：

./profiler.sh start --all-user -e G1CollectedHeap::humongous_obj_allocate -f ./humongous.jfr jps

然后使用jmc打开humongous.jfr文件，调用栈如下：
image_2023-02-04_20230204180005

这是在做thrift反序列化操作，调用了TCompactProtocol.readDouble方法，方法代码如下：
image_2023-02-04_20230204144842
可是，这里只创建了8字节的数组，怎么也不可能需要分配1.9G内存吧，真是奇了怪了！

经过一番了解，这是因为async-profiler是通过AsyncGetCallTrace来获取调用栈的，而AsyncGetCallTrace获取的栈有时是不准的，Java社区有反馈过这个问题，至今未解决。
image_2023-02-04_20230204171551
问题链接：https://bugs.openjdk.org/browse/JDK-8178287