LoadRunner性能测试引发的内存溢出(续)-DWR代码分析
接上一篇深入分析DWR代码的处理逻辑，仅保留了说明问题的主干代码；
先看DWR的相关数据结构：DefaultScriptSessionManager中有两个相对重要的ConcurrentHashMap：sessionMap和sessionXRef，
sessionMap 以ScriptSessionId为key保存ScriptSessionId与ScriptSession的关系；
sessionXRef 以SessionID为key保存SessionID和ScriptSessionId的关系(见后面的代码)；
ScriptSession 则是通过内置的一个attributes Map保存其归属的SessionID；
【LoadRunner性能测试引发的内存溢出(续)-DWR代码分析】
当httpRequest被BaseCallHandler类的handle()方法处理时，DefaultWebContext类的checkPageInformation()方法被调用，而后者又调用了DefaultScriptSessionManager类的getScriptSession()方法；
从代码可以看出sessionMap首先保存ScriptSessionId与ScriptSession的对应关系，再通过调用associateScriptSessionAndHttpSession()方法在sessionXRef中保存SessionID和ScriptSessionId的关系；超时检查方法checkTimeouts稍候描述；
DefaultScriptSessionManager的getScriptSession()方法首先执行Timeout的检查，遍历sessionMap中的ScriptSession，超时的ScriptSession会被标记随后执行invalidate()方法；
invalidate()方法中首先进行sessionMap的清理，再调用disassociateScriptSessionAndHttpSession()方法清理sessionXRef；
LoadRunner脚本提交http请求时使用了固定的几个ScriptSessionId，从而导致Tomcat内存溢出，gc无法回收；
综上所述，sesssionMap中只会保存LoadRunner脚本中设置的ScriptSessionId；事实上，脚本中一共使用了7个ScriptSessionId，检查堆内存dump对象后，sessionMap中确实也就只有7条数据；
当携带相同ScriptSessionId的请求到来时，sessionMap中保存的ScriptSession会被更新：lastAccessedTime，SessionID，由于lastAccessedTime不停的被更新，从而导致ScriptSession始终不会过期，而SessionID的更新导致sessionXRef中旧SessionID对应的ScriptSessionIds再也无法回收；sessionXRef中为每个SessionID保存了7个ScriptSessionId；
只有把LoadRunner停止，等待一段时间，可以观察到ScriptSession过期的日志；sessionMap中的数据被正常清理，而sessionXRef中的最后一批SessionID的数据也会被清理，但是GC对上面所说的老SessionID对应的ScriptSessionIds无能为力；可以看下老生代内存对象做个证明；正如前面所分析的，每个SessionId下有7个ScriptSessionId；
推荐阅读
- 女生该不该用小号测试男朋友（）
- BNC公链|BNC公链 | Eth2.0测试网Topaz已质押超100万枚ETH
- 我的软件测试开发工程师书单
- 数据库|SQL行转列方式优化查询性能实践
- 性能测试中QPS和TPS的区别
- 如何在手机上查看测试vue-cli构建的项目
- 工作好忙
- javascript|javascript 性能测试笔记
- 灵魂测试……
- Android智能手表MMI测试检测系统