一个 Web 应用对应一个会话管理器，也就是说 StandardContext 内部有一个 Manager 实例。每个容器组件都会启动一个后台线程，周期的调用自身以及内部组件的 backgroundProcess() 方法，Manager 后台处理就是检查 Session 是否过期。
检查的逻辑是，获取所有 session 使用它的 isValid 判断是否过期，代码如下：
public boolean isValid() { ... // 是否检查是否活动，默认 false if (ACTIVITY_CHECK && accessCount.get() > 0) { return true; } // 检查时间是否过期 if (maxInactiveInterval >= 0) { long timeNow = System.currentTimeMillis(); int timeIdle = (int) ((timeNow - thisAccessedTime) / 1000L); if (timeIdle >= maxInactiveInterval) { // 如果过期，执行一些内部处理 // 主要是通知对过期事件感兴趣的 listeners expire(true); } } // 复数永不过期 return (this.isValid); } 3.3 Session 持久化持久化就是把内存中活动的 Session 对象，序列化到文件，或者存储到一个数据库中。如果会话管理组件符合并启用了持久化功能，那么就会在它生命周期事件 stop 方法中执行存储；在 start 方法中执行加载。
持久化到文件，StandardManager 也提供了持久化到文件的功能，它会把 session 池中活动的会话全部写入到CATALINA_HOME/work/Catalina/<host>/<webapp>/SESSIONS.ser文件中，代码在它的 doUnload 方法中。
FileStore 也提供了持久化到文件的功能，与 StandardManager 的区别是，它会把每个会话写入到单个文件中，以 <id>.session 命名。
持久化到数据库，分别把 session 相关数据存储到一个表中，包括序列化后的二进制数据，表字段信息如下:
create table tomcat_sessions ( session_id varchar(100) not null primary key, valid_session char(1) not null, -- 是否有效 max_inactive int not null,-- 最大有效时间 last_access bigint not null, -- 最后访问时间 app_name varchar(255), -- 应用名，格式为 /Engine/Host/Context session_data mediumblob, -- 二进制数据 KEY kapp_name(app_name) );注意：需要把数据库驱动程序的 jar 文件，放到 $CATALINA_HOME/lib 目录中，以便让 Tomcat 内部的类加载器可见。
4. 小结本文简单分析了 Tomcat 对 Session 的管理，当然了忽略了很多细节，有兴趣的可以深入源码，后续将会对 Tomcat 集群 Session 的实现进行分析。如有疑问，欢迎留言交流。