📚 课程目录第3章事务提交与UI线程的冲突

3. 事务提交与UI线程的冲突

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章将深入讲解如何通过专用线程池将事务执行完全移出主线程，并处理结果回传与一致性保证。