Spring Boot虚拟线程下基于连接池耗尽的负载均衡就绪信号实现

问题背景 #

在虚拟线程出现前，Tomcat的有界线程池可作为隐式背压机制。当实例过载时，/health接口会变慢甚至超时，促使负载均衡器停止向该实例路由流量。
而引入虚拟线程后，这一信号消失了：线程池实际上是无界的，因此即使实例因下游连接池（HTTP客户端、数据库池、缓存客户端）饱和、请求排队而过载，/health仍始终返回200。

需求目标 #

实现一个供负载均衡器轮询的/readyz端点：当实例连接池耗尽时返回503，将其从路由池中移除；待连接池恢复后返回200，重新加入路由。
Spring Boot的/actuator/health/readiness结合返回OUT_OF_SERVICE的自定义HealthIndicator似乎是合适的实现方式，但也考虑其他替代方案。

核心疑问 #

1. 使用HealthIndicator + OUT_OF_SERVICE是否为正确机制，还是有更合适的Spring Boot原生方案？
2. 如何在不额外发起网络调用的前提下可靠检测连接池耗尽？现有两种思路：(a) 直接读取池统计数据（空闲连接数、等待获取连接的请求数）；(b) 统计连接获取超时次数。哪种方案在不同连接池实现（HikariCP、Lettuce、Apache HTTP客户端）中更具可移植性？
3. 采用何种合理的滞回策略避免状态频繁波动？即需要连接池耗尽状态持续N秒才标记为未就绪，恢复状态持续M秒才标记为就绪？

技术栈 #

Spring Boot 3.x、JDK 21虚拟线程、ALB轮询/readyz端点

解答 #

1. Spring Boot原生方案选择 #

HealthIndicator + OUT_OF_SERVICE是完全符合Spring Boot生态的标准实现方式，也是官方推荐的就绪状态自定义扩展方案。

Spring Boot 3.x的Actuator就绪端点/actuator/health/readiness本身就是为负载均衡器提供实例就绪状态判断的标准化端点，当自定义HealthIndicator返回Status.OUT_OF_SERVICE时，端点会返回503状态码，正好匹配需求。

不存在更合适的原生替代方案：其他类似ApplicationListener监听上下文状态的方式，无法直接对接Actuator的标准化端点，需要自行实现状态暴露逻辑，反而增加复杂度。

2. 连接池耗尽检测方案的可移植性 #

直接读取池统计数据（方案a）的可移植性更强，原因如下：

• HikariCP：通过HikariPoolMXBean可获取getIdleConnections()（空闲连接数）、getPendingConnections()（等待连接的请求数）等统计指标；
• Lettuce：Redis客户端的ConnectionPool提供getNumIdle()、getNumActive()、getNumWaiters()等方法获取池状态；
• Apache HTTP Client：PoolingHttpClientConnectionManager支持getTotalStats()获取空闲、活跃、等待连接的统计数据。

方案b（统计连接获取超时次数）局限性明显：不同连接池的超时触发逻辑和暴露方式差异极大，比如HikariCP可通过setMetricRegistry()注册指标监听超时，但Lettuce的超时事件需要自定义RedisConnectionFailureListener，Apache HTTP Client则需要通过自定义ConnectionRequest包装类统计，实现成本高且兼容性差。

实现时可基于PooledObjectPool（Apache Commons Pool，Lettuce和Apache HTTP Client均基于此）和HikariCP的MXBean做适配，抽象出统一的连接池统计读取接口，降低不同实现的耦合。

3. 滞回策略的合理实现 #

采用固定时间窗口的状态持续检测，避免状态频繁切换：

• 耗尽判定（标记未就绪）：当连接池满足耗尽条件（比如空闲连接数为0且等待连接请求数超过池大小的80%）时，启动定时器，持续检测该状态是否保持N秒（推荐5-10秒），若持续满足则将实例标记为OUT_OF_SERVICE；
• 恢复判定（标记就绪）：当连接池恢复到健康状态（比如空闲连接数大于池大小的20%且等待请求数为0）时，同样启动定时器，持续检测M秒（推荐3-5秒），状态稳定后恢复为UP状态。

可借助Spring的ScheduledExecutorService实现定时检测，或使用Guava的状态计数器实现窗口统计。另外，Actuator的HealthIndicator本身支持缓存，可通过@Cacheable或自定义缓存逻辑控制检测频率，避免频繁读取连接池统计数据带来的性能开销。

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