iOS端SQLite执行sqlite3_step时冻结崩溃的排查解决问询

我们的iPhone/iPad应用出现因SQLite死锁导致的崩溃，崩溃日志如下：

Exception Type:  EXC_CRASH (SIGKILL)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Termination Reason: RUNNINGBOARD 0xdead10cc

应用使用系统内置SQLite库，数据库打开配置如下：

int err = sqlite3_open_v2(db_path, &db, SQLITE_OPEN_CREATE | SQLITE_OPEN_READWRITE | SQLITE_OPEN_FULLMUTEX, nil);

崩溃时应用在非主线程执行sqlite3_step时冻结，涉及的线程栈片段如下：

线程栈1 #

Thread 2 name:
Thread 2:
0   libsystem_kernel.dylib          0x00000001ea5fcd9c pread + 8 (:-1)
1   libsqlite3.dylib                0x00000001d065a228 seekAndRead + 96 (sqlite3.c:41646)
2   libsqlite3.dylib                0x00000001d05d3078 unixRead + 208 (sqlite3.c:41738)
3   libsqlite3.dylib                0x00000001d05e5e60 readDbPage + 180 (sqlite3.c:64270)
4   libsqlite3.dylib                0x00000001d0663ca8 getPageNormal + 488 (sqlite3.c:66892)
5   libsqlite3.dylib                0x00000001d066f388 getAndInitPage + 100     (sqlite3.c:76131)
6   libsqlite3.dylib                0x00000001d06705f8 moveToLeftmost + 136 (sqlite3.c:79298)
7   libsqlite3.dylib                0x00000001d05f93b4 sqlite3VdbeExec + 5000 (sqlite3.c:102042)
8   libsqlite3.dylib                0x00000001d05f75b4 sqlite3_step + 984 (sqlite3.c:94140)

线程栈2 #

Thread 3 name:
Thread 3:
0   libsystem_kernel.dylib          0x00000001df2adc88 fsync + 8 (:-1)
1   libsqlite3.dylib                0x00000001c52c7d18 unixSync + 212 (sqlite3.c:42244)
2   libsqlite3.dylib                0x00000001c52d0560 syncJournal + 576 (sqlite3.c:65600)
3   libsqlite3.dylib                0x00000001c52c78a4 sqlite3PagerCommitPhaseOne + 392 (sqlite3.c:67879)
4   libsqlite3.dylib                0x00000001c52b871c sqlite3BtreeCommitPhaseOne + 172 (sqlite3.c:78021)
5   libsqlite3.dylib                0x00000001c52b81ec vdbeCommit + 688 (sqlite3.c:90610)
6   libsqlite3.dylib                0x00000001c5290998 sqlite3VdbeHalt + 1320 (sqlite3.c:91020)
7   libsqlite3.dylib                0x00000001c52b29b4 sqlite3VdbeExec + 43400 (sqlite3.c:99633)
8   libsqlite3.dylib                0x00000001c52a75b4 sqlite3_step + 984 (sqlite3.c:94140)

线程栈3 #

Thread 4 name:
Thread 4:
0   libsqlite3.dylib                0x00000001eb90ef18 accessPayload + 312 (sqlite3.c:78866)
1   libsqlite3.dylib                0x00000001eb8f4634 sqlite3VdbeMemFromBtree + 200 (sqlite3.c:87070)
2   libsqlite3.dylib                0x00000001eb8e9e24 sqlite3VdbeExec + 40440 (sqlite3.c:98870)
3   libsqlite3.dylib                0x00000001eb8df5b4 sqlite3_step + 984 (sqlite3.c:94140)

目前无法在Debug版本复现问题，也没有明确的复现步骤，且问题不依赖具体查询，在应用多处的只读和修改查询中均会出现。

解决与排查建议 #

可能的修复方案 #

• 统一数据库连接管理：SQLITE_OPEN_FULLMUTEX仅保护单个连接的线程安全，如果多个线程各自创建独立连接，跨连接的并发读写会引发锁竞争。建议用单例模式维护全局唯一的数据库连接，所有线程共享该连接执行操作。
• 调整同步模式：尝试修改SQLite的同步配置，执行PRAGMA synchronous = NORMAL（平衡性能与安全性）或PRAGMA synchronous = OFF（提升性能但降低数据安全性），减少fsync调用频率，降低提交阶段的阻塞概率。
• 优化事务使用：所有修改操作必须包裹在显式事务中，避免SQLite自动开启的隐式事务频繁触发锁竞争。比如批量操作时，先执行BEGIN TRANSACTION，完成所有操作后再COMMIT。
• 替换SQLite版本：系统内置SQLite可能存在旧版本锁机制bug，集成最新版SQLite静态库替代系统库，验证是否能解决问题。

排查方向 #

• 获取完整崩溃报告：当前仅提供单个线程栈，需要查看所有线程的状态，确认是否存在多线程互相等待锁的死锁场景。
• 开启SQLite内部日志：在Release版本中通过sqlite3_config(SQLITE_CONFIG_LOG, ...)开启锁相关日志，记录锁的获取、释放操作，问题复现时通过日志定位触发点。
• 监控并发操作：在代码中添加日志，记录每个数据库操作的线程ID、操作类型（读/写）、起止时间，出现冻结时分析并发执行的操作列表。

需要补充的排查信息 #

• 完整的崩溃报告（包含所有线程栈、iOS版本、应用版本）
• 数据库大小、表结构及索引情况
• 崩溃发生的场景（如后台运行、同步数据时等）
• 代码中事务的使用方式（是否存在长事务、事务内是否有耗时操作）

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