在一次性能压测中，发现Java应用程序频繁FullGC，但老年代占用仅3%，通过jmap分析发现Fastjson对象占用较高。进一步排查发现，代码中Fastjson序列化配置对象每次请求都会动态加载类到Metaspace，导致内存泄露。通过修改配置对象为全局静态变量，解决了FullGC问题，提高了接口性能。
01 起因
前几天，群里一个学员发消息，说在压测时发现某应用程序jvm中FullGC特别多，不知道正常不正常，并把gc的截图发了出来。点开一看是这个样子
这是 jstat监控 的截图，FGC那列代表数字代表从应用启动开始到目前为止FullGC发生的次数，数据是每秒打印一行，所以从图里可以看出，FullGC次数从2735到2736，只用了10秒，也就是大概10秒就会发生一次FullGC，这种频率对于一个Java程序来说太过于频繁了。每次FullGC都会造成应用程序的暂停，从而引起响应时间边长，程序性能也严重下降。从图里也能印证这一点，每次FullGC花费的时间在400ms多。
02 分析
图里也有一个奇怪的现象，一般发生FullGC，都是因为jvm中老年代空间不足引起的，图中第4列就是老年代的数据，图里可以看到，老年代只占用了3%左右，远远达不到上限100%。
学员表示在这种情况下，用10并发去压测接口，tps大概900多，看起来性能还可以，但是FullGC这么频繁肯定是有问题，还是需要排查下的。
也没考虑太多，既然FullGC这么频繁，那就看看jvm中对象的分配情况吧，于是让同学用 jmap 去打印下堆内存中的对象信息，结果如下：
最低0.47元/天 解锁文章
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
