RxJava：多订阅为何需用Observable.share()？默认行为疑问

这是个典型且值得深究的RxJava问题，我来帮你理清背后的设计逻辑和实际影响：

1. 为什么多订阅时需要用share()？ #

首先得明确RxJava中Observable的默认行为：默认的Observable是“冷”的。简单说就是每一个新的订阅者出现时，都会从头触发一遍上游Observable的整个执行流程。

拿你的代码举例，如果去掉share()：

Observable<String> nameChanges = nameDataSource.changes();
// 第一个订阅：触发nameDataSource.changes()的完整逻辑（比如初始化数据源监听链路）
autoUnsubscribe(nameChanges.subscribe(() -> { ... }));
// 第二个订阅：又会触发一遍nameDataSource.changes()的完整逻辑
autoUnsubscribe(nameChanges.map(...).filter(...).subscribe(...));

这意味着你的nameDataSource.changes()会被执行两次——可能是两次重复的数据源监听、两次数据库查询，甚至两次网络请求，不仅浪费资源，还可能导致两个订阅者拿到的数据不一致（比如两次查询之间数据源发生了变化）。

而share()的作用就是把这个冷Observable转换成多播的热Observable：它会维护一个上游订阅，当第一个订阅者出现时才触发上游逻辑，之后所有新订阅者都共享同一个数据流，不会重复触发上游。这样你的nameDataSource.changes()只会执行一次，所有订阅者都收到同一批数据。

2. 为什么share()不是默认行为？ #

核心原因有两个：性能优化和行为可预测性：

• 性能层面：单订阅者是RxJava最常见的场景（比如一个网络请求只需要一个订阅者处理结果）。如果默认开启多播（即默认share()），即使是单订阅场景，也需要维护订阅者列表、上游订阅状态等额外逻辑，带来不必要的性能开销。冷Observable的单订阅模式不需要这些额外开销，执行效率更高。
• 行为可预测性：冷Observable的行为是完全独立的——每个订阅者的数据流都是从头开始的，不会受到其他订阅者的影响。而热Observable（share()后的）是有状态的：如果一个订阅者晚于数据流开始才订阅，它会错过之前发射的数据；如果所有订阅者都取消订阅，上游也会被取消。把冷Observable作为默认，能让开发者在最基础的场景下获得清晰、可预测的行为，需要多播时再主动选择share()，符合“最小惊讶”的设计原则。

3. 不调用share()真的不能“正常运行”吗？ #

其实也能运行，但行为可能不符合你的预期。如果你的nameDataSource.changes()是一个无副作用的Observable（比如只是发射固定的测试数据），那多次订阅可能看不出问题；但如果它有副作用（比如操作数据库、发起网络请求、监听硬件变化），多次重复执行就会导致资源浪费、数据不一致等问题。

所以要不要用share()，核心看你的需求：

• 如果多个订阅者需要共享同一批数据流，避免重复执行上游逻辑 → 用share()
• 如果每个订阅者需要独立的数据流（比如每个订阅都要重新获取最新数据） → 不用share()

内容的提问来源于stack exchange，提问作者Martin Konicek