Room数据库在系统应用中的隔离实践 - 第2节

2.1 隔离级别概述

SQLite 默认采用 可串行化（SERIALIZABLE） 隔离级别，这是数据库隔离等级中最严格的一档。在此级别下，并发事务的执行效果与串行执行完全一致，从而彻底避免了脏读、不可重复读和幻读。然而，这种严格的保证依赖于一套精巧的锁机制：共享锁（Shared Lock）、排他锁（Exclusive Lock）以及中间阶段的预留锁（Reserved Lock）和未决锁（Pending Lock）。

理解这组锁的获取、升级与释放流程，是掌握 Room 事务隔离的基础。下表总结了 SQLite 主要锁类型的语义与持有场景：

2.2 锁兼容性矩阵

锁之间的兼容关系决定了并发事务能否同时推进。下面的矩阵说明了四种锁之间的阻塞情况：

关键原则：S 锁 是唯一能被多个事务同时持有的锁；R 锁 标志着写事务即将开始，但不阻止其他读事务；P 锁 是升级到 X 锁前的最后屏障，阻止所有新 S 锁；X 锁 提供完全独占。

2.3 读写事务锁转换流程

一个典型的写事务从读阶段到提交阶段，会经历 NONE → S → R → P → X 的序列（读事务止步于 S）。下面通过 SVG 流程图直观展示路径：

2.4 默认事务行为：DEFERRED / IMMEDIATE / EXCLUSIVE

SQLite 通过事务修饰词控制初始锁的获取策略，这是上层 Room 事务配置的基础：

• DEFERRED（默认）：事务开始时不获取任何锁，首次读操作才获取 S 锁，首次写操作尝试获取 R 锁。这可能导致并发写事务因锁升级失败而抛出 SQLITE_BUSY。
• IMMEDIATE：事务开始时立即获取 R 锁，确保后续写操作不会因读锁阻塞而失败。推荐用于写事务。
• EXCLUSIVE：事务开始时立即获取 X 锁，完全禁止其他连接访问数据库文件。仅用于高优先级单向写操作。

-- 在 Room 中，可以通过 rawQuery 或 SupportSQLiteDatabase 控制
db.beginTransactionWithListenerNonExclusive(transactionListener)
// 等同于 DEFERRED 模式

// 若需要 IMMEDIATE 语义：
// 使用 SupportSQLiteDatabase.execSQL("BEGIN IMMEDIATE")
// 或者通过自定义 SQLiteOpenHelper 重写 onCreate/onConfigure

2.5 调试命令与锁状态观察

通过 SQLite 提供的 PRAGMA 可以在运行时观察当前数据库连接的锁状态：

-- 查看当前连接是否持有排他锁
PRAGMA main.locking_mode;
PRAGMA main.query_only;

-- 查看数据库日志（锁竞争时特别有用）
PRAGMA main.log_slow_queries = 3000;

-- 强制使用 IMMEDIATE 模式（避免 DEFERRED 导致的忙等待）
PRAGMA main.journal_mode = WAL;
PRAGMA main.synchronous = NORMAL;

2.6 常见错误与性能陷阱

• SQLITE_BUSY (5)：两个写事务在 DEFERRED 模式下同时升级到 R 锁失败。解决方案：统一使用 IMMEDIATE 事务，或启用 WAL 模式。
• 长事务持有 X 锁：写事务在提交前长时间持有排他锁，阻塞所有其他连接。解决方案：拆分大事务，减少提交前的工作量。
• 读事务阻塞写事务：虽然 S 锁与 R 锁兼容，但读事务若长时间不提交，会阻止写事务从 R 升级到 P。解决方案：在 Room 中使用 @Transaction(readOnly = true) 标记纯读操作，并确保快速释放。

2.7 性能与稳定性优化建议