4. 多线程并发读场景：@Query 与读锁、快照隔离实现

4.1 并发读的核心挑战

在系统应用中，多个线程同时对同一张数据库表执行 SELECT 查询是常见需求。如果不加控制，可能出现脏读（读取未提交数据）、不可重复读（同一事务内两次读取结果不一致）或幻读（结果集行数变化）。Room 基于 SQLite，其默认隔离级别为 SERIALIZABLE（串行化），使用 读写锁 来保证一致性。但在高并发读场景下，串行化会严重降低吞吐量。Room 通过 快照隔离（Snapshot Isolation）配合 WAL（Write-Ahead Logging） 模式，允许读操作不阻塞写操作，从而大幅提升并发读性能。

4.2 原理：快照隔离与读锁

SQLite 的 WAL 模式为每个数据库连接维护一个逻辑上的“快照”。当读事务开始时，SQLite 会记录当前的 WAL 序列号，后续的读操作始终基于该序列号对应的数据库状态，即使其他线程（或连接）同时执行写操作并提交了新版本，当前读线程看到的仍是自己开始时刻的快照。这实现了 MVCC（多版本并发控制） 的读一致性，且读操作无需等待写锁释放，写操作也无需等待读锁。

Room 默认使用 共享读锁（Shared Read Lock） 与 WAL 模式。当开启 WAL 时，读操作仅获得一个 SHARED 锁，允许同时多个线程持有该锁；写操作需要 RESERVED 或 EXCLUSIVE 锁。因此并发读场景下，读线程之间不互斥，读与写之间也不互斥（写线程仅阻塞其他写线程）。

关键点： 快照隔离只保证读事务内部的一致性，但跨事务的读（例如两次独立 @Query 调用）不能保证看到相同的数据。如果需要事务内一致性，请使用 @Transaction(readOnly = true) 包裹多次查询。

4.3 实现流程：在 Room 中启用快照隔离并发读

  1. 配置数据库 Builder 开启 WAL：RoomDatabase.Builder 的 .setJournalMode(JournalMode.WRITE_AHEAD_LOGGING)。
  2. 定义 DAO 接口：使用 @Query 注解编写读操作。
  3. 创建可并发调用的读操作：在多个后台线程（如 Kotlin 协程或 RxJava）中并行执行 DAO 方法。
  4. 可选：使用 @Transaction(readOnly = true) 包裹一组查询，确保在同一个快照下执行。
  5. 验证并发效果：通过日志或性能工具确认无锁等待、无脏读。

4.3.1 配置 WAL 模式

@Database(entities = [Article::class], version = 1)
abstract class AppDatabase : RoomDatabase() {
    abstract fun articleDao(): ArticleDao

    companion object {
        fun create(context: Context): AppDatabase {
            return Room.databaseBuilder(context, AppDatabase::class.java, "my_db")
                .setJournalMode(RoomDatabase.JournalMode.WRITE_AHEAD_LOGGING)  // 开启 WAL
                .build()
        }
    }
}

4.3.2 DAO 接口 – 快照隔离下的并发查询

@Dao
interface ArticleDao {
    // 单个查询：Room 自动使用快照隔离读
    @Query("SELECT * FROM articles WHERE id = :id")
    fun getArticleById(id: Long): Article?

    // 事务内多个查询，保证同一个快照
    @Transaction(readOnly = true)
    @Query("SELECT * FROM articles WHERE category = :category")
    fun getArticlesByCategory(category: String): List<Article>
}

4.3.3 多线程并行读示例（Kotlin 协程）

val dao = db.articleDao()
val scope = CoroutineScope(Dispatchers.Default + SupervisorJob())

// 两个读操作可以同时执行，互不阻塞
scope.launch {
    val article1 = withContext(Dispatchers.IO) { dao.getArticleById(1L) }
    Log.d("Reader1", "$article1")
}
scope.launch {
    val article2 = withContext(Dispatchers.IO) { dao.getArticleById(2L) }
    Log.d("Reader2", "$article2")
}

4.4 调试与验证并发读

通过 adb shell dumpsys dbinfo <package> 可以查看数据库的 WAL 状态、活跃事务数量、锁等待情况。此外，在 Room 的日志中开启 QueryCallback 或设置 SQLiteDatabase.enableWriteAheadLogging() 的日志级别，可观察并发读的线程执行顺序。

调试方法命令 / 配置观察点
数据库统计adb shell dumpsys dbinfo com.example.appwal-index 大小、read transactions、write transactions
Room SQL 日志.setQueryCallback(…)每个 SQL 执行的时间戳和线程名
WAL 锁试验手动添加 sleep 模拟慢查询确认读线程是否被写线程阻塞
注意： WAL 模式下，如果读事务未及时结束（例如长时间持有 Cursor 未 close），会阻止 WAL 合并 checkpoint，导致数据库文件膨胀。务必确保读操作完成后关闭 Cursor 或使用 Flow/LiveData 等自动管理生命周期。

4.5 常见错误与避坑

  • 未开启 WAL 导致读互斥：默认 DELETE 日志模式下，读与写会竞争同一把锁。
  • 事务内混用读与写：在 @Transaction 中先读后写，会导致写操作阻塞其他读线程（因为读锁升级为写锁）。
  • 以为 @Query 自动提供事务：单个 @Query 本身就是一个隐式读事务，但多次调用之间不保证一致性。必须显式使用 @Transaction(readOnly = true) 实现快照隔离。
  • 快照隔离与写后读不一致：线程 A 写入并提交后，线程 B 开始的新事务可能仍未看到最新数据（因为快照在事务开始时已固定）。

4.6 性能与稳定性优化

策略说明效果
缩小事务范围读事务内只做必要查询，尽早释放 Cursor减少 WAL 堆积
固定线程池使用固定大小的线程池（如 Dispatchers.IO 有限线程）避免过多并发读导致 WAL 拆过慢
定期 checkpoint通过 PRAGMA wal_checkpoint(TRUNCATE) 手动触发控制 WAL 文件大小
使用 Flow 或 LiveDataRoom 会监听表变化，自动重新查询减少手动快照管理的复杂度

4.7 图解：多线程并发读与快照隔离流程

多线程并发读快照隔离流程 读请求线程A 读请求线程B WAL 快照管理器 分配各自事务快照版本号 DB 主文件 + WAL 共享读锁 说明：线程A和B同时获取共享读锁，各自在WAL快照管理器下获得独立快照，互不阻塞
最佳实践： 在系统级应用中，推荐优先使用 @Transaction(readOnly = true) 来声明读事务，一是明确语义，二是 Room 会利用 WAL 快照实现真正的快照隔离，无需手动管理读锁。对于仅一次查询，可省略 @Transaction，因为单个查询自动在隐式事务中执行。

通过上述原理、代码实现、调试表和性能优化策略，你可以在 Room 中安全高效地实现多线程并发读场景，利用快照隔离消除读-写冲突，同时保持数据一致性。

← 上一章 📖 返回目录 下一章 →