Multithreading rxjava2是否过度保护了线程安全？

我已经使用RxJava2很长时间了。 最近，我正在从RxJava2的源代码研究它，试图理解它，编写自己的操作符实现。 我发现有很多关于线程安全的代码。但我认为有些是多余的，这增加了学习的难度

根据2.7“订户必须确保其订阅上的所有呼叫都来自同一线程或提供相应的外部同步。”。 确保调用线程安全不是调用方的职责吗

---

但是我发现“io.reactivex.internal.operators.flowable.FlowableLimit$LimitSubscriber.request”这个方法使用AtomicLong来实现原子性。许多其他代码都是这样做的。为什么？

您正在使用的API“RXJava2”中的订阅项目本身不是线程安全的，但如果您正在使用RXJava2，则必须使其成为线程安全的。或者只用一根线

"A Subscriber MUST ensure that all calls on its Subscription are thread Safe"

这基本上是一个警告，多线程可能会出现奇怪的情况，当多线程遇到使用“Subscribtion”类编写的代码时，您应该真正考虑后果

但我无法回答这个问题，因为可能有人开始更改代码，并试图使其更加线程安全（一点一点）代码不断演变和更改，并且在文档中警告尚未实现线程安全的部分

希望这能有所帮助

但我认为有些是多余的，这增加了学习的难度

<> P>当执行操作符时，必须考虑来自不同来源/消费者的各种信号类型的许多可能的并发交互。我花了很多时间研究和优化RXJava2。并发性很难实现，我很确定实际上没有“多余的”实现细节。有些算法看起来像这样总是有原因的。然而，可能存在一些优化的可能性，但必须仔细分析和思考这些可能性

根据反应流规范2.7

还有一些关于规则措辞的讨论和改进，给出了RxJava和ProjectReactor等实际实现的结果

确保调用线程安全不是调用方的职责吗

调用

Subscriber.onXXX

方法时，特定操作员的

Publisher

通常处于确保线程安全的最佳位置。否则，

订户

将需要更多地了解其源代码是什么或做什么

但我发现“io.reactivex.internal.operators.flowable.FlowableLimit$LimitSubscriber.request”

有许多方法可以确保线程安全。措辞“synchronization”并不一定意味着必须使用Java关键字

synchronized

。RxJava主要使用所谓的无锁算法，这些算法利用

java.util.concurrent.atomic

类提供的原子操作。请求管理通常是无锁原子的“客户端”