基于springboot系统，如何跟踪会话过期，浏览器会话标识是否收到正常响应，存储，并在后续请求保持携带

今天我们分享一个项目开发中的出现操作某个业务时候，出现闪退的经典问题，针对老旧的Spring MVC系统，要系统性地跟踪会话（Session）生命周期和Cookie的携带情况，我们需要一套清晰的、从浏览器到服务器的排查方案。以下是详细的跟踪步骤和方法。

当然这个排查步骤和方法，也适合基本SpringBoot开发的系统，但是服务端的排查需要大家根据实际情况修改后端排查日志、拦截器等方法

整体排查思路

我们的目标是验证以下三个环节是否正常：

1. 登录成功时：服务器是否正确生成了Session并返回了包含正确 JSESSIONID的Cookie给浏览器。

2. 浏览器端：浏览器是否成功接收并存储了该Cookie。

3. 后续请求：浏览器在执行查询等操作时，是否始终在请求头中携带了这个Cookie。

第一步：浏览器端跟踪（客户端验证）

这是最直接、最容易操作的第一步，可以由开发或运维人员在问题电脑上进行。

一、跟踪会话标识（Cookie）的接收与存储

1. 开启浏览器开发者工具：使用出现问题的浏览器（如奇安信、Chrome），按 F12打开开发者工具。

2. 切换到Network/网络面板：勾选 Preserve log(保留日志)​ 复选框，防止页面跳转时日志被清空。

3. 清空Cookie（可选，为了纯净的测试）：在开发者工具的 Application（应用）或 Storage（存储）标签页下，找到 Cookies，选中当前系统地址的Cookie，将其删除。这可以模拟一次全新的登录。

4. 执行登录：

   • 在地址栏输入系统单节点地址（如 http://10.15.9.106/...）进行登录。

   • 在Network面板中，找到登录请求（通常是 login或 j_spring_security_check之类的POST请求）。

   • 重点查看登录请求的响应：

     • 点击这个登录请求，查看 Response Headers（响应头）。

     • 你应该能看到一个 Set-Cookie头，内容类似于 JSESSIONID=ABCD1234...; Path=/; HttpOnly。

     • 记录下这个 JSESSIONID的值。

5. 验证Cookie存储：

   • 切换到 Application/应用标签页。

   • 在左侧找到 Cookies-> http://10.15.9.106。

   • 检查是否存在一个名为 JSESSIONID的Cookie，其值是否与刚才在响应头中看到的一致。

至此，我们验证了环节1和2。如果这里就出问题，那么根源在服务器响应或浏览器安全策略上。

二、跟踪后续请求的Cookie携带情况

1. 进行正常操作：登录成功后，在系统内进行一些不会触发闪退的简单操作，比如点击菜单。

2. 观察请求：在Network面板中，观察这些操作触发的Ajax或页面请求。

3. 检查请求头：随机点击几个后续请求，查看它们的 Request Headers（请求头）。

   • 必须找到一个 Cookie:头，其内容应包含 JSESSIONID=ABCD1234...（即登录时设置的那个值）。

   • 确保每个请求都携带了这个Cookie。

4. 触发闪退（关键步骤）：

   • 进行那个已知会引发闪退的查询操作。

   • 密切观察Network面板，在点击“查询”按钮后，瞬间发出的请求。

   • 重点检查触发闪退的那个特定查询请求：

     • 情况A（正常）：该请求的 Request Headers里正常携带了 JSESSIONID，但服务器返回了一个 302 Found状态码，Location指向登录页，或者直接返回了登录页的HTML（状态码200）。这说明问题出在服务器端，服务器主动废弃了会话。

     • 情况B（异常）：该请求的 Request Headers里没有​ Cookie头，或者 JSESSIONID的值变成了空、错误或一个新的值。这说明问题出在浏览器端，Cookie在发送前丢失了。

第二步：服务器端跟踪（代码与日志层面）

如果浏览器端跟踪指向了“情况A”（Cookie携带正常，但服务器返回登录页），那么问题根因在服务器内部。

一、启用详细日志记录（最有效的方法）

如果这个老系统可能日志不全，我们需要临时增加会话跟踪日志。

1.在web.xml中配置Session监听器：

