LoadRunner性能测试引发的内存溢出(续)-DWR代码分析

        接上一篇深入分析DWR代码的处理逻辑，仅保留了说明问题的主干代码；

        先看DWR的相关数据结构：DefaultScriptSessionManager中有两个相对重要的ConcurrentHashMap：sessionMap和sessionXRef，

             sessionMap 以ScriptSessionId为key保存ScriptSessionId与ScriptSession的关系；

             sessionXRef 以SessionID为key保存SessionID和ScriptSessionId的关系(见后面的代码)；

             ScriptSession 则是通过内置的一个attributes Map保存其归属的SessionID；

        当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；