Spring Cloud Gateway非标准Content-Type引发内存泄漏及连接池疑问

问题背景 #

我们在Spring Cloud Gateway中遇到仅某条路由出现的内存泄漏问题：该路由指向常规Spring Web Rest服务，其返回响应使用非标准Content-Type application/jwt，响应体为字符串格式的JWT-token。堆转储显示内存被reactor.netty.http.client.HttpClientConfig大量占用。设置以下配置后内存泄漏问题解决：

• spring.cloud.gateway.httpclient.pool.max-idle-time: "20s"
• spring.cloud.gateway.httpclient.pool.max-life-time: "30s"

针对该场景有两个疑问，以下是具体分析：

1. 非标准Content-Type为何引发内存泄漏？ #

核心原因在于Reactor Netty连接池的复用机制依赖响应体的正确收尾识别：

• Reactor Netty的HttpClient在复用连接前，必须确认当前请求的响应已完全读取并处理完毕，否则会将连接持续标记为"活跃"状态，不会放回连接池。
• 对于标准Content-Type（如application/json、text/plain等），框架内置的解码器能通过Content-Length头或分块编码（Transfer-Encoding: chunked）正确判断响应体的结束位置，完成后自动释放连接到池。
• 而application/jwt这类非标准Content-Type，会导致框架的默认响应解析逻辑无法正确归类处理：可能不会自动触发响应体的完全读取或缓冲区释放，使得连接一直被占用，无法被连接池回收。
• 未被回收的连接会被HttpClientConfig持有引用，随着请求量增加，内存占用持续上升，最终引发泄漏。设置max-idle-time和max-life-time后，连接池会强制回收超时的空闲/活跃连接，从而解决泄漏问题。

2. 连接池超时后请求响应时间仍未变长的原因？ #

这并非连接池未关闭连接，而是操作系统层面的TCP连接复用机制在起作用：

• 当应用层的连接池关闭连接后，操作系统会将该Socket连接置于TIME_WAIT状态（通常持续2倍MSL时间，默认约120秒），目的是确保所有残留的TCP报文被处理完毕。
• 若在TIME_WAIT周期内发起相同目标IP+端口的请求，操作系统会允许复用该状态下的连接（即TCP快速复用），无需重新执行三次握手流程，因此响应时间仍能保持在10-30ms的复用水平。
• 你通过指标看到的"无活跃/空闲连接"是应用层Reactor Netty连接池的状态，而底层操作系统的TIME_WAIT连接不在这个指标统计范围内，所以会出现看似矛盾的现象。

依赖版本：

• spring boot 2.7.5
• spring cloud gateway 3.1.4
• netty-all 4.1.84Final
• reactor-netty 1.0.24

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