6.4 常见陷阱与规避

6.4 常见陷阱与规避

本节摘要：SOURCE 第六章与第一章挑战均指向同一类问题——响应式外壳 + 命令式内核。.block()、无界 push、忽略背压、在 EventLoop 阻塞，比不用响应式更糟。

读前必看

1. 列出四条必须禁止的代码 smell
2. 说明团队能力错配时的渐进迁移策略
3. 判断 CRUD 后台是否值得 WebFlux

一、反模式清单

SOURCE：精通 Spring MVC 的工程师常需 3–6 个月 才写出符合响应式精神的代码——赶工期的「Mono 包装同步」引入更隐蔽死锁。

反模式详解

阻塞伪装是最普遍的反模式：链中间某处调用 .block() 拿结果，导致整个 EventLoop 线程被挂起等待。更隐蔽的是隐性阻塞——在 flatMap 里调用 Thread.sleep、System.currentTimeMillis 循环、阻塞 SDK（Jedis、JDBC、Apache HttpClient），调用点没有 .block() 字样，但行为一模一样。

// 反模式：阻塞伪装
public Mono<String> get() {
    String db = jdbc.query("...").block();   // ← EventLoop 在此挂起
    return Mono.just(db);
}

// 反模式：伪异步（没有切换线程）
Mono<String> bad = Mono.fromCallable(() -> jdbc.query("..."));
// ← 若没有 subscribeOn(boundedElastic)，查询仍在 EventLoop 执行
​

伪异步的本质是「包装了却不在对的地方执行」：Mono.fromCallable(() -> jdbc.query()) 看起来异步，但如果后续没有 .subscribeOn(Schedulers.boundedElastic())，阻塞代码依然跑在 EventLoop 上。判断标准：阻塞代码有没有离开 EventLoop 线程？ 没有，就是伪异步。

背压盲区：手写 Flux.create(emitter -> { while(...) emitter.next(x); }) 时忽略 emitter 的 requested 状态，无限发射。Reactor 的 Flux.create 支持背压（emitter 有 requested 计数），但需要生产者配合——不检查 requested，背压就只是摆设。

错误黑洞：flux.subscribe() 不传错误消费者，异常进入全局 Hooks.onErrorDropped 或被静默吞掉，运维根本看不到。所有 subscribe() 必须至少带一个 error 消费者，或使用 log() 观察。

二、何时不必响应式

响应式适合：I/O 密集、高并发、流式推送、端到端延迟敏感（Netflix 事件、Uber 50ms 调度）。

响应式不是「更高端的默认选项」，它有自己的适用边界。判断标准有三个：

1. 有真正的高并发 I/O 吗？ 100 QPS 的 CRUD 用 WebFlux 收益接近零，复杂度却显著上升；
2. 有流式语义吗？ SSE 推送、事件流、Kafka 消费这类「天然是流」的场景响应式如鱼得水；纯请求-响应的页面 API 则未必；
3. 团队能维护吗？ 3-6 个月学习曲线意味着前几个月产出质量和排障速度都在下降——如果团队只有两周工期，传统模型更稳。

三、迁移路径

1. 新接口 WebFlux + 旧接口 MVC 并存
2. 先换 Netty + 非阻塞 Client，DB 仍阻塞时用 boundedElastic 隔离
3. R2DBC 逐表迁移，保留 JDBC 回退
4. 建立 StepVerifier 与背压集成测试门禁

渐进迁移的每一步

迁移的关键纪律：每一步都必须可回退、可灰度、可测试。响应式迁移最大的坑不是技术，而是一次性「大爆炸」——把所有接口一次性改造成响应式，出问题时无法定位是哪一段引入的。按「读路径 → 非阻塞客户端 → 数据层」的次序推进，每步都有明确的验证标准，才是可持续的迁移方式。

反模式自查清单

// 逐条自查：你的代码命中了几条？
// [ ] 链内出现 .block() / .blockFirst() / .blockLast()
// [ ] flatMap 内直接调用阻塞 SDK（JDBC/Jedis/RestTemplate）
// [ ] Mono.fromCallable 后没有 subscribeOn(boundedElastic)
// [ ] Flux.create 中不看 emitter.requested() 就无限发射
// [ ] subscribe() 不传 error 消费者
// [ ] 在 EventLoop 里做 CPU 密集计算（没有 publishOn）
​

命中 2 条以上，代码大概率是「响应式外壳 + 命令式内核」——建议先重构 I/O 边界，再谈优化。

陷阱案例逐步剖析

// 典型案例：看似响应式，实则阻塞
public Mono<List<User>> findUsers() {
    // 问题1：JDBC 查询是阻塞的
    List<User> users = jdbc.query("SELECT * FROM users", ROW_MAPPER);
    // 问题2：包装成 Mono 但没有切换线程，仍在 EventLoop 执行
    return Mono.just(users);
}
​

这段代码有两个叠加的错误：JDBC 查询本身阻塞调用方线程；Mono.just(users) 包装已完成的值，没有非阻塞语义。如果它在 WebFlux 控制器里被调用，EventLoop 会在查询期间被挂起——高并发下所有请求排在这个查询后面，等价于把响应式降级成阻塞模型。

// 正确改法（分两档）
// 档一：暂时无法换 R2DBC → 明确隔离阻塞
return Mono.fromCallable(() -> jdbc.query("SELECT * FROM users", ROW_MAPPER))
    .subscribeOn(Schedulers.boundedElastic());

// 档二：彻底响应式 → 用 R2DBC
return r2dbcTemplate.select("SELECT * FROM users", ROW_MAPPER).all();
​

档一承认阻塞现实但隔离它——fromCallable + subscribeOn(boundedElastic) 让查询在独立的有界线程池执行，EventLoop 不再被挂起；档二才是真正的响应式。工程上允许「隔离的阻塞」，禁止「隐性的阻塞」——后者是排障最困难的反模式。

背压盲区的检测手段

背压盲区（create 无界发射）通常要到内存告警才暴露。主动检测手段：

// 手段一：订阅时观察 request 压力
Flux.create(emitter -> {
        // 每次发射前检查 requested
        if (emitter.requestedFromDownstream() == 0) {
            // 下游没有请求，等待而非继续发射
            return;
        }
        emitter.next(nextItem());
    })
    .onBackpressureBuffer(1024);

// 手段二：用指标观察在途量
Flux.range(1, 1_000_000)
    .name("ingest")
    .metrics()                    // 观察 on_next_delay 突增
    .subscribe(consumer);
​

结合 6.2 的指标手段，背压盲区不再是「等 OOM 才知道」——on_next_delay 突增、内存曲线上升时，即可定位到无界发射点。

要点串联

• 没有非阻塞 I/O 就不要追求 Mono 全覆盖
• 背压与 cancel 是一等测试用例
• 选型是架构决策，不是框架时尚

一句话总结：响应式反模式的共同根源是「把响应式当语法糖用」——.block()、伪异步、背压盲区、错误黑洞都在破坏契约；正确的做法是承认适用边界、渐进迁移、逐条自查，让每一跳都真正兑现非阻塞与背压。

回到导读：用 Publisher/Subscriber/request(n) 重画你的系统数据流。