Spring WebFlux线程模型疑问：subscribeOn为何未按预期工作？

初始理解的正确性 #

你的核心理解方向是对的：Spring WebFlux基于Reactor响应式模型，事件循环（NIO线程）负责接收请求、注册回调，后续异步任务完成后会通知事件循环，再由其触发回调返回结果。但细节上存在偏差——上游数据源的线程模型会直接影响后续操作的执行线程，这是你遇到问题的核心原因。

1. reactor-tcp-nio-1线程是什么，为何它执行所有处理任务？ #

• reactor-tcp-nio-1是Reactor Netty的NIO事件循环线程，主要负责处理TCP连接建立、请求接收、响应发送，同时也会处理异步非阻塞数据源（比如R2DBC数据库驱动）的回调推送。
• 如果你使用的是异步数据库驱动（如R2DBC），categoryRepository.findAll()的查询结果会直接由数据库驱动推送到Reactor Netty的NIO线程上，后续的map、filter等纯内存操作默认会复用这个线程执行，无需切换到其他工作线程。

2. 为何subscribeOn未将执行切换到其他工作线程？ #

• subscribeOn的作用是指定整个订阅链的「订阅发起线程」，也就是触发subscribe()动作的线程，但它不会改变上游发布者（这里是数据库查询）发布元素的线程。
• 你的日志中parallel-2线程就是subscribeOn(Schedulers.parallel())指定的订阅发起线程，它只负责启动订阅流程；而数据库查询的结果是异步推送到NIO线程的，所以后续的map、filter操作都跑在reactor-tcp-nio-1上。
• 要切换元素处理阶段的线程，需要使用publishOn，它会指定下游操作符的执行线程池。

3. 为何Reactor创建大量boundedElastic线程却都处于等待状态？ #

• Schedulers.boundedElastic()是专门为阻塞操作设计的线程池，它会根据需求动态创建线程（有上限），用于隔离阻塞任务避免阻塞NIO线程。
• 当你使用subscribeOn(Schedulers.boundedElastic())时，Reactor会创建线程来发起订阅动作，但订阅完成后这些线程就进入WAIT状态——因为你的操作都是非阻塞的（异步数据库查询+纯内存转换），根本不需要这些线程来执行任务，所有逻辑都在NIO线程上完成了。

代码修正示例 #

如果希望后续的map、filter等操作在指定工作线程上执行，应该在数据库查询之后使用publishOn切换线程：

@Override
public Flux<CategoryInfo> getAllCategories() {
    return categoryRepository.findAll()
            .publishOn(Schedulers.parallel()) // 切换后续操作到parallel线程池
            .map(it -> debug(it, "findAll"))
            .filter(filterUncategorized())
            .map(categoryMapper::toView);
}

关键总结 #

• Reactor Netty NIO线程：负责网络IO和异步数据源的回调推送，非阻塞的纯内存操作默认复用该线程
• subscribeOn：仅控制订阅发起的线程，不改变元素发布和处理的线程
• publishOn：用于切换下游操作的执行线程，适合将非阻塞任务转移到工作线程，或把阻塞任务转移到boundedElastic
• 异步非阻塞数据源的结果会直接推送到NIO线程，无需额外工作线程

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