Spring Integration应用负载增加时请求响应缓慢问题排查求助
2026-8-9
Spring Integration应用负载测试后整体响应缓慢排查方向
应用架构
- 技术栈：Java 8 + Spring Boot + Spring Integration
- 内部消息传输：使用
DirectChannels - 入站适配器：
- SOAP Web服务
- 消息队列（MQ）
- 外部依赖调用：
- 通过Rest API调用审计应用
- 通过Rest调用发送请求至X应用（配置HTTP连接池：
defaultMaxPerRoute=100，maxTotal=200）
问题描述
使用60用户进行约30分钟负载测试，初期消息处理速度极快，调用X应用前的内部处理耗时最长1秒；但运行一段时间后，应用整体响应异常缓慢，即使简单方法执行也耗时约2秒，请求在应用内总耗时达10-15秒，且该现象覆盖所有请求类型。
已添加多位置日志但未找到明确线索，日志中无内存溢出（OOM）或CPU满载情况；在各通道首尾添加的日志显示，通道间消息传递、简单转换器处理均耗时约2秒，无法定位根因。
相关慢请求日志
channel 1 2022-11-22 09:24:51 Transformer [INFO] converted the Source object to String xml for message 2022-11-22 09:24:54 AuditService [DEBUG] Completed first channel for : channel 2 2022-11-22 09:24:56 AuditService[DEBUG] Creating entry audit for operation 2022-11-22 09:24:59 AuditService [DEBUG] log just before pre rest channel call channel 3 2022-11-22 09:25:02 AuditService [DEBUG] starting rest pre channel 2022-11-22 09:25:05 RequestTransformer [DEBUG] About to process request 2022-11-22 09:25:05 RequestTransformer [DEBUG] The json after conversion channel 4 2022-11-22 09:25:07 AuditService [DEBUG] Completed request sent audit for operation 2022-11-22 09:25:08 AuditService[DEBUG] Completed request sent audit for operation
排查方向
1. DirectChannel线程池瓶颈排查
DirectChannel默认使用调用者线程处理消息，若所有请求都阻塞在外部调用（如审计应用、X应用），会导致线程耗尽，后续请求排队等待。
- 检查应用线程池配置：Spring Integration的
DirectChannel是否自定义了TaskExecutor？若未配置，默认使用调用线程，高负载下易出现线程阻塞排队。 - 查看线程状态：使用
jstack或可视化工具（如JConsole）查看线程状态，是否存在大量WAITING或TIMED_WAITING的线程，尤其是与外部HTTP调用、MQ相关的线程。
2. HTTP连接池资源耗尽或泄漏
虽然配置了defaultMaxPerRoute=100、maxTotal=200，但可能存在连接未正确释放的情况：
- 检查HTTP客户端配置：是否确保所有HTTP请求完成后（包括异常场景）都释放了连接？例如使用
CloseableHttpClient时是否正确关闭响应流或调用close()方法。 - 监控连接池状态：添加连接池指标监控（如活跃连接数、等待队列长度），负载测试时观察是否出现等待获取连接的请求堆积，导致线程阻塞。
3. 外部依赖调用延迟
日志中多个步骤间隔3秒左右，需确认外部服务（审计应用、X应用）是否在负载后期出现响应变慢：
- 单独对审计应用和X应用进行负载测试，验证其在长时间高负载下的响应稳定性。
- 在应用中添加外部调用的详细耗时日志，记录每个Rest请求的开始和结束时间，确认是否是外部服务拖慢了整个流程。
4. Spring Integration通道阻塞或消息堆积
- 检查各
DirectChannel的消息处理能力：若某个通道的处理逻辑（如转换器、服务激活器）存在隐性阻塞（如锁竞争、同步IO），会导致消息在通道中排队。 - 监控通道的消息队列长度：通过Spring Integration的监控指标（如
MessageChannelMetrics）查看是否有消息堆积，尤其是在负载后期。
5. JVM资源隐性瓶颈
虽然日志中无OOM和CPU满载，但可能存在其他资源瓶颈：
- 检查GC情况：使用
jstat或GC日志分析，是否存在频繁的Full GC或长时间的Young GC，导致应用停顿。 - 检查文件句柄、套接字资源：使用
lsof命令查看是否存在文件句柄泄漏，导致后续IO操作阻塞。
6. MQ相关阻塞
若MQ入站适配器的消息消费线程被阻塞，也会影响整个应用的处理能力：
- 检查MQ消费者的线程配置：是否有足够的线程处理MQ消息？是否存在消息消费超时或重试逻辑导致线程占用。
- 查看MQ服务器状态：是否在负载后期出现MQ消息堆积、响应变慢的情况。
内容的提问来源于stack exchange，提问作者Ashish Kathait
相关产品推荐
相关产品推荐
