管道性能问题排查求助：分类页访问后请求延迟飙升

这种场景我之前碰到过类似的，大概率是分类搜索页的操作给应用全局状态埋下了“坑”，导致后续请求被拖慢。给你一套逐步排查的实操思路：

1. 先锁定TTFB延迟的核心原因 #

首先要明确延迟到底出在服务器端还是客户端/网络：

• 用浏览器DevTools的Network面板，查看测试页请求的TTFB和Content Download时间——如果是TTFB占了近3秒，那肯定是服务器端处理慢；如果是下载时间长，可能是资源缓存问题，但你的情况更偏向服务器端。
• 用命令行工具精确验证：创建一个format.txt文件，内容如下：

  time_namelookup:  %{time_namelookup}\n
  time_connect:  %{time_connect}\n
  time_appconnect:  %{time_appconnect}\n
  time_pretransfer:  %{time_pretransfer}\n
  time_redirect:  %{time_redirect}\n
  time_starttransfer:  %{time_starttransfer}\n
  ----------\n
  time_total:  %{time_total}\n
  

  然后执行curl -w "@format.txt" -o /dev/null -s "https://你的测试页URL"，对比访问分类页前后的time_starttransfer（就是TTFB），确认延迟确实来自服务器端处理。

2. 排查全局资源的泄漏或占用 #

分类页涉及Solr查询，很可能消耗了全局共享资源且未正确释放：

• 数据库连接池检查：如果你的应用同时用到数据库和Solr，查看连接池的活跃连接数、空闲数。比如Spring Boot应用可以看actuator/metrics/hikaricp.connections.active指标，访问分类页前后对比——如果活跃连接数一直居高不下，说明有连接未释放，后续请求得等连接。
• 线程池状态检查：看应用的请求处理线程池（比如Tomcat的maxThreads）是否被占满。分类页如果有长时间运行的Solr查询（比如没加超时、拉取大量数据），会阻塞线程，导致后续请求排队。可以通过JVM工具（比如VisualVM）查看线程状态，看是否有大量WAITING或BLOCKED的线程。
• 缓存状态验证：测试页的“Test”内容是不是本来存在缓存里？访问分类页后缓存被清空了？给测试页加日志，记录是否命中缓存，对比访问分类页前后的日志——如果从“命中缓存”变成“未命中”，那就是分类页触发了缓存清除。

3. 追踪Solr操作的副作用 #

重点看分类页的Solr相关代码有没有留下“后遗症”：

• Solr客户端连接问题：如果用了单例的SolrClient，检查分类页的查询是否设置了超时。比如solrQuery.setTimeAllowed(5000)（5秒超时），如果没设置超时，Solr查询卡壳会导致客户端连接被挂起，后续请求复用这个连接时就会卡住。
• 资源清理检查：看分类页中Solr查询后的资源是否正确关闭，比如QueryResponse的输入流、结果集有没有释放。未关闭的资源可能导致内存泄漏或连接泄漏，拖慢后续请求。
• 全局锁检查：分类页有没有加全局锁（比如静态锁、分布式锁）但未正确释放？如果有，后续所有请求都会被阻塞在锁上，导致TTFB飙升。

4. 用Profiling工具抓现场 #

如果前面的检查没发现问题，直接用工具抓瓶颈：

• JVM线程栈分析：用AsyncProfiler或VisualVM，在访问分类页后立即请求测试页，捕捉此时的线程栈。看测试页的请求线程卡在哪个方法上——是在等待数据库连接？还是在Solr客户端的方法里？还是在某个同步代码块？
• 详细日志打点：在测试页的请求入口、关键步骤（比如缓存读取、模板渲染）加计时日志，比如：

  long start = System.currentTimeMillis();
  // 缓存读取逻辑
  log.info("测试页缓存读取耗时: {}ms", System.currentTimeMillis() - start);
  

  同时在分类页的所有关键操作（Solr查询、数据库操作、缓存更新）也加计时和资源状态日志，对比访问分类页前后测试页的日志差异，找到新增的耗时步骤。

5. 排查会话与线程上下文状态 #

有时候问题出在用户会话或线程局部变量：

• Session大小检查：分类页是不是往Session里存了大量数据？比如把Solr的查询结果全存到Session里，导致后续请求序列化/反序列化Session的时间变长。可以打印Session的大小，访问分类页前后对比。
• ThreadLocal清理检查：分类页有没有在ThreadLocal里存了大对象但未清理？后续请求复用线程时，ThreadLocal里的对象没释放，甚至引发内存泄漏，拖慢GC。确保在请求结束时清理ThreadLocal，或者检查ThreadLocal的使用是否规范（比如用弱引用）。

6. 验证隔离性缩小范围 #

做个小实验验证问题的影响范围：

• 重启应用后，先访问测试页（确认快），再访问分类页，再访问测试页（确认慢）；
• 然后用全新的无痕窗口/不同浏览器访问测试页——如果新窗口的测试页还是慢，说明是应用全局状态的问题；如果新窗口快，说明是用户会话/客户端状态的问题，缩小排查范围。

内容的提问来源于stack exchange，提问作者BVernon