当前位置： 移动技术网 > IT编程>开发语言>JavaScript > 荐 性能测试中你是否遇见过频繁fgc的问题呢？

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

2020年07月08日  | 移动技术网IT编程  | 我要评论

前言：今天分享一个频繁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不掉的内存是哪里来的了

您可能感兴趣的文章:

如对本文有疑问， 点击进行留言回复！！

相关文章:

验证码：
最近更新的文章
大家感兴趣的文章
移动技术网