整个创建 Session 的过程比较简单,就是实例化 StandardSession 对象并设置其基本属性,以及生成唯一的 sessionId,其次就是记录创建时间,关键代码如下所示:
在 tomcat 中是可以限制 session 数量的,如果需要限制,请指定 Manager 的 maxActiveSessions 参数,默认不做限制,不建议进行设置,但是如果存在恶意攻击,每次请求不携带 Cookie 就有可能会频繁创建 Session,导致 Session 对象爆满最终出现 OOM。另外 sessionId 采用随机演算法生成,并且每次生成都会判断当前是否已经存在该 id,从而避免 sessionId 重复。而 StandardManager 是使用 ConcurrentHashMap 存储 session 对象的,sessionId 作为 key,org.apache.catalina.Session 作为 value。此外,值得注意的是 StandardManager 创建的是 tomcat 的 org.apache.catalina.session.StandardSession,同时他也实现了 servlet 的 HttpSession,但是为了安全起见,tomcat 并不会把这个 StandardSession 直接交给应用程序,因此需要调用 org.apache.catalina.Session#getSession() 获取 HttpSession。
前面我们分析了 Session 的创建过程,而 Session 会话是有时效性的,下面我们来看下 tomcat 是如何进行失效检查的。在分析之前,我们先回顾下 Container 容器的 Background 线程。
tomcat 所有容器组件,都是继承至 ContainerBase 的,包括 StandardEngine、StandardHost、StandardContext、StandardWrapper,而 ContainerBase 在启动的时候,如果 backgroundProcessorDelay 参数大于 0 则会开启 ContainerBackgroundProcessor 后台线程,调用自己以及子容器的 backgroundProcess 进行一些后台逻辑的处理,和 Lifecycle 一样,这个动作是具有传递性的,也就是说子容器还会把这个动作传递给自己的子容器,如下图所示,其中父容器会遍历所有的子容器并调用其 backgroundProcess 方法,而 StandardContext 重写了该方法,它会调用 StandardManager#backgroundProcess() 进而完成 Session 的清理工作。看到这里,不得不感慨 tomcat 的责任