案列背景

最近在做公司项目核心接口压测和稳定性压测时，各接口的成功率不足99.99%，通过分割压测之后发现，在压测A服务时，内存上升明显，且伴有频繁的fgc发生

 jvm老年代内存使用率已经达到了100%且应用的fgc有5000+次，fgc频率大概在2s左右，怀疑有内存泄漏问题产生

压测工具tps表现和现象

内存飙升导致频繁的fgc，导致在压测时出现tps不稳定现象，出现毛刺现象

 Tps火焰图如下：

 

排查过程

内存dump,Mat分析

出现内存100%之后，将A服务的内存dump文件拿到之后，使用MAT工具分析，mat显示如下：

从MAT工具上显示，有大量的SessionImpl对象存在，怀疑内存泄漏发生在此处

源码追踪 

通过跟踪源码，找到了InMemorySessionManager相关代码，并跟踪到了SessionImpl实例类代码如下：

调用处：

 

在哪里调用了InMemorySessionmanager#createSession方法？ 

此时发现有多出地方会调用该方法，无法确定是由哪里导致Session创建的

额外发现 

通过使用jstat -gcutil 1 1000观察A服务的pod内存和gc情况，当压测一段时间之后停止压测，观察一段时间，发现pod的内存会逐步往下掉，最终内存会回退到正常范围，怀疑有SessionImpl过期清除机制。同时，在以上InMemorySessionManager代码中发现了如下方法：

 

此处会定期清理session对象。

跟踪整个调用栈：

SessionImpl#maxInactiveInterval--->InMemorySessionManager#defaultSessionTimeout=30*60

InMemorySessionManager提供了方法setDefaultSessionTimeout方法可以修改此处属性

在UndertowServletWebServerFactory中有关于session的超时设置

 为此，查询springboot自动装配关于session过期的设置：

为了验证是否是由于该处设置引起的，增加关于session过期的设置，并且设置过期时间10s，再次压测：

此时，内存的上升速度没变，但是每次经过fgc

(cms垃圾收集器-XX:CMSInitiatingOccupancyFraction=70),内存回退到正常状态

SessionImpl是有哪里创建的

通过对比不同的服务之前的内存增长差异情况，发现之后A会出现如上内存快速增长情况。再结合session过期设置的验证效果，查询了A的业务代码发现如下代码：

 

其中@ModelAttribute注解使用在方法上时，会在每次调用Control的方法前都会调用，注意到：

this.session = request.getSession();跟踪代码，发现最终会调用到InMemorySessionManager#getSession方法创建大量的SessionImpl存入到Sessions(一个ConcurrentHashMap)

至此，内存泄漏的最终元凶找到了

 

再次验证

 在A服务中，去掉对BaseController的继承，再次压测心跳接口，此时应用内存和gc恢复正常

总结

1 确定内存泄漏对象

出现内存泄漏问题，首先获取服务内存映射(当让也可以使用:(jmap  -histo:live   1 |head -20查看内存大对象)，然后查看内存类。

2 分析代码，查询资料，确定泄漏来源