本文详解如何在 Project Reactor 中避免阻塞调用（block），通过 flatMap 结合 Flux.merge 或 Mono.zip，实现“先串行获取数据、再并行执行依赖与独立任务”的典型响应式编排模式。
本文详解如何在 project reactor 中避免阻塞调用（block），通过 `flatmap` 结合 `flux.merge` 或 `mono.zip`，实现“先串行获取数据、再并行执行依赖与独立任务”的典型响应式编排模式。
在响应式编程中，盲目调用 block() 不仅违背非阻塞设计原则，还会导致线程阻塞、吞吐量下降，甚至引发死锁（尤其在有限线程池如 parallel() 调度器下）。针对如下常见场景：需先串行获取列表 A（Mono<List<String>>），再基于 A 的结果异步加载 B（loadB(a)，依赖 A），同时独立并行加载 C（loadC()，无依赖），正确的做法是构建声明式数据流，而非手动阻塞等待。
✅ 正确方案：使用 flatMap + 并行组合操作符
核心思路是：将串行依赖环节作为 flatMap 的上游输入，再在内部对下游任务进行并行编排。根据是否需要聚合结果，选择不同操作符：
场景一：仅关注执行完成（Void 类型，无需返回值）
当 loadB 和 loadC 均返回 Mono<Void>（例如保存、发送、清理类操作），推荐使用 Flux.merge 合并并行流，并用 then() 收敛为 Mono<Void>：
Mono<List<String>> resultAMono = listA();
Mono<Void> res = resultAMono
.flatMap(a -> Flux.merge(loadB(a), loadC()).then());✅ 优势：
- Flux.merge 对所有源 Mono 立即订阅（eager subscription），确保 B 和 C 真正并行启动；
- then() 忽略中间值，仅在两者均完成时发出 onComplete，语义清晰；
- 全链路无阻塞，完全响应式。
场景二：需要合并多个结果（非 Void 类型）
若 loadB(a) 返回 Mono<B>、loadC() 返回 Mono<C>，且业务需同时使用 B 和 C 的结果，则应使用 Mono.zip：
Mono<B> loadB(List<String> a) { /* ... */ }
Mono<C> loadC() { /* ... */ }
Mono<Tuple2<B, C>> res = resultAMono
.flatMap(a -> Mono.zip(loadB(a), loadC()));
// 或使用泛型友好的 zipWith（推荐）
Mono<Pair<B, C>> res2 = resultAMono
.flatMap(a -> loadB(a).zipWith(loadC()));✅ 说明：
- Mono.zip 同样并发触发两个 Mono，并在二者均成功发出数据后，以 Tuple2（或 Pair）形式组合结果；
- 若任一源发生错误，整个 zip 流将立即失败，符合响应式错误传播机制。
⚠️ 关键注意事项
- 切勿在 flatMap 外部调用 block()：resultAMono.block() 会强制同步等待，破坏整个链路的响应式特性，且在非 elastic 线程上极易引发线程饥饿；
- 区分 merge 与 concat：Flux.concat 是严格串行，不满足并行需求；merge 才是真正的并发执行；
- 错误处理需显式声明：建议在链路末尾添加 .onErrorResume() 或 .doOnError()，避免上游异常静默丢失；
- 调度器控制（进阶）：若 loadB/loadC 包含 CPU 密集型操作，可通过 .publishOn(Schedulers.parallel()) 显式指定线程池。
✅ 总结
响应式编程的核心在于描述数据流动逻辑，而非控制执行时机。面对“串行依赖 + 并行无关”混合流程，应始终优先选用 flatMap 承接上游结果，再通过 Flux.merge（侧重执行）或 Mono.zip（侧重结果）完成下游并行化。这不仅消除了阻塞风险，更提升了系统可伸缩性与资源利用率——这才是 Project Reactor 推崇的真正响应式实践。
