RxJava中subscribeOn(mainThread).subscribe()是否保证主线程同步执行？

核心结论 #

调用subscribeOn(mainThread).subscribe()不能保证同步执行，完全有可能出现主线程的其他任务优先执行的情况，你给出的输出结果B→D→A→C是完全可能发生的，且这个行为高度依赖调度器的具体实现。

具体分析 #

1. subscribeOn的本质 #

subscribeOn的作用是指定Observable的订阅逻辑（包括上游Observable的创建、订阅链路的建立）所在的线程。但不管指定的是哪个线程，只要调度器是基于异步消息队列实现的（比如Android主线程调度器），提交的任务都会被放入对应线程的任务队列，等待该线程的调度循环依次执行，而非立刻同步执行。

2. 示例场景拆解 #

看你给出的代码时序：

• t=1秒：后台线程调用printA.subscribeOn(mainThread).subscribe()——此时会把printA的订阅任务提交到主线程的消息队列，主线程此时可能在处理其他任务，不会立刻执行这个订阅任务。
• t=2秒：主线程执行System.out.println("B")——这是主线程当前同步执行的代码，会直接输出，无需等待队列中的任务。
• t=3秒：主线程调用printC.subscribeOn(mainThread).subscribe()——同样把printC的订阅任务追加到主线程消息队列的末尾。
• t=4秒：主线程执行System.out.println("D")——依然是当前同步代码，直接输出。

当主线程完成B和D的同步输出后，才会开始处理消息队列中的任务，先执行最早提交的A的订阅任务，再执行C的，所以最终输出B→D→A→C是完全符合调度逻辑的。

3. 调度器实现的影响 #

这个行为完全依赖调度器的实现：

• 以Android平台的AndroidSchedulers.mainThread()为例，它基于Handler将任务post到主线程的Looper消息队列。主线程的Looper会按顺序处理队列中的任务，只有当前正在执行的任务完成后，才会取下一个任务执行。因此同步代码（B、D）必然优先于队列中的异步任务（A、C）执行。
• 如果是自定义的“主线程调度器”（比如当检测到当前线程已是主线程时，直接同步执行任务），那结果会不同，但这种实现不符合RxJava调度器的常规设计，也不是Android平台的标准实现。

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