Android LiveData/多线程代码是否存在并发问题或非预期结果？

原有版本代码的潜在问题 #

• 非原子自增导致计数错误
  三个后台线程并发对基础类型int的loaded变量执行自增操作，int自增不是原子操作，存在并发竞争风险：可能出现两个线程同时读取到相同的loaded值，各自自增后写入相同的结果，导致最终计数小于实际完成的任务数，永远达不到阈值3，页面无法正常初始化。
• 字段可见性依赖隐式保证
  你对postValue的执行逻辑理解是正确的，它会将更新任务投递到主线程Looper队列，Android的Handler消息机制本身存在happens-before规则：投递消息前的线程操作，对消息在目标线程的执行过程可见。所以原有代码中postValue之前的字段赋值，理论上主线程收到回调时是可见的，但这个规则属于Android平台的隐式约定，没有语法层面的强制保证，代码可维护性较差。

更新后版本代码的合理性 #

你更新后的代码已经规避了绝大多数风险，设计是合理的：

• doOnSuccess执行在computation线程，耗时的heavyOperation不会阻塞主线程，符合预期。
• observeOn(AndroidSchedulers.mainThread())将后续的subscribe回调切换到主线程执行，三个任务的自增和setValue操作都在主线程串行执行，彻底解决了loaded变量的并发竞争问题。
• 有两层明确的可见性保证：
  1. RxJava的observeOn操作符自身保证：切换线程前的所有操作（doOnSuccess内的赋值），happen before切换线程后的所有操作（subscribe内的逻辑）
  2. LiveData的setValue触发Observer回调时，setValue前的所有操作，happen before Observer内的执行逻辑
     因此Activity在主线程收到isLoadedLiveData的回调时，所有后台更新的字段都已经完成写入，且对主线程可见，可以安全读取。

额外优化建议 #

• 建议将name、abbrev、heavyOperationResult、stuff这些字段封装为一个不可变的POJO类，加载完成后统一存储到单独的LiveData中，比单独的字段读取更安全，也更符合Jetpack组件的最佳实践。
• 把所有返回的Disposable都加入CompositeDisposable容器，在ViewModel的onCleared生命周期回调中调用clear()方法，避免RxJava订阅泄漏。
• 如果想要更稳妥的可见性保证，可以给这些字段加上volatile修饰，不需要额外性能开销，还能进一步明确多线程访问的语义。

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