荐 性能测试中你是否遇见过频繁fgc的问题呢？

前言：今天分享一个频繁fgc的问题，现象是接口响应时间太长了，达到了好几秒，远远高于预期的1秒。

xshell连接到应用服务器，服务器负载高，且cpu使用率也偏高。

使用jstat看了下gc的情况，fgc很频繁，老年代满了（下图的O列）

打开JvisualVM，双击对应的应用进程，然后进入Monitor，可以看到堆内存GC频繁。然后进入 Visual GC查看，发现堆内存Full GC非常频繁.

根据下面gc日志，Full GC Old区回收的内存很少。

现在情况就非常明显了，就是内存中有大量GC不掉的对象。

下面我们看看heap里面到底是些什么东西。切换到monitor，点击heap dump生成dump文件，然后把dump文件拷贝到本机进行分析。

分析dump文件，点击class，根据size排序，找到比较大且比较熟悉的实例，下面对红框中两个class进行分析。

sacToNoticeConfirmRequest这个class是业务接口，但是现在应用程序并没有请求sacToNoticeConfirm这个接口，为啥这个class会有这么多对象呢？

先分析其他对象，ConstraintViolationimpl这个class是dubboRPC请求对参数进行验证时需要的类，看看这个类的实例都是些什么内容：

看了多个实例后发现ConstraintViolationimpl这个class的实例对象都是因为RPC参数校验不通过生成的对象。我们在sacToNoticeConfirmRequest这个类里面使用了javax.validation这个包的注解，如果sacToNoticeConfirmRequest请求参数在RPC调用时参数校验不通过就会产生大量的ConstraintViolationimpl实例。我们继续分析sacToNoticeConfirmRequest这个class的实例：

终于知道这些GC不掉的内存是哪里来的了