1
2
3
4

假设一个银行有10个柜台（线程池大小为10）：
- 每个客户（请求）需要占用柜台5分钟（包含等待IO的时间）
- 当同时有100个客户时，90个客户必须排队等待
- 即使柜员实际工作时间只有1分钟（CPU计算），其他4分钟都在等待（IO阻塞）

1
2
3
4
5
6
7
8
9

  ┌───────────┐       ┌───────────┐
请求队列 → │ 线程池    │ → 1:1 → │ 阻塞IO    │
  │ (200线程) │       │ (DB/HTTP) │
  └───────────┘       └───────────┘

关键问题：
- 假设CPU处理本身需要10ms，而下游响应延迟从10ms升至500ms时：
  吞吐量从 200/(0.01+0.01)=10,000 QPS 
  暴跌至 200/(0.5+0.01)=392 QPS

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

[工作流程]
1. 接受请求 → 分配线程
2. 线程执行 → 阻塞等待
3. 获取结果 → 返回响应
4. 释放线程

[资源时间线示例]
线程1：█░░░░░░░░░（80%时间在等待）
线程2：███░░░░░░░
线程3：░░░░░░░░░░

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

[工作流程]
1. 接受请求 → 注册回调
2. 立即释放线程 → 处理其他请求
3. 下游响应就绪 → 事件循环调度处理
4. 生成响应 → 无需等待

[资源时间线示例]
线程1：██████████（持续处理事件）
线程2：██████████
（仅需2-4个核心线程）

1
2
3
4
5
6
7

// 传统模型：同步等待结果（线程被阻塞）
String data = database.query(); // <- 线程在这里卡住！
response.send(data);

// WebFlux：订阅数据流（线程立即释放）
Mono<String> mono = database.reactiveQuery();
mono.subscribe(data -> response.send(data));

1
2
3
4
5
6
7

webClient.get()
    .uri("/api/users")
    .retrieve()
    .bodyToFlux(User.class)
    .filter(user -> user.age > 18)
    .take(10)
    .subscribe(System.out::println);

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

Mono<String> data = webClient.get()
    .uri("/api")
    .retrieve()
    .bodyToMono(String.class)
    .flatMap(response -> 
        Mono.deferContextual(ctx -> {
            String requestId = ctx.get("requestId"); // 从上下文中获取
            return processResponse(response, requestId);
        })
    )
    .contextWrite(Context.of("requestId", "12345")); // 写入上下文