Java REST服务响应延迟突增的原因及排查方法咨询

嘿，针对你遇到的Java REST服务流量阈值后的性能骤降问题，结合你给出的各项指标图表，我来梳理下可能的原因和排查方向：

从你提供的CPU使用率、JVM内存、打开文件数、响应时间等指标来看，几个核心线索指向这些问题：

• 系统文件描述符耗尽：从「打开文件数」图表能看到，流量超过阈值后数值直接暴涨。Linux系统每个进程默认的文件描述符上限不高（通常是1024），而每个HTTP连接、打开的文件/数据库连接都会占用一个描述符。一旦超过上限，新请求会被阻塞排队，直接导致响应时间飙升、活跃会话积压。
• 容器线程池打满：Java REST服务（比如Spring Boot内嵌的Tomcat、Jetty）依赖线程池处理请求。如果线程池的最大线程数和等待队列设置过小，流量突增后新请求会排队等待空闲线程，队列满了就会出现请求积压，对应你看到的HTTP会话数激增、响应时间跳升。
• 资源泄漏问题：低流量时不明显的资源泄漏（比如文件句柄没关、数据库连接未归还、HTTP客户端连接泄漏），在高流量下会快速累积，耗尽系统资源，直接触发打开文件数飙升、请求处理阻塞。
• GC长时间停顿：虽然JVM内存使用率图表看起来没有极端飙升，但如果内存池持续高位，可能触发Full GC，长时间的GC停顿会让服务暂时无法处理请求，也会导致响应时间变长，这个需要结合GC日志进一步确认。

按优先级来，你可以一步步验证：

1. 检查文件描述符限制
   • 先查当前进程的文件描述符上限：执行cat /proc/<进程ID>/limits（比ulimit -n更准确）
   • 再查进程实际打开的文件数：lsof -p <进程ID> | wc -l
   • 如果实际数接近或超过上限，就需要调整系统配置：编辑/etc/security/limits.conf，添加soft nofile 65535和hard nofile 65535，重启服务后生效。
2. 排查线程池状态
   • 如果是Spring Boot Tomcat，检查server.tomcat.max-threads、server.tomcat.accept-count配置（默认max-threads是200，accept-count是100），是否和你的流量规模不匹配。
   • 用jstack <进程ID>导出线程栈，查看是否有大量线程处于WAITING（等待队列）或BLOCKED状态，确认线程池是否已经耗尽。
3. 定位资源泄漏
   • 用lsof -p <进程ID>查看打开的文件/连接列表，看是否有大量重复的未关闭资源（比如大量数据库连接、日志文件）。
   • 用VisualVM或JProfiler等工具连接JVM，查看堆内存中的对象分布，看是否有大量未释放的连接对象（比如Connection、HttpClient实例）。
   • 检查代码逻辑：确认文件流、数据库连接是否在finally块中关闭，或者使用连接池时是否正确归还连接。
4. 分析GC日志
   • 开启GC日志：添加JVM参数-Xloggc:/var/log/app/gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCApplicationStoppedTime
   • 查看日志中是否有超过1秒的停顿事件，如果有，说明GC是瓶颈之一，需要调整JVM内存参数（比如增大堆内存、调整新生代比例）或排查内存泄漏。
5. 监控连接状态
   • 用netstat -anp | grep <进程ID>查看网络连接状态，看是否有大量TIME_WAIT或ESTABLISHED状态的连接没及时释放，这可能是连接复用配置不合理导致的。

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