R2DBC-PostgreSQL线程池未充分利用问题咨询

这是预期行为吗？ #

不是。R2DBC PostgreSQL驱动的reactor-tcp-nio线程池是事件循环池，设计目标是根据负载分配到不同线程处理请求。出现所有操作绑定到单个线程的情况，通常有两个核心原因：

1. 连接池未被充分利用：如果请求处理速度快，连接还没释放就被复用，会导致后续请求绑定到同一个线程的连接上，不会触发线程切换。
2. 订阅上下文绑定单线程：如果请求的订阅操作是在单线程上下文（比如Tomcat IO线程、自定义单线程调度器）中触发，所有流会被关联到第一个可用的事件循环线程。

另外，断点挂起reactor-tcp-nio-1后其他线程未被使用，大概率是因为所有请求的订阅链都绑定在了这个线程的事件循环上，没有触发线程池的负载均衡逻辑。

如何让多个reactor-tcp-nio线程被利用？ #

1. 确保连接池真正被用起来 #

先排查连接池的实际使用情况：

• 启用R2DBC连接池指标（依赖io.r2dbc:r2dbc-pool），查看连接的获取、释放、空闲状态，确认是否真的用到了配置的10个连接。
• 调整连接池参数：缩短spring.r2dbc.pool.max-idle-time让空闲连接更快回收，避免单个连接被长期复用；确认spring.r2dbc.pool.max-size确实设置为10且生效。

2. 打破单线程订阅绑定 #

R2DBC的数据库操作默认会在连接对应的事件循环线程执行，但如果订阅上下文是单线程，会导致所有流绑定到同一线程。解决方式：

• 在Spring WebFlux场景下，Controller返回的响应式流会被框架自动调度，无需额外处理。如果是自定义订阅逻辑，避免在单线程上下文触发订阅。
• 若需要强制后续操作符切换到R2DBC事件循环池的其他线程，可以在Repository调用后添加publishOn(R2dbcSchedulers.fromConnectionFactory(connectionFactory))，让后续操作在R2DBC的线程池中均衡调度。

3. 不需要每次手动加publishOn/subscribeOn #

日常开发中不需要每次调用Repository后都手动添加调度器：

• 纯响应式的数据库操作和操作符，会自动在R2DBC的事件循环线程池中执行，框架会负责线程调度。
• 只有当业务逻辑包含阻塞操作时，才需要用publishOn(Schedulers.boundedElastic())将阻塞逻辑转移到专门的线程池，避免阻塞事件循环线程。

额外排查点 #

• 检查日志配置，确认线程名称的识别无误，避免把其他线程误标记为reactor-tcp-nio-1。
• 调整JMeter压测配置：确保用多线程发起请求（比如设置100个JMeter线程，每个线程每秒发10次请求），单JMeter线程发起的串行请求会被R2DBC调度到同一个事件循环线程，无法触发多线程负载。

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