本文详解 RxJava 的 doFinally 操作符为何未按预期触发，并指出核心误区：操作符必须链式调用才能生效；直接对 Observable 多次调用 doFinally 会生成多个独立、未订阅的 Observable，导致副作用被丢弃。
本文详解 rxjava 的 `dofinally` 操作符为何未按预期触发，并指出核心误区：操作符必须链式调用才能生效；直接对 observable 多次调用 `dofinally` 会生成多个独立、未订阅的 observable，导致副作用被丢弃。
在 RxJava（尤其是 RxJava 3.x）中，doFinally 是一个关键的资源清理操作符，它保证在 Observable 正常完成（onComplete）、异常终止（onError）或被下游主动取消（dispose）时必定执行一次指定的清理动作。但许多开发者初次使用时发现：即使 onComplete 明确触发了，doFinally 中的代码却从未打印——这并非 Bug，而是对 RxJava 不可变链式操作模型的理解偏差所致。
? 根本原因：误用“构建”而非“链式订阅”
观察原始代码：
Observable<Integer> observable = Observable.create(emitter -> {
emitter.onNext(1);
emitter.onComplete();
});
observable.doFinally(() -> System.out.println("Test do finally before")); // ❌ 未订阅，被丢弃
observable.blockingSubscribe(...); // ✅ 真正执行的是这个原始 observable
observable.doFinally(() -> System.out.println("Test do finally after")); // ❌ 同样未订阅，被丢弃关键点在于：RxJava 所有操作符（如 doFinally, map, filter）均返回一个新 Observable 实例，原 Observable 不变。上述三行代码实际创建了三个互不关联的 Observable：
- 第一个带 doFinally("before")，但未被订阅；
- 第二个是原始 observable，被 blockingSubscribe 订阅；
- 第三个带 doFinally("after")，同样未被订阅。
因此，只有 blockingSubscribe 触发的那条链才真正执行，其余 doFinally 完全失效。
立即学习“Java免费学习笔记（深入）”；
✅ 正确写法：链式调用 + 单次订阅
要使 doFinally 生效，必须将其嵌入订阅链中，确保它属于最终被订阅的那个 Observable：
public static void main(String[] args) {
System.out.println("Start");
Observable<Integer> source = Observable.create(emitter -> {
System.out.println("Emitting...");
emitter.onNext(1);
emitter.onComplete();
});
// ✅ 正确：doFinally 作为链中一环，随订阅一起执行
source
.doFinally(() -> System.out.println("✅ doFinally executed — cleanup done"))
.blockingSubscribe(
System.out::println, // onNext
err -> System.err.println("Error: " + err), // onError
() -> System.out.println("✅ ON Complete") // onComplete
);
System.out.println("End");
}输出结果：
Start Emitting... 1 ✅ ON Complete ✅ doFinally executed — cleanup done End
⚠️ 注意：doFinally 在 blockingSubscribe 中总是在 onComplete 或 onError 之后立即执行（即“最终”阶段），但仍属于同步阻塞流程的一部分。因此其打印位置严格位于 onComplete 回调之后、blockingSubscribe 返回之前。
? 进阶提示：blockingSubscribe vs subscribe
若需 doFinally 在整个流处理完毕后（即 blockingSubscribe 返回后）执行，这是不可能也不符合设计意图的——因为 doFinally 的语义就是“流生命周期结束时”，而 blockingSubscribe 的阻塞行为本身已包含等待流终结。试图让它“延后到方法末尾”本质是混淆了流内清理与方法级逻辑。
✅ 推荐模式（清晰分离关注点）：
source
.doFinally(() -> closeResource()) // 流结束时释放连接/文件等
.subscribe(
value -> process(value),
error -> handleError(error),
() -> System.out.println("Stream done")
);
// 后续代码（如日志、状态更新）自然在 subscribe 返回后执行
System.out.println("All done — method continues");? 总结要点
- doFinally 不是“方法调用”，而是构建新 Observable 的声明式操作符，必须链入最终订阅的流中；
- 每次调用操作符都产生新实例，孤立调用等于“构建了但没用”；
- 它在 onComplete/onError/dispose 三者任一发生时保证执行且仅执行一次，是资源清理（如关闭 IO、释放锁）的理想选择；
- 切勿与 blockingSubscribe 的阻塞特性混为一谈——doFinally 的时机由流事件驱动，而非线程调度。
掌握这一模式，你就能可靠地在 RxJava 中实现确定性的资源管理，避免内存泄漏或状态不一致。
