一次由于垃圾session分配造成的内存惨案

测试一个http交互的性能负载模型，在测试过程中发现JVM内存随着测试的进行不停被消耗，直至被消耗完毕，彻底over失去响应。由于该项目目前阶段用户量还相对有限，对性能的需求不是很强烈，这种问题放过貌似也关系不大，不过抱着求甚解的生活态度，还是刨根问底的分析了一次。

主要采用的是新发布的visualVM1.2.2版本分析,VisualVM伴随着jdk1.6的发布一起推出，后期又进行了几次升级，功能确实已经越来越strong了，jprofiler之类的第三方工具也开始变得越来越没立足之地。

在压力负载下，采用jmap -histo 进程号|head -n 20分析消耗堆存最大的几个进程，java.util.concurrent.ConcurrentHashMap$Segment等几个类占用了大多数，网上查了下，该类继承自tomcat中的session容器，也就是说，每次新的http连接时，tomcat容器都自动分配了session。

so，问题的症结在于，loadrunner没有附带cookie和url重写，也就没有JSESSIONID信息，导致每一个请求，容器都会创建一个新的session，强负载的请求下， session被不停的创建，导致内存被大量消耗。

解决办法也很简单：在服务端web.xml中设置<session-timeout>3</session-timeout>,暂时将session的超时回收时间设置为3分钟（默认是24小时），再次测试，内存泄漏问题解决。考虑到实际情况，现网把该参数设置为30分钟。

问题已经水落石出，另外说明下，如果是在IE浏览器环境下，一般访问都是会附带cookie信息的，不会出现每个请求都需要创建session的情况，但我们的产品是无线交互产品，并不能保证cookie信息的携带，所以该问题还是存在的，需要适当的配置session失效时间以避免性能问题的出现，否则对大容量，大并发，需要长期稳定运行的系统很可能会带来很无谓的负载。