Spring Boot构建的Restful API偶发响应耗时过长如何排查

业务逻辑结束到Servlet返回间的耗时定位手段 #

应用层排查 #

• 排查Filter、拦截器后置逻辑、返回增强组件耗时：Interceptor的postHandle执行早于视图渲染、返回值序列化、Filter后置逻辑，可分别在自定义Filter的doFilter调用前后、ResponseBodyAdvice的beforeBodyWrite方法前后增加时间戳日志，确认是否存在自定义加解密、审计日志上报、流量染色等同步后置操作耗时异常。
• 验证返回值序列化耗时：若接口返回对象存在大字段、循环引用、自定义序列化逻辑，可单独对返回结果执行序列化测试，或用Arthas的trace命令跟踪Jackson/HttpMessageConverter相关方法的执行耗时。
• 排查事务提交延迟：若事务注解标注在Controller层或外层切面，业务逻辑执行完成时事务尚未提交，可在事务切面/事务管理器的提交逻辑前后增加埋点，确认是否存在数据库事务提交阻塞（如数据库redo log刷盘延迟、网络抖动导致事务ACK超时）。

JVM层面排查 #

• 排查GC停顿：给应用启动参数增加GC日志配置-XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCApplicationStoppedTime -XX:+PrintSafepointStatistics，匹配超长响应发生的时间点，确认是否存在STW（Stop The World）停顿，包括Full GC、偏斜锁撤销、类重定义等Safepoint停顿场景。
• 排查锁竞争：出现超时现象时多次执行jstack <pid>抓取线程栈，查看处理当前请求的Worker线程是否处于BLOCKED状态，定位是否存在日志组件锁、公共业务锁竞争。也可通过Arthas的thread -b命令直接定位阻塞其他线程的锁持有线程。

Servlet容器层面排查 #

• 验证内嵌容器（默认Tomcat）的后置逻辑耗时：确认是否配置了自定义Valve、持久化Session管理器、同步刷盘的AccessLog，这类组件均会在业务逻辑执行完成后运行，可临时关闭相关配置验证耗时是否消失。
• 排查TCP发送阻塞：通过tcpdump抓包对应请求的TCP交互流程，确认是否存在socket缓冲区满、滑动窗口为0导致的发送阻塞（多发生在返回体较大、客户端接收速率慢的场景）。

系统层面排查 #

• 跟踪进程系统调用：执行strace -tt -T -p <应用进程ID>，在出现超长响应时查看进程卡在哪类系统调用上：若卡在futex调用可确认是用户态锁竞争，若卡在fsync/write调用可确认是磁盘IO阻塞，若卡在网络相关系统调用可确认是后置外部请求（如监控上报、日志同步推送）超时。
• 确认跨应用资源竞争：同服务器运行3个Spring Boot应用，可通过lsof、ss命令确认是否存在端口、文件句柄、内核连接跟踪表等资源抢占的情况。

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