PDE (Processing D Editor) 三维场景编辑器 · 软件白皮书 · 基于 v..

整体排查思路

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

登录成功时:服务器是否正确生成了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=/; Only。

记录下这个 JSESSIONID的值。

验证Cookie存储:

切换到 Application/应用标签页。

在左侧找到 Cookies-> ://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监听器:

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

import javax.servlet..SessionEvent;

import javax.servlet..SessionAttributeListener;

import javax.servlet..SessionBindingEvent;

import java.util.logging.Logger; // 或使用Log4j、Slf4j

public class SessionDebugListener implements SessionListener, SessionAttributeListener {

private static final Logger logger = Logger.getLogger(SessionDebugListener.class.getName());

@Override

public void sessionCreated(SessionEvent se) {

logger.info("!!! Session被创建: ID=" + se.getSession().getId() + ", 时间=" + new java.util.Date());

}

@Override

public void sessionDestroyed(SessionEvent 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(SessionBindingEvent event) {

if ("user".equals(event.getName())) { // 监听用户登录属性

logger.info("!!! 用户登录成功,User对象被存入Session。 SessionID=" + event.getSession().getId() + ", User=" + event.getValue());

}

}

@Override

public void attributeRemoved(SessionBindingEvent event) {

if ("user".equals(event.getName())) { // 监听用户登出属性

logger.info("!!! 用户登出,User对象从Session移除。 SessionID=" + event.getSession().getId());

}

}

}

在 web.xml中注册:

.yourpany.SessionDebugListener

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

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

public class SessionTrackingFilter implements Filter {

@Override

public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {

ServletRequest req = (ServletRequest) request;

ServletResponse res = (ServletResponse) 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锁而阻塞:会话锁超时问题

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

相关推荐
EsK9QtghY2 小时前
一款基于 .NET 开源、跨平台应用程序自动升级组件
分享
aF058JN5H3 小时前
Serilog 日志库简单实践(五)数据库 Sinks(.net)
分享
oAA4RW56t3 小时前
.NET 打造 OpenClaw Windows Node
分享
dtICUA6su3 小时前
一款基于 .NET 开源、跨平台应用程序自动升级组件
分享
风趣的小刺猬3 小时前
.NET 新特性概览与相关文章索引
分享
Nx14g3Hu43 小时前
一款基于 .NET 开源、跨平台应用程序自动升级组件
分享
nd1o6XEn33 小时前
MiniMax M. 发布!Redis 故障排查 + 跨语言重构场景实测,表现如何?
分享
Qbpad9TeD3 小时前
AutoGod:一款拥有AI视觉的安卓自动化框架
分享
qp83X6D473 小时前
再次革新 .NET 的构建和发布方式(一)
分享