Reactive Java中Flux流元素推送与订阅触发机制疑问

你对Project Reactor（Spring WebFlux默认使用的响应式流实现）的默认执行模型存在认知偏差：响应式流不存在「必须攒齐所有元素、等onComplete信号触发才向下游传递处理」的默认规则，你观察到的逐元素生成、立刻触发订阅处理的现象，是同步冷流场景下的标准行为。

1. Flux.fromIterable的核心实现特性 #

你代码中使用的Flux.fromIterable()生成的是同步冷流，核心行为逻辑如下：

• 冷流属性：只有当你主动调用subscribe()订阅的时候，流才会真正开始执行，仅创建Flux实例不会触发任何数据处理逻辑
• 同步执行：整个流的元素遍历、下发、处理逻辑全部在发起订阅的线程（也就是你日志里的main线程）上串行执行，没有线程切换、异步排队的额外开销
• 无额外全量缓存：你的数据源List.of("James","Harry","Spike")本身在创建Flux的时候就已经存在于JVM内存中，Flux不会额外拷贝、缓存全量元素等待下发，也不存在「预先收集所有元素」的步骤。

2. 订阅触发后的真实执行时序 #

你日志第一行的request(unbounded)是整个流程的起点：
当调用subscribe()注册下游消费者时，响应式流的背压机制首先生效，下游会向上游发送一个无界需求信号，意思是「我可以接收任意数量的元素，你准备好就可以发」。上游fromIterable收到无界需求后，会直接遍历List的迭代器：每遍历到一个元素，就立刻调用下游的onNext()方法下发当前元素，等当前元素对应的下游处理逻辑（也就是你写的打印语句）完全执行完毕，才会继续遍历下一个元素。

你看到的输出顺序完全对应这个逐元素串行执行的流程：

# 收到下游的无界拉取请求
2022-06-18 23:59:59.319  INFO 35446 --- [           main] reactor.Flux.Iterable.1                  : | request(unbounded)
# 遍历到第一个元素James，log先打印onNext信号，再执行自定义订阅逻辑打印
2022-06-18 23:59:59.320  INFO 35446 --- [           main] reactor.Flux.Iterable.1                  : | onNext(James)
Subscriber called James
# 第一个元素处理完成，遍历到第二个元素Harry，重复上述流程
2022-06-18 23:59:59.327  INFO 35446 --- [           main] reactor.Flux.Iterable.1                  : | onNext(Harry)
Subscriber called Harry
# 第二个元素处理完成，遍历到第三个元素Spike，重复上述流程
2022-06-18 23:59:59.327  INFO 35446 --- [           main] reactor.Flux.Iterable.1                  : | onNext(Spike)
Subscriber called Spike
# 迭代器遍历完成，上游发送onComplete信号，整个流终止
2022-06-18 23:59:59.327  INFO 35446 --- [           main] reactor.Flux.Iterable.1                  : | onComplete()

3. 认知偏差的来源 #

「攒齐所有元素再处理」不是响应式流的通用规则，只是特定聚合类操作符的专属逻辑：

• 只有当你显式使用collectList()、buffer()、reduce()这类本身需要聚合全量数据才能产出结果的操作符时，操作符内部才会开辟内存空间缓存上游传来的所有元素，直到收到onComplete信号，再把聚合后的结果一次性下发给下游。
• 你代码里加的.log()只是个信号观察操作符，不会改变流的任何执行逻辑，只是把流运行过程中所有的交互信号（request、onNext、onComplete等）打印出来而已，就算去掉.log()，流依然是逐元素下发处理的，只是你看不到内部的信号日志。

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