整体排查思路
我们的目标是验证以下三个环节是否正常：
登录成功时：服务器是否正确生成了Session并返回了包含正确 JSESSIONID的Cookie给浏览器。
浏览器端：浏览器是否成功接收并存储了该Cookie。
后续请求：浏览器在执行查询等操作时，是否始终在请求头中携带了这个Cookie。
第一步：浏览器端跟踪（客户端验证）
这是最直接、最容易操作的第一步，可以由开发或运维人员在问题电脑上进行。
一、跟踪会话标识（Cookie）的接收与存储
开启浏览器开发者工具：使用出现问题的浏览器（如奇安信、Chrome），按 F12打开开发者工具。
切换到Network/网络面板：勾选 Preserve log(保留日志)? 复选框，防止页面跳转时日志被清空。
清空Cookie（可选，为了纯净的测试）：在开发者工具的 Application（应用）或 Storage（存储）标签页下，找到 Cookies，选中当前系统地址的Cookie，将其删除。这可以模拟一次全新的登录。
执行登录：
在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中注册：
com.yourcompany.SessionDebugListener
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 ）。分析快照，看是否有线程长时间持有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锁而阻塞：会话锁超时问题
请按照这个流程进行操作，很大概率能直接定位到问题发生的具体环节。先从浏览器端跟踪开始，这通常能给出最直接的线索。依乌弦乖
