使用CoroutineDispatcher.limitParallelism(1)修改共享状态是否无数据竞争？

核心结论 #

使用limitParallelism(1)且仅在该调度器的协程中读写共享状态时，可以保证无数据竞争，不需要额外的@Volatile或Mutex——哪怕底层线程会变化，kotlinx.coroutines也会维护必要的内存可见性和执行顺序。

原因分析 #

1. 串行执行的本质 #

limitParallelism(1)会强制所有提交到该调度器的协程任务串行执行：前一个任务的所有操作完成后，才会开始执行下一个任务。这从根本上消除了多个协程同时读写共享状态的可能，自然不会出现竞态条件。

2. 内存一致性保障（对应ExecutorService的happens-before） #

kotlinx.coroutines的调度器（包括通过limitedParallelism包装的）遵循JVM内存模型，提供了和ExecutorService类似的happens-before语义：

• 当一个协程任务在调度器上执行完成后，其所有内存写操作对后续在该调度器上执行的协程任务都是可见的。
• 调度器会确保任务切换时的内存屏障（Memory Barrier），即使底层线程变化，也不会出现内存可见性问题。

文档中提到“不保证底层系统线程始终相同”只是说明调度器可能复用不同线程，但这不会影响串行执行的语义和内存一致性——线程切换时的内存同步由调度器内部处理，开发者无需手动干预。

额外说明 #

如果你的共享状态还有其他读写路径（比如在该调度器之外的协程或线程中被访问），那仍然需要Mutex或@Volatile这类保护机制。但如果所有读写都严格限制在limitParallelism(1)的调度器协程内，就完全不需要额外措施。

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