Webflux 线程模型理解
内容提要
Webflux线程模型是使用Webflux/Reactor编程的重要概念。Reactive Streams规范定义了发布者和订阅者之间的交互逻辑，解决了异步流式处理中的背压问题。Reactor提供了subscribeOn和publishOn方法来控制request和onNext方法的执行线程。同时使用subscribeOn和publishOn时，subscribeOn的作用会穿过publishOn。
延伸解读
线程阻塞的连锁反应
文章开篇的案例显示，批量任务卡住页面访问，根源是r2dbc的IO线程被阻塞。在Webflux中，若某个操作符（如map）是CPU密集型，会在Netty worker线程上执行onNext，导致该线程无法处理其他请求，进而使依赖同一线程池的子模块相互干扰。这提醒开发者，即使批量任务本身DB操作不多，也可能因线程模型问题引发系统性卡顿。
Cold与Hot模式的数据流差异
Reactive Streams规范未规定onNext由谁调用，由此衍生出Cold和Hot两种模式。Cold模式下每个Subscriber拥有独立数据流，如Flux.range，订阅者从头消费；Hot模式下数据共享，如Flux.interval().share()，新订阅者获取当前值。理解这一区别有助于正确选择操作符，避免因数据流共享或独立而导致的预期外行为。
subscribeOn与publishOn的协作与穿透
subscribeOn影响request方法的执行线程，作用于向上调用链；publishOn影响onNext方法的执行线程，作用于向下调用链。当两者同时使用时，subscribeOn的作用会穿过publishOn，即位于publishOn上方的操作符仍受subscribeOn影响，而下方操作符受publishOn影响。这一特性要求开发者在组合线程调度时仔细安排操作符顺序，以精确控制各阶段的执行线程。
Q&A
Webflux线程模型的核心概念是什么？
Webflux线程模型是Webflux/Reactor编程的重要概念，主要涉及Reactive Streams规范下发布者和订阅者的交互逻辑。
Reactive Streams规范如何解决背压问题？
Reactive Streams规范规定Subscriber以PULL方式获取数据，从而有效解决异步流式处理中的背压问题。
Cold模式和Hot模式有什么区别？
Cold模式下每个Subscriber有独立的数据流，而Hot模式下数据是共享的，所有Subscriber共享同一数据流。
如何使用subscribeOn和publishOn控制线程？
subscribeOn影响request方法的执行线程，publishOn影响onNext方法的执行线程，二者可以结合使用，但subscribeOn的作用会穿过publishOn。
Subscription接口在Reactive Streams中有什么作用？
Subscription接口简化了Subscriber与Publisher之间的关系，使得Publisher可以有多个Subscriber而不增加复杂性。
在Webflux中，如何避免线程阻塞问题？
可以通过使用subscribeOn和publishOn方法来控制不同操作的执行线程，从而避免线程阻塞问题。
