第3章 事务提交与UI线程的冲突：SQLite事务默认在调用线程执行、锁竞争导致主线程等待
3.1 问题定义
Android应用中SQLite事务默认在发起调用的线程执行。当主线程（UI线程）直接开启或提交事务时，SQLite内部会持有数据库写锁或读锁。如果此时其他后台线程也在操作同一数据库，或者事务执行耗时较长（例如批量插入、复杂查询），就会出现主线程等待锁释放的现象。轻则造成UI丢帧、卡顿，重则触发ANR。
关键结论：主线程上的任何SQLite事务操作都是潜在的ANR隐患。即使单条SQL执行很快，事务的加锁、磁盘I/O、WAL checkpoint等过程仍可能让主线程阻塞数十甚至数百毫秒。
3.2 锁竞争场景分析
SQLite使用细粒度锁模型，主要分为读锁（SHARED）和写锁（RESERVED/PENDING/EXCLUSIVE）。事务提交时，写锁升级为EXCLUSIVE锁，此时所有其他读/写操作都会被阻塞。下图展示了一个典型冲突路径：
3.3 冲突原理详解
| 组件 | 行为 | 对主线程影响 |
|---|---|---|
| SQLiteConnection | 子类化SQLiteClosable，每个事务绑定到当前线程 | 主线程调用beginTransaction()时，线程关系即锁定 |
| 锁升级 | 读→写→EXCLUSIVE，升级需要等待当前所有读锁释放 | 若后台有长期读事务，主线程写操作无限等待 |
| WAL模式 | 读操作不阻塞写，但写事务提交时仍需WAL checkpoint刷盘 | checkpoint可能触发文件锁竞争 |
| Android StrictMode | 主线程磁盘IO默认触发警告 | 实际是锁等待+IO双重损耗 |
实际案例：某IM应用在聊天列表滑动时，主线程每读取一条消息都开启隐式事务，同时后台同步线程正在批量写入历史消息。结果UI线程等待写锁平均耗时150ms，导致列表滑动明显卡顿，重度场景触发ANR。通过将UI读取切换到WAL模式并使用
enableWriteAheadLogging()，将主线程事务下放到子线程，ANR率从3.2%降至0.05%。
3.4 锁竞争检测方法
定位主线程等待SQLite锁，可使用以下手段：
- 系统Trace：抓取systrace / perfetto，搜索“SQLite”或“lock”关键字，观察主线程的等待时间片。
- StrictMode：启用
StrictMode.ThreadPolicy的detectDiskReads()和detectDiskWrites()，直接报出主线程IO违规。 - SQLite配置：调用
SQLiteDatabase.getMaximumSize()并设置setLockingEnabled(false)？注意该API有风险，更安全的方式是使用WAL。
// 启用StrictMode主线程检测示例
StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder()
.detectDiskReads()
.detectDiskWrites()
.penaltyLog()
.penaltyDeath() // 调试阶段可直接崩溃
.build());3.5 规避方案概览
| 方案 | 原理 | 适用场景 | 复杂程度 |
|---|---|---|---|
| 异步事务委托 | 所有事务提交放到专用HandlerThread | 全局统一数据库 | 低 |
| WAL模式 | 读不阻塞写，写不阻塞读 | 读写并发高 | 低 |
| 事务合并/批量 | 减少事务开启次数，降低锁竞争频率 | 批量插入 | 中 |
| 自定义锁超时 | 设置LockTimeout，避免无限等待 | 极端场景 | 中 |
实验验证：在测试设备上，使用adb shell来模拟主线程写入场景：
然后使用
adb shell am start -n com.example.app/.MainActivity然后使用
sqlite3客户端连接到同一数据库执行BEGIN EXCLUSIVE;，观察应用是否出现卡顿或ANR。此方法可快速复现锁竞争。
3.6 下一步思考
本章揭示了事务提交与UI线程冲突的根本原因：SQLite默认在同线程执行事务，导致锁竞争直接作用在主线程。理解这一冲突是后续优化（异步化、WAL、事务拆分）的基础。第4章将深入讲解如何通过专用线程池将事务执行完全移出主线程，并处理结果回传与一致性保证。