Spring Boot Web 中RestController接口存在异常延迟问题求助

我在使用基于Tomcat的Spring Boot Web Rest接口时遇到了奇怪的延迟问题。我们的RestController有多个接口方法，最近注意到异常的延迟情况。比如我特意写了一个返回true的简单接口（为了隔离问题，没有业务逻辑），但调用这个接口的平均响应时间竟然有60-70ms。我通过Spring的sum(rate(http_server_requests_seconds_sum{kubernetes_pod_name=~"$pod.*", release="指标观测到了这个情况。

你好，碰到这种无业务逻辑的简单接口都有几十毫秒延迟的情况，确实挺让人困惑的，我来分享几个实际排查过类似问题的方向，帮你定位根源：

• 先排查K8s与基础资源层面

  • 首先确认Pod的资源配额是否足够：比如CPU是否被K8s限流（出现Throttled状态）、内存是否不足导致频繁GC？你可以查看Pod的监控指标（CPU使用率、内存使用率、GC次数与停顿时间），如果资源吃紧，哪怕是最简单的接口也会因为资源调度问题产生延迟。
  • 检查Tomcat线程池的运行状态：默认的Tomcat线程池参数可能无法匹配你的请求量，比如server.tomcat.max-threads设置过小，导致请求进入队列等待。可以通过Spring Boot Actuator的/actuator/metrics/tomcat.threads接口查看线程池的活跃数、队列长度等指标，判断是否有线程阻塞的情况。

• 梳理Spring Boot的拦截器与过滤器链

  • 哪怕是简单接口，请求也会经过Spring的整个拦截器/过滤器链，比如日志拦截器、Spring Security的权限校验过滤器、Metrics收集拦截器等。你可以尝试临时禁用一些非核心的拦截器/过滤器（比如暂时关闭Spring Security、注释掉自定义的日志切面），看看延迟是否明显降低，以此定位到耗时的环节。
  • 留意Metrics收集本身的开销：你用到的http_server_requests_seconds_sum指标，有些Metrics的收集逻辑如果比较重（比如频繁的标签计算、远程上报），也会拖慢接口响应。可以尝试临时关闭Metrics的自动配置，对比接口响应时间的变化。

• 排查网络与调用链路的损耗

  • 先做本地调用验证：直接在Pod内部用curl调用这个简单接口，看看本地响应时间是否正常。如果本地调用很快，那问题大概率出在K8s的Ingress、Service转发环节，或者集群网络本身有延迟。
  • 检查DNS解析是否有问题：如果Spring Boot内部有依赖DNS解析的逻辑（比如某些组件的初始化、配置中心的连接），DNS解析慢会导致周期性的接口延迟。可以在Pod内部测试DNS解析耗时，比如time nslookup xxx。

• JVM层面的深度排查

  • 开启GC日志监控：添加JVM参数-Xlog:gc*:file=gc.log，查看是否有频繁的Minor GC或者长停顿的Major GC，GC停顿会直接导致接口响应延迟。
  • 用工具追踪调用链路：可以用Arthas的trace命令精准定位接口调用的每个步骤耗时，比如：

    trace com.yourpackage.YourRestController yourSimpleMethod
    

    这个命令会输出方法调用的每个子步骤耗时，能快速找到哪个环节拖慢了响应。

如果这些方向都没找到问题，还可以检查是否有JVM的性能瓶颈（比如锁竞争、线程阻塞），用jstack导出线程栈分析，或者用性能 profiling 工具做进一步排查。

备注：内容来源于stack exchange，提问作者Mikhail Grinfeld