Session 的默认失效时间是多长？如何配置和修改？
Session 的默认失效时间是多久？如何配置和修改？
- 1. 引言：停车场的“免费停车券”
- 2. 前置知识：Session 是什么？它为什么需要“失效”？
- 3. 默认失效时间是多少？
- 4. Session 超时的工作原理
- 5. 如何配置和修改 Session 超时时间？
- 5.1 方式一：编程方式（动态设置，优先级最高）
- 5.2 方式二：web.xml（全局配置，中等优先级）
- 5.3 方式三：容器配置（全局默认，优先级最低）
- 5.4 优先级总结
- 6. 配置对比表
- 7. 常见误区与注意事项
- 8. 集群环境下的特殊注意事项
- 9. 最佳实践：如何设置合理的超时时间？
- 10. 总结
1. 引言：停车场的“免费停车券”
想象你开车进入一个商场的地下停车场。入口闸机给你一张停车券（Session），上面写着：“免费停车 30 分钟”。如果你在 30 分钟内开车离开，闸机自动抬杆放行；如果超过 30 分钟，就需要额外缴费才能出去。但是，如果你在 25 分钟时开车到出口转了一圈又回来，停车券上的时间会重置吗？答案是：会的——只要你“刷一次卡”，计时就从此刻重新开始。
在 Web 世界中，Session 的超时时间就像这张停车券的免费时长。用户在网站上的每次操作（请求）都会刷新这个计时器，如果用户在设定的时间内没有发出任何请求，服务器就会认为用户“离开了”，于是销毁 Session，释放内存资源。本文将带你全面了解 Session 的默认失效时间、配置方式以及背后的原理。
2. 前置知识：Session 是什么？它为什么需要“失效”？
在深入了解超时时间之前，我们先快速回顾一下 Session 的基本概念。
Session（会话）是服务器为每个用户分配的一块私有数据空间，用来存储登录状态、购物车、验证码等信息。服务器通过一个唯一的Session ID来识别这块空间属于谁。
为什么需要“失效时间”？因为用户可能关掉浏览器、离开电脑，或者长时间不操作。如果不设置超时，这些“僵尸 Session”会一直占用服务器内存，最终导致内存耗尽、服务崩溃。设置合理的超时时间，是资源回收和用户体验之间的平衡。
3. 默认失效时间是多少？
不同应用服务器的默认值略有差异，但业界最常用的是Tomcat，它的默认值是：
30 分钟（1800 秒）
这意味着：用户最后一次请求后，如果在 30 分钟内没有新的请求，Session 就会自动过期，释放服务端资源。
4. Session 超时的工作原理
超时检测由容器（如 Tomcat）的后台线程负责，流程如下：
- 每个 Session 记录两个关键时间：
lastAccessedTime（最后一次访问时间）和maxInactiveInterval（最大空闲间隔，即超时时间）。 - 后台线程定期扫描所有 Session，计算
当前时间 - lastAccessedTime。 - 如果差值 >=
maxInactiveInterval，则将该 Session 标记为过期，触发销毁事件（如HttpSessionListener.sessionDestroyed()），并从内存中移除。
关键点：
- 用户每次请求时，
lastAccessedTime会被更新为当前时间。 - 超时时间是空闲时间，不是从创建开始的总存活时间。
5. 如何配置和修改 Session 超时时间？
有三种主流方式，按优先级从高到低排列：
| 方式 | 配置位置 | 单位 | 优先级 | 适用范围 |
|---|---|---|---|---|
| 编程方式 | session.setMaxInactiveInterval() | 秒 | 最高 | 单个 Session（动态设置） |
| web.xml | <session-timeout> | 分钟 | 中等 | 整个 Web 应用（所有 Session） |
| 容器配置 | Tomcat 的conf/web.xml | 分钟 | 最低 | 容器中所有应用（全局默认） |
5.1 方式一：编程方式（动态设置，优先级最高）
在代码中针对当前 Session单独设置超时时间：
// 设置当前 Session 的超时时间为 15 分钟（注意单位是秒）HttpSessionsession=request.getSession();session.setMaxInactiveInterval(15*60);// 15 × 60 = 900 秒// 设置为 0 表示立即过期（下次访问时失效）// session.setMaxInactiveInterval(0);// 设置为负数表示永不超时（慎用！）// session.setMaxInactiveInterval(-1);适用场景：
- 对特定用户（如管理员）设置更长的超时时间。
- 敏感操作（如支付页面）要求更短的超时。
5.2 方式二：web.xml（全局配置，中等优先级）
在 Web 应用的WEB-INF/web.xml中添加配置，对所有 Session 生效：
<web-app>...<session-config><session-timeout>15</session-timeout><!-- 单位：分钟 --></session-config>...</web-app>注意：这里的单位是分钟，与编程方式的秒不同，容易混淆。
5.3 方式三：容器配置（全局默认，优先级最低）
在 Tomcat 的conf/web.xml中修改，作为所有应用的默认值：
<session-config><session-timeout>30</session-timeout><!-- Tomcat 默认 30 分钟 --></session-config>如果应用自己的web.xml没有配置，则使用此默认值。
5.4 优先级总结
编程方式（session.setMaxInactiveInterval） > web.xml > 容器配置也就是说，代码中的设置会覆盖配置文件中的值。
6. 配置对比表
| 配置方式 | 位置 | 单位 | 生效范围 | 示例 |
|---|---|---|---|---|
| 编程方式 | Java 代码 | 秒 | 单个 Session | session.setMaxInactiveInterval(900) |
| web.xml | WEB-INF/web.xml | 分钟 | 整个应用 | <session-timeout>15</session-timeout> |
| 容器配置 | Tomcatconf/web.xml | 分钟 | 所有应用 | <session-timeout>30</session-timeout> |
7. 常见误区与注意事项
| 误区 | 正解 |
|---|---|
“修改web.xml会影响已创建的 Session” | ❌ 错误。只对新创建的 Session 生效，现有 Session 沿用创建时的超时值。 |
“setMaxInactiveInterval(0)会立即销毁 Session” | ❌ 部分正确。设置为 0 后，该 Session 在下次访问时会立即失效，但不会主动销毁。 |
| “负数表示永久有效” | ✅ 是的，但慎用。设置为-1表示永不超时，除非主动调用invalidate()，否则会一直占用内存，极易导致内存泄漏。 |
| “单位混淆” | ⚠️web.xml中是分钟，编程方式是秒。常见错误是写成session.setMaxInactiveInterval(15)以为是 15 分钟，实际是 15 秒。 |
8. 集群环境下的特殊注意事项
在分布式系统（多台服务器）中，如果使用 Redis 等外部存储共享 Session，还需要注意：
- 确保超时配置一致：所有节点、Redis 的 TTL 配置必须统一，否则可能出现“A 节点认为 Session 有效，Redis 已过期”的不一致。
- Redis TTL：在存储 Session 到 Redis 时，应设置与
maxInactiveInterval相同的过期时间，避免数据残留。
// 示例：Spring Session + Redis 自动处理 TTL，无需手动干预spring.session.timeout=15m// 单位：分钟9. 最佳实践：如何设置合理的超时时间？
| 场景 | 推荐超时时间 | 理由 |
|---|---|---|
| 普通 Web 应用（如电商、论坛） | 15-30 分钟 | 平衡用户体验与资源占用 |
| 管理后台（内部系统） | 15-30 分钟 | 安全要求较高，不宜过长 |
| 敏感操作（支付、修改密码） | 5-10 分钟 | 防止长时间未操作被他人利用 |
| 永不超时（如自动签到服务） | ❌ 避免 | 必须配合主动销毁，否则内存泄漏 |
| 移动端 / SPA 应用 | 配合 Refresh Token 机制，Session 可设短（如 15 分钟） | 由 Refresh Token 自动续期 |
10. 总结
| 核心要点 | 说明 |
|---|---|
| 默认值 | Tomcat 默认 30 分钟（1800 秒） |
| 配置方式 | 编程 > web.xml > 容器配置 |
| 单位 | web.xml用分钟，编程用秒（切记） |
| 原理 | 后台线程扫描lastAccessedTime + maxInactiveInterval |
| 最佳实践 | 15-30 分钟通用，敏感场景更短，避免用负数 |
Session 的超时时间是 Web 应用运维的基础配置之一。设置太短，用户频繁掉线；设置太长，内存浪费甚至 OOM。理解其原理和配置方法，是写出健壮、高效应用的必修课。