Tomcat中session的管理机制

详细描述tomcat中session的管理机制：

1. 请求过程中的session操作：

简述：在请求过程中首先要解析请求中的sessionid信息，然后将sessionid存储到request的参数列表中。然后再从 request获取session的时候，如果存在sessionid那么就根据id从session池中获取session，如果sessionid不 存在或者session失效，那么则新建session并且将session信息放入session池，供下次使用。

(1)sessionid解析过程时序图：

概述：首先用户发送一个http请求传递给http11processor,经由http11processor解析封装在org.apache.coyote.request然后传递给coyoteadapter，coyoteadapter是一个适配器，将coyote框架封装的org.apache.coyote.request适配给org.apache.catalina.connector.request（这个流程不多说，之前都有总结过），转换完之后会调用parsepathparameters方法去解析路径参数中的cookie信息（因为当cookie被浏览器禁用时，会将cookie信息重写进url），先尝试从url中尝试解析出sessionid. 然后会调用parsesessioncookiesid,这个就是从cookie中解析sessionid存到request（parsepathparameters和parsesessioncookiesid方法，在调用过程中，没有看到明显的异或逻辑，即两者都执行了，但这样不是就有问题了吗？想想其实没有问题的，url重写设置sessionid或者放到cookie中传递过来，两者方式只会用一个，想到这点就知道没有问题了）解析到sessionid就放到了request里面。解析sessionid的逻辑就ok了。

下面贴出关键代码：

parsepathparameters方法（从重写url中解析）：

ps： 标记出来的部分分别是从url解析出变量，然后放到request参数列表里面。

parsesessioncookiesid方法（从cookie中解析出sessionid）:

ps: 上面的标记就是从cookie中获取sessionid.看第一个标记有个sessionconfig.getsessioncookiename（context）的调用，这里会获取到一个默认的sessionid的key，这个key是定义在sessionconfig中的，其值为jsessionid：

(2) 从请求中获取session的流程基本就是上文描述的这样。那么再看一下servlet获取session的流程：

概述：appservlet是我们自己定义的一个servlet，在通过reqest获取session的时候，其实调用的这个httpservletrequest（是一个接口）其实是requestfacade（封装了org.apache.catalina.connector.request的一个门面），然后requestfacade会调用真实的request的getsession方法。request具体的逻辑是调用context容器的getmanger方法获取session管理器（session管理器详情下文介绍），然后如果sessionid如果已经被解析出来了，那么则会调用findsession方法从session对象池中获取对应的session，反之如果sessionid不存在，则需要重新创建一个session，并放入session对象池中。

下面贴出关键代码：

类requestfacade的getsession方法：

类request的getsession方法：

类request的dogetsession方法：

ps：第一个标记就是根据sessionid从session对象池中获取session信息，第二标记就是在没有解析到sessionid的情况下创建一个新的session对象。

这个创建一个新的session这里点涉及到新的sessionid的生成，生成sessionid的逻辑关键代码是在类sessionidgenerator中的generatesessionid方法中定义：

以上即是servlet获取session的流程，下文具体总结一下tomcat是怎么来管理session的，即session管理器的知识。

2. session的管理机制

session管理器定义：session管理器组件负责管理session对象，例如，创建和销毁session对象。

首先看一张session管理器的类继承结构图（这个是tocmat7.x的图，tomcat5的类继承机构和这个有很大不同）：

简述：下面依次总结下每个类（参考官网信息）：

(1)manager：定义了关联到某一个容器的用来管理session池的基本接口。

(2)managerbase：实现了manager接口，该类提供了session管理器的常见功能的实现。

(3)standardmanager：继承自managerbase,tomcat的默认session管理器（不指定配置，默认使用这个），是tomcat处理session的非集群实现（也就说是单机版的），tomcat关闭时，内存session信息会持久化到磁盘保存为session.ser,再次启动时恢复。

(4)persistentmanagerbase：继承自managerbase，实现了和定义了session管理器持久化的基础功能。

(5)persistentmanager：继承自persistentmanagerbase，主要实现的功能是会把空闲的会话对象（通过设定超时时间）交换到磁盘上。

(6)clustermanager：实现了manager接口，通过类名应该能猜到，这个就是管理集群session的管理器和上面那个standardmanager单机版的session管理器是相对的概念。这个类定义类集群间session的复制共享接口。

(7)clustermanagerbase：实现了clustermanager接口，继承自managerbase。该类实现了session复制的基本操作。

(8)backupmanager：继承自clustermanagerbase， 集群间session复制策略的一种实现，会话数据只有一个备份节点，这个备份节点的位置集群中所有节点都可见。这种设计使它有个优势就是支持异构部署。

(9)deltamanager：继承自clustermanagerbase,集群建session复制策略的一种实现，和backupmanager不同的是，会话数据会复制到集群中所有的成员节点，这也就要求集群中所有节点必须同构，必须部署相同的应用。

补充：下面再具体总结一点就是在persistentmanagerbase类中有个成员变量store：

持久化session管理器的存储策略就是有这个store对象定义的，这个store的类继承结构如下：

简述：接口store及其实例是为session管理器提供了一套存储策略，store定义了基本的接口，而storebase提供了基本的实现。其中filestore类实现的策略是将session存储在以setdirectory（）指定目录并以.session结尾的文件中的。jdbcstore类是将session通过jdbc存入数据库中，因此需要使用jdbcstore，需要分别调用setdrivername()方法和setconnectionurl()方法来设置驱动程序名称和连接url。

3. tomcat session相关的配置

从两个层面总结一下session相关的配置和设置。首先是从配置文件层面，session是有过期时间的，这个默认的过期时间是在$catalina_home/conf/web.xml有定义的。具体的默认配置如下（默认的过期时间是30min，即30min没有访问，session就过期了）：

还有一点就是session管理如果不配置就默认使用standardmanager，但如果要配置的话可以在$catalina_home/conf/context.xml当中指定（其中从这个配置当中可以看到session管理器是和context容器关联的，也就说每个web应用都会有一个session管理器）具体的配置如下：

tomcat7.x默认这个manager的配置是注释掉的。如果要指定的persistentmanager为默认管理器的话可以这么指定：

其实看到这也就发现了，其实session管理器或者store存储策略，只要实现了相关的接口，都是可以自定义的。自己写一个配置在这里就ok了。

另外在从代码层面总结一下：session的一些配置信息是写死在代码里的，比如sessionconfig这个类就定义了一些session的设置信息。session在cookie中的名字是jsession. session通过url重写的方式放在path里时，键值的名字是jsessionids,具体的代码如下：

还有一点就是sessionid默认指定的长度是16个字节,这个在sessionidgenerator当中指定：

好了，有关默认配置的就先总结这么多。

以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持。