创建一个类，实现 HttpSessionListener和 HttpSessionAttributeListener接口，并部署到生产环境。这个类可以记录Session的创建、销毁和属性变化。

import javax.servlet.http.HttpSessionEvent;
import javax.servlet.http.HttpSessionAttributeListener;
import javax.servlet.http.HttpSessionBindingEvent;
import java.util.logging.Logger; // 或使用Log4j、Slf4jpublic class SessionDebugListener implements HttpSessionListener, HttpSessionAttributeListener {private static final Logger logger = Logger.getLogger(SessionDebugListener.class.getName());@Overridepublic void sessionCreated(HttpSessionEvent se) {logger.info("！！！ Session被创建: ID=" + se.getSession().getId() + "， 时间=" + new java.util.Date());}@Overridepublic void sessionDestroyed(HttpSessionEvent se) {// 这是最关键的信息！会话何时、为何被销毁？logger.info("！！！ Session被销毁: ID=" + se.getSession().getId() + "， 时间=" + new java.util.Date() + "。 最后访问时间: " + new java.util.Date(se.getSession().getLastAccessedTime()));// 可以在这里打印堆栈信息，看是哪个线程触发了销毁Thread.dumpStack();}@Overridepublic void attributeAdded(HttpSessionBindingEvent event) {if ("user".equals(event.getName())) { // 监听用户登录属性logger.info("！！！ 用户登录成功，User对象被存入Session。 SessionID=" + event.getSession().getId() + ", User=" + event.getValue());}}@Overridepublic void attributeRemoved(HttpSessionBindingEvent event) {if ("user".equals(event.getName())) { // 监听用户登出属性logger.info("！！！ 用户登出，User对象从Session移除。 SessionID=" + event.getSession().getId());}}
}

在 web.xml中注册：

<listener><listener-class>com.yourcompany.SessionDebugListener</listener-class>
</listener>

2.在过滤器中记录请求：

在一个全局的Filter中（如果已有，则修改它），记录每个请求的Session状态。

public class SessionTrackingFilter implements Filter {@Overridepublic void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {HttpServletRequest req = (HttpServletRequest) request;HttpServletResponse res = (HttpServletResponse) response;String sessionId = req.getRequestedSessionId();boolean sessionValid = req.isRequestedSessionIdValid();logger.info("请求进入: URI=" + req.getRequestURI() + ", SessionID=" + sessionId + ", Session是否有效=" + sessionValid);chain.doFilter(request, response);// 请求处理后，再次检查Session状态sessionValid = req.isRequestedSessionIdValid();logger.info("请求离开: URI=" + req.getRequestURI() + ", Session是否有效=" + sessionValid);}
}

部署这些监听器和过滤器后，重现闪退问题。然后立即查看服务器日志，寻找 ！！！ Session被销毁这条关键日志。它会告诉你Session被销毁的精确时间，结合堆栈信息，就能定位到是哪个代码路径或配置触发了销毁。

二、分析服务器线程栈

如果怀疑是会话锁超时，需要在闪退发生时，立刻获取服务器的线程堆栈快照（jstack <pid>）。分析快照，看是否有线程长时间持有Session锁（状态为 RUNNABLE且正在执行查询SQL），而其他线程在等待这个锁（状态为 BLOCKED）。

总结：跟踪流程一览表

步骤	跟踪点	方法	期望结果	异常结果与含义
1​	浏览器接收Cookie​	F12 -> Network -> 查看登录请求的 Set-Cookie响应头	收到正确的 JSESSIONID	未收到：服务器响应问题
2​	浏览器存储Cookie​	F12 -> Application -> Cookies	存储了正确的 JSESSIONID	未存储：浏览器安全策略阻止
3​	后续请求携带Cookie​	F12 -> Network -> 查看查询请求的 Cookie请求头	携带了登录时的 JSESSIONID	未携带/值错误：浏览器端Cookie丢失
4​	服务器处理请求​	查看服务器日志/监听器日志	Session有效，请求正常处理	日志显示Session被销毁：服务器端主动废弃会话
5​	服务器并发情况​	分析线程堆栈快照 (jstack)	无长时间锁等待	有线程因等待Session锁而阻塞：会话锁超时问题

请按照这个流程进行操作，很大概率能直接定位到问题发生的具体环节。先从浏览器端跟踪开始，这通常能给出最直接的线索。