如何追踪SpringBoot系统会话过期及浏览器标识响应存储与携带？

今天我们分享一个项目开发中的出现操作某个业务时候，出现闪退的经典问题，针对老旧的Spring MVC系统，要系统性地跟踪会话（Session）生命周期和Cookie的携带情况，我们需要一套清晰的、从浏览器到服务器的排查方案。以下是详细的跟踪步骤和方法。 当然这个排查步骤和方法，也适合基本SpringBoot开发的系统，但是服务端的排查需要大家根据实际情况修改后端排查日志、拦截器等方法 整体排查思路 我们的目标是验证以下三个环节是否正常： 登录成功时：服务器是否正确生成了Session并返回了包含正确 JSESSIONID的Cookie给浏览器。 浏览器端：浏览器是否成功接收并存储了该Cookie。 后续请求：浏览器在执行查询等操作时，是否始终在请求头中携带了这个Cookie。 第一步：浏览器端跟踪（客户端验证） 这是最直接、最容易操作的第一步，可以由开发或运维人员在问题电脑上进行。 一、跟踪会话标识（Cookie）的接收与存储 开启浏览器开发者工具：使用出现问题的浏览器（如奇安信、Chrome），按 F12打开开发者工具。 切换到Network/网络面板：勾选 Preserve log(保留日志)​ 复选框，防止页面跳转时日志被清空。 清空Cookie（可选，为了纯净的测试）：在开发者工具的 Application（应用）或 Storage（存储）标签页下，找到 Cookies，选中当前系统地址的Cookie，将其删除。这可以模拟一次全新的登录。 执行登录： 在地址栏输入系统单节点地址（如 http://10.15.9.106/...）进行登录。 在Network面板中，找到登录请求（通常是 login或 j_spring_security_check之类的POST请求）。 重点查看登录请求的响应： 点击这个登录请求，查看 Response Headers（响应头）。 你应该能看到一个 Set-Cookie头，内容类似于 JSESSIONID=ABCD1234...; Path=/; HttpOnly。 记录下这个 JSESSIONID的值。 验证Cookie存储： 切换到 Application/应用标签页。 在左侧找到 Cookies-> http://10.15.9.106。 检查是否存在一个名为 JSESSIONID的Cookie，其值是否与刚才在响应头中看到的一致。 至此，我们验证了环节1和2。如果这里就出问题，那么根源在服务器响应或浏览器安全策略上。 二、跟踪后续请求的Cookie携带情况 进行正常操作：登录成功后，在系统内进行一些不会触发闪退的简单操作，比如点击菜单。 观察请求：在Network面板中，观察这些操作触发的Ajax或页面请求。 检查请求头：随机点击几个后续请求，查看它们的 Request Headers（请求头）。 必须找到一个 Cookie:头，其内容应包含 JSESSIONID=ABCD1234...（即登录时设置的那个值）。 确保每个请求都携带了这个Cookie。 触发闪退（关键步骤）： 进行那个已知会引发闪退的查询操作。 密切观察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、Slf4j public class SessionDebugListener implements HttpSessionListener, HttpSessionAttributeListener { private static final Logger logger = Logger.getLogger(SessionDebugListener.class.getName()); @Override public void sessionCreated(HttpSessionEvent se) { logger.info("！！！ Session被创建: ID=" + se.getSession().getId() + "， 时间=" + new java.util.Date()); } @Override public void sessionDestroyed(HttpSessionEvent se) { // 这是最关键的信息！会话何时、为何被销毁？ logger.info("！！！ Session被销毁: ID=" + se.getSession().getId() + "， 时间=" + new java.util.Date() + "。 最后访问时间: " + new java.util.Date(se.getSession().getLastAccessedTime())); // 可以在这里打印堆栈信息，看是哪个线程触发了销毁 Thread.dumpStack(); } @Override public void attributeAdded(HttpSessionBindingEvent event) { if ("user".equals(event.getName())) { // 监听用户登录属性 logger.info("！！！ 用户登录成功，User对象被存入Session。 SessionID=" + event.getSession().getId() + ", User=" + event.getValue()); } } @Override public 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 { @Override public 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锁而阻塞：会话锁超时问题 请按照这个流程进行操作，很大概率能直接定位到问题发生的具体环节。先从浏览器端跟踪开始，这通常能给出最直接的线索。