Reactor 中的 finally 实现原理与关键设计
核心概念与信号类型
在响应式编程中，最终化逻辑并非来自传统的 try-catch-finally，而是由 doFinally 等运算符接管的资源清理与收尾行为。通过将清理逻辑绑定到信号生命周期，无论流自源是正常完成、出现错误还是被取消，最终都会触发指定的回调。此机制为高并发场景下的资源保障提供了统一入口。
Reactor 将终止过程抽象为几种信号类型，例如 CANCEL、ON_COMPLETE、ON_ERROR、ON_REQUEST，这些信号会在订阅生命周期的不同阶段传递给 doFinally 的回调，确保清理逻辑在任何退出路径执行。通过这种设计，开发者可以把资源释放、引用计数归零、计数器递减等处理放在一个集中点，而不需要在各个分支重复编写。
设计要点包括：1) doFinally 触发时机统一，2) 信号类型可区分不同退出路径，3) 回调中尽量保持无阻塞操作，以避免在事件循环中引发额外的阻塞。
Mono m = Mono.fromCallable(() -> fetchData()).doFinally(signalType -> {// finalization logicreleaseResources();System.out.println("Final signal: " + signalType);}).subscribe(System.out::println);
以上示例展示了一个典型的 doFinally 使用方式：在数据获取完成、出错或取消时，都会执行同一个清理入口。通过读取 signalType，你可以区分不同的终止场景，然后做相应的统计、日志记录或资源释放。
doFinally 与 finally 的实现机制对比
与传统 finally 的差异
在同步编程模型中，传统的 finally 块保证在 try 语句结束时执行。但在 Reactor 的异步流中，finally 不再来自语言层面的语法，而是通过 doFinally 等运算符提供的生命周期钩子来实现。与阻塞式链路中的 try-catch-finally 不同，doFinally 能覆盖 取消、完成、错误三种终止路径，并且在事件驱动的执行模型中具备更高的可控性。
从实现角度看，doFinally 内部基于信号订阅和生命周期状态机，它监听源流的终结信号并在回调中执行清理逻辑。这样可以避免在不同分支中重复清理逻辑，也避免了因提前抛出异常导致清理跳过的问题。
实战要点在于：若清理逻辑涉及资源释放、缓存清空或计数控制，务必在 doFinally 回调中完成，并尽量把阻塞性操作移出回调，避免对事件循环造成阻塞。
Mono.fromCallable(() -> blockingCall()).doFinally(signal -> {// finalize resources 清理阶段尽量避免阻塞metrics.increment("terminated");}).subscribe();
在高并发场景下的阻塞规避策略
阻塞源头识别
在高并发系统中，阻塞调用是性能瓶颈的常见来源。常见来源包括数据库阻塞操作、文件 IO、旧有的阻塞式 HTTP 客户端等。识别这些阻塞点，是实现无阻塞流的第一步。
一个有效的做法是：把阻塞操作从事件循环中移出，使用非阻塞 I/O 组件，或将阻塞调用调度到专门的线程池中执行，避免拖累 Reactor 的事件驱动网络栈。
同时，需要对资源限定、并发数、超时策略等进行细粒度控制，以避免后续的阻塞链条放大影响整体吞吐量。
技术要点与实现方案
非阻塞 I/O：优先使用 WebClient、R2DBC 等原生非阻塞组件来进行网络或数据库交互。对于需要阻塞的逻辑，使用 Schedulers.boundedElastic 将其切换到弹性线程池，避免回到事件循环上执行。
线程模型切换：通过 subscribeOn 和 publishOn 实现对执行阶段的分离，把阻塞任务放到后台线程，并将非阻塞计算留在事件循环中。
// 阻塞调用切换到弹性线程池
Mono> users = Mono.fromCallable(() -> userRepository.findAll()).subscribeOn(Schedulers.boundedElastic()).map(list -> transform(list));
此外，对于需要频繁发起外部请求的高并发场景，推荐使用非阻塞的 WebClient，并在必要时结合限流、并发控制策略来稳定系统。
WebClient wc = WebClient.create("https://api.example.com");
Mono res = wc.get().uri("/data").retrieve().bodyToMono(String.class).timeout(Duration.ofSeconds(5)); 实战演练：从原理到高并发实战
综合案例：数据库查询 + HTTP 调用 + 清理
在一个典型的微服务场景中，先从关系型数据库读取大量数据（可能阻塞），然后对每条数据发起非阻塞的外部 HTTP 调用，最后通过 doFinally 做统一的资源清理与指标统计。
核心思路是：将阻塞部分包装为 Mono.fromCallable 并通过 subscribeOn(Schedulers.boundedElastic()) 转移执行上下文，同时对 HTTP 调用使用完全非阻塞的 WebClient；再通过 flatMap 将数据流拼接，并在 finally 回调中完成清理。
WebClient wc = WebClient.create("https://api.example.com");
Mono> orders = Mono.fromCallable(() -> orderRepository.findAll()).subscribeOn(Schedulers.boundedElastic()).flatMap(list -> Flux.fromIterable(list)).flatMap(order -> wc.post().uri("/process").bodyValue(order).retrieve().bodyToMono(String.class)).collectList().doFinally(sig -> {// 统一清理与统计metrics.increment("pipeline_terminated");cleanupResources();});
常见误区与排错要点
常见误区
误区一：doFinally 可以处理耗时任务，直接在回调中执行复杂逻辑。事实上，doFinally 最好只执行轻量清理与日志工作，耗时操作应异步下放到线程池，避免阻塞事件循环。
误区二：把阻塞性 IO 放在 doFinally 里执行。这样会显著降低并发能力，应将阻塞逻辑放到单独的调度域或使用 non-blocking 替代方案。
误区三：忽略信号类型区分，导致资源重复释放或未释放。应通过 signalType 的判断来实现幂等清理和正确的资源管控。
Mono m = Mono.just("x").doFinally(signal -> {// 这里避免阻塞性 I/O// 如果确需清理，应该异步提交到专用线程池CompletableFuture.runAsync(() -> performBlockingCleanup(), Executors.newSingleThreadExecutor());});
排错要点与调试技巧
要点包括：监控 doFinally 的执行次数与信号类型是否覆盖所有终止路径；利用日志和指标确保清理逻辑在各种退出场景下都被触发；在性能分析中分离清理阶段和业务阶段，以定位阻塞点。
调试时可以开启结构化日志，配合事件流可视化工具来观察信号流的终止顺序，并通过对比测试用例验证 doFinally 是否在取消、完成和错误三种路径上都执行。
// 调试示例：验证三种终止路径都会执行 doFinally
Mono m1 = Mono.just("ok").doFinally(s -> log.info("path: {}", s));
Mono m2 = Mono.error(new RuntimeException("boom")).doFinally(s -> log.info("path: {}", s));
Mono m3 = Mono.never().doFinally(s -> log.info("path: {}", s));
