目前性能测试组正在对独立秒杀进行性能压测，性能抖动特别厉害。
由于独立秒杀的接口大多数是经过volicity渲染过的页面和数据的整合，所以在压测的时候有很多volicity的错误。初步判定，感觉是volicity的性能问题才导致的。但是通过排查volicity发现，此版本没有网传的性能问题，而且代码层面上也没见到有过多的性能问题点。
之后通过查看jvm的堆内内存才发现，老年代的内存无法释放，总是会经过很长一段时间，大概三十四分钟后才会释放。感觉很奇怪：
从上图可以看到，堆内内存涨上去后，基本上就下不来了， 这些没释放的内存，基本上都在老年代。初步判定为jvm堆内内存要么有大对象，要么什么东西一直持有，并未释放。
之后从服务器上dump数据下来，然后通过mat加载后，得到的分析如下：
可以看到，系统中，有一个ConcurrentHashMap的容器里面，貌似对每个http请求，都做了一次缓存。考虑到目前做的是压测，那么也就是说瞬间涌入千万级别的请求也不为过，ConcurrentHashMap的体积在很短的时间就会暴涨，势必会带来频繁的gc问题。如果只是保存http请求状态，为什么http请求完毕，不会释放呢？
带着疑问去应用里面进行排查，发现应用里面根本没有直接使用ConcurrentHashmap对象。那么也就是说ConcurrentHashmap对象也许是存在什么jar包里面了。经过排查jar包，也没发现什么地方使用concurrenthashmap，顿时陷入了死局。
后来，压测组发来一篇文章：压力测试中JVM内存暴涨原因分析实战, 看完文章，和我的遭遇非常一致，联想到目前压测直接使用ip+端口压测，直接打到tomcat上进行压测，而且接口返回数据都是经过velocity渲染的模板和数据组合，是有前端页面的。所以说，按照文章中的说法，应该是tomcat对每一个进来的请求都会将状态会话保持放到ConcurrentHashmap中导致的，而且这个状态会话保持默认30分钟后过期，这也是为啥GC一直下不来的原因了。
为了印证此说法，按照此文的建议， Memory Fully utilized by Java ConcurrentHashMap (under Tomcat)，在web.xml中设置session过期时间为1分钟：
<session-config>
<session-timeout>1</session-timeout>
</session-config>之后修改代码，上预发，然后让压力机单压预发这台机器，可以看到堆内存回收如下：
可以看到当堆内存打到极高点后，jvm很快进行了一次回收，而且此次回收比较彻底。
验证完毕，看来是这个原因。希望对你有帮助。