Spring Boot微服务无法正常响应请求的排查方案咨询

1. 聚焦数据库连接池状态排查 #

• 执行jstack -l <进程ID>，定位DiscoveryClient-InstanceInfoReplicator线程的完整栈帧，确认它是卡在HikariDataSource.getConnection()调用，还是数据库驱动的底层连接逻辑上。
• 用jmap -histo <进程ID>查看HikariCP相关对象的实例数，对比配置的maximum-pool-size，判断连接池是否已耗尽。如果连接数达到上限，说明有线程占用连接未释放。

2. 分析DiscoveryClient线程阻塞的根源 #

• 该线程是Eureka用于周期性上报实例信息的线程，它请求数据库连接，说明服务可能配置了从数据库读取实例元数据，或是自定义InstanceInfo生成逻辑依赖数据库。
• 检查该线程的等待点：如果卡在驱动层，排查数据库端是否正常、网络是否连通、数据库连接数是否达上限；如果卡在HikariCP内部，检查是否有连接泄漏（比如业务线程获取连接后未关闭）。

3. 解析Tomcat工作线程全WAITING的原因 #

• Tomcat的http-nio-9026-exec线程全处于WAITING状态，说明所有工作线程都在等待某个共享资源释放。结合DiscoveryClient的情况，大概率是所有需要数据库连接的线程都阻塞在连接池获取环节，导致新请求无法被处理。
• 检查是否存在启动时的初始化任务（比如Bean初始化、数据预热）占用数据库连接未释放，或是某个长耗时业务线程持有连接陷入阻塞（比如数据库锁等待、慢查询）。

4. 验证数据库端状态 #

• 登录数据库服务器，执行对应命令排查会话状态：
  • MySQL：show processlist，查看是否有大量处于Locked或Sleep状态的会话
  • Oracle：select * from v$session where status='WAITING'，检查是否有锁等待或资源争用
• 确认数据库服务正常运行，没有出现宕机、网络分区，且数据库连接数未达配置上限。

5. 检查HikariCP配置合理性 #

• 核对以下核心配置：
  • spring.datasource.hikari.maximum-pool-size：是否设置过小，无法支撑并发请求
  • spring.datasource.hikari.connection-timeout：是否设置过长，导致线程长时间等待连接
  • spring.datasource.hikari.leak-detection-threshold：建议开启该配置（设置为大于0的毫秒值，比如2000），会在日志中输出连接泄漏的调用栈
• 若actuator后续恢复可用，可通过/actuator/hikaricp端点查看连接池实时状态。

6. 排查死锁与循环等待 #

• 重新执行jstack -l <进程ID>，检查输出开头是否有Found one Java-level deadlock的提示，若有则根据栈帧分析死锁双方的资源持有情况。
• 确认是否存在线程持有Tomcat工作线程的锁，同时等待数据库连接；而另一个线程持有数据库连接，等待Tomcat的资源，形成循环等待。

7. 临时恢复与验证 #

• 若允许重启服务，添加JVM参数-Dcom.sun.management.jmxremote开启JMX，使用JConsole/VisualVM实时监控线程状态、连接池连接数变化。
• 临时关闭Eureka实例上报（eureka.client.enabled=false）或调大HikariCP连接池大小，验证服务是否能恢复响应，定位是否为DiscoveryClient线程导致的连接池耗尽。

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