今天我们分享一个项目开发中的出现操作某个业务时候，出现闪退的经典问题，针对老旧的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、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 -> 查看登录请求的 |
收到正确的 |
未收到：服务器响应问题 |
|
2 |
浏览器存储Cookie |
F12 -> Application -> Cookies |
存储了正确的 |
未存储：浏览器安全策略阻止 |
|
3 |
后续请求携带Cookie |
F12 -> Network -> 查看查询请求的 |
携带了登录时的 |
未携带/值错误：浏览器端Cookie丢失 |
|
4 |
服务器处理请求 |
查看服务器日志/监听器日志 |
Session有效，请求正常处理 |
日志显示Session被销毁：服务器端主动废弃会话 |
|
5 |
服务器并发情况 |
分析线程堆栈快照 ( |
无长时间锁等待 |
有线程因等待Session锁而阻塞：会话锁超时问题 |
请按照这个流程进行操作，很大概率能直接定位到问题发生的具体环节。先从浏览器端跟踪开始，这通常能给出最直接的线索。