R2DBC连接池为何分配20个连接而非预期的11个？

环境与配置 #

基于Reactive Java Spring Boot开发应用，使用R2DBC连接MySQL，连接池配置如下：

spring.r2dbc.pool.enabled=true
spring.r2dbc.pool.initial-size=0
spring.r2dbc.pool.max-size=20
spring.r2dbc.pool.max-acquire-time=30s
spring.r2dbc.pool.max-idle-time=1m

应用工作流 #

A. 数据生成（单线程） #

• 从SQS消费消息并生成待处理数据
• processMessage方法为响应式实现，通过响应式流生成数据
• 因会话确认模式配置为CLIENT_ACKNOWLEDGE，此处使用.block()阻塞调用：

myConsumerService.processMessage(message).block();

B. 数据处理（10个并发线程） #

• 10个线程并发执行数据处理操作
• 单个线程依次执行3次MySQL查询操作，每次操作仅耗时数毫秒
• MySQL查询代码实现：

public class MyRepository {

    private final R2dbcEntityTemplate template;

    public MyRepository(R2dbcEntityTemplate template) {
        this.template = template;
    }

    public Mono<MyEntity> getEntityById(Long id) {
        return template.select(MyEntity.class)
            .matching(Query.query(Criteria.where("id").is(id))).one();
    }
}

问题现象 #

• 配置最大连接数为20，但连接池实际分配连接数达到20，远超预期的11个（1个数据生成线程+10个数据处理线程）
• 日志显示连接在MySQL操作前分配、操作后立即释放，符合预期逻辑
• 调试日志输出：

ConnectionPoolStats : Allocated : 20, Acquired : 1, Idle : 0, Pending : 9

• 实际影响：连接池占满20个连接后，新请求等待获取连接超时，抛出异常：

Caused by: io.r2dbc.spi.R2dbcTimeoutException: Connection acquisition timed out after 30000ms

• 连接池指标获取代码：

PoolMetrics metrics = connectionPool.getMetrics().orElse(null);

if (metrics != null) {
    String connectionPoolStats = String.format("Allocated : %d, Acquired : %d, Idle : %d, Pending : %d",
            metrics.allocatedSize(), metrics.acquiredSize(),
            metrics.idleSize(), metrics.pendingAcquireSize());
    logger.info("ConnectionPoolStats : {}",  connectionPoolStats);
} else {
    System.out.println("Connection Pool Metrics are not available.");
}

疑问 #

为什么R2DBC连接池会分配20个连接，而非预期的11个？

解答 #

出现该问题的核心原因是响应式代码与阻塞操作的混合使用破坏了R2DBC连接池的线程模型，同时数据处理阶段的并发逻辑存在隐性的连接申请问题：

1. .block()触发的线程池膨胀 #

数据生成线程中使用的.block()会打破响应式线程模型：调用.block()时，Reactor会在当前线程或从blockingScheduler线程池取出线程等待响应式流完成，这会导致原本的单线程逻辑实际触发多个线程并发执行，进而申请更多连接。此外，SQS默认的传统线程池结合.block()，会进一步加剧线程膨胀，导致连接申请量远超预期。

2. 数据处理阶段的连接申请逻辑 #

你提到每个线程依次执行3次MySQL操作，但如果实际代码中是并行触发查询（比如用Mono.zip()同时发起多个查询），单个线程会同时申请3个连接，10个线程就会一次性发起30个连接请求，快速占满max-size=20的连接池，后续请求进入等待队列最终超时。即使是串行执行，线程切换或Reactor调度器切换也可能导致连接未及时回收就发起新申请，短时间内出现连接数峰值。

3. R2DBC连接池指标的定义误区 #

R2DBC连接池的allocatedSize()统计的是累计分配过的连接总数，而非当前活跃连接数。连接被快速创建又释放后，allocatedSize()会累计到max-size，但这些连接可能处于空闲等待回收的状态（你的日志中Idle:0说明此时空闲连接已被回收，但allocatedSize不会减少）。真正需要关注的是acquiredSize()（当前被占用的连接数）和pendingAcquireSize()（等待连接的请求数）。

解决建议 #

1. 移除.block()，改用响应式SQS消费：使用Spring Cloud AWS的响应式SQS客户端，保持全流程响应式，让Reactor统一管理线程模型，避免线程膨胀。
2. 确保MySQL操作严格串行执行：如果每个线程需要依次执行3次查询，用.flatMap()串行调用，而非并行触发，示例：

   getEntityById(id1)
       .flatMap(entity1 -> getEntityById(id2))
       .flatMap(entity2 -> getEntityById(id3))
   

3. 调整连接池参数：将max-size下调到合理值（比如15），缩短max-idle-time让空闲连接更快回收，同时调整max-acquire-time适配实际业务场景。
4. 聚焦核心监控指标：重点关注acquiredSize()和pendingAcquireSize()，allocatedSize()仅作为历史分配参考，不代表当前连接占用情况。

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