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管理器的常见功能的实现。