Mono.just() 在链构建阶段即同步执行参数计算，无法延迟或异步化阻塞逻辑；要实现真正非阻塞，应改用 Mono.fromCallable() 并配合真正的异步操作（如 delayElement），而非在 just() 中嵌入 sleep() 等阻塞调用。
reactor 中 `mono.just()` 在链构建阶段即同步执行参数计算，无法延迟或异步化阻塞逻辑；要实现真正非阻塞，应改用 `mono.fromcallable()` 并配合真正的异步操作（如 `delayelement`），而非在 `just()` 中嵌入 `sleep()` 等阻塞调用。
在响应式编程中，一个常见误区是认为只要将代码“包装进 Mono 或 Flux”，就能自动变为非阻塞。事实恰恰相反：Reactor 不会魔法般地将阻塞调用转为非阻塞。它仅提供调度、编排和背压能力，底层执行仍依赖实际操作的性质——若内部含 Thread.sleep()、JDBC 同步调用或文件 I/O，线程依然会被挂起。
? 问题核心：Mono.just() 的执行时机
Mono.just(value) 是立即求值（eager evaluation） 的操作符：它在创建 Publisher 的瞬间就执行 value 的计算（如调用 getString()），且该计算发生在当前线程（通常是主线程），而非订阅后指定的调度器线程。因此：
Mono.just(getString()) // ← getString() 在此处同步阻塞主线程！
.subscribeOn(Schedulers.parallel())
.subscribe(...);
即使后续指定了 subscribeOn(Schedulers.parallel())，也已无法“撤回” getString() 的阻塞——它早已在链组装时完成。这正是你第二个测试中循环逐次等待、输出顺序出现的根本原因。
✅ 正确做法：使用 Mono.fromCallable()
该操作符将计算逻辑延迟到订阅时执行，并可由调度器控制执行线程：
Mono.fromCallable(() -> getString()) // getString() 延迟到 subscribe 阶段，在 parallel 线程中执行
.subscribeOn(Schedulers.parallel())
.map(s -> {
System.out.println("Thread: " + Thread.currentThread().getName() + " → " + s);
return s.length();
})
.subscribe(System.out::println);
⚠️ 注意：这仍未消除阻塞！getString() 内的 sleep(2000) 依然会阻塞 parallel-1、parallel-2 等工作线程。在生产环境中，这将迅速耗尽线程池，导致吞吐量崩溃。
重要：对 React 或 Next.js 代码的任何更改必须先阅读本技能。Vercel 工程团队的 React 与 Next.js 指南，涵盖可视化...
✅ 真正非阻塞的替代方案
要模拟异步延迟（如 HTTP 请求、数据库查询），必须使用非阻塞原语，例如：
- Mono.delay(Duration)：基于时间轮（HashedWheelTimer）的轻量级定时，不占用线程；
- Mono.fromFuture() + CompletableFuture.supplyAsync()（需谨慎，仍可能用到线程池）；
- 优先采用真正的非阻塞驱动：如 R2DBC（数据库）、WebClient（HTTP）、Netty（网络）。
示例（推荐）：
public static Mono<string> getStringAsync() {
return Mono.delay(Duration.ofSeconds(2)) // 非阻塞延迟
.thenReturn("Hello world"); // 延迟后发出值
}
// 使用方式
for (int i = 0; i {
System.out.println(Instant.now() + " | Thread: " +
Thread.currentThread().getName() + " | " + s);
return s.length();
})
.subscribeOn(Schedulers.parallel())
.subscribe(len -> System.out.println("Length: " + len));
System.out.println(Instant.now() + " | Loop: " + i + " → after MONO");
}</string>
输出将显示所有 "after MONO" 几乎同时打印，随后约 2 秒后批量输出处理结果——证明整个流程真正非阻塞。
? 关键总结
| 操作符 | 执行时机 | 是否支持异步 | 适用场景 |
|---|---|---|---|
| Mono.just(value) | 创建时立即计算 value | ❌（阻塞在链构建阶段） | 已知、快速、无副作用的常量值 |
| Mono.fromCallable(() -> heavyWork()) | 订阅时在指定 Scheduler 执行 | ⚠️（可调度线程，但逻辑仍阻塞） | 必须使用阻塞 API 且需隔离线程时（如遗留系统集成） |
| Mono.delay().thenReturn() / Mono.fromFuture() | 异步触发，不阻塞线程 | ✅ | 模拟延迟、对接非阻塞生态 |
? 最佳实践：永远避免在 just()、fromSupplier() 等 eager 操作符中放入耗时或阻塞逻辑；对 I/O 密集型操作，坚持使用 Reactor 原生非阻塞 API（如 WebClient, R2DBC），而非试图“包装阻塞代码”。
