SQLite作为轻量级嵌入式数据库，被大量应用于桌面软件、移动端和小型服务中。它的锁机制与MySQL、PostgreSQL等服务器型数据库差异明显，很多开发者在迁移经验时容易误判并发行为，从而引发死锁或长时间阻塞。要彻底解决这类问题，必须先弄清楚SQLite在文件层面是如何管理读写权限的。
SQLite锁机制与死锁形成的底层原理
SQLite在默认回滚日志模式下，数据库文件存在多种锁状态：未加锁、共享锁、保留锁、待定写锁和独占写锁。读操作只需获取共享锁，多个连接可同时持有；但第一个写操作会尝试升级到保留锁，真正提交时才申请独占写锁。由于SQLite锁作用于整个数据库文件，而不是具体的表或行，因此哪怕两个事务修改的是不同表，也会彼此排斥。
死锁的本质是循环等待。假设连接A先对表a开启写事务但尚未提交，连接B对表b开启写事务也未提交，随后A试图访问表b、B试图访问表a，二者都需要对方已占用的库级资源，而SQLite本身不会检测死锁，只会让后到者等待。若等待超时（由busy_timeout控制）仍未获取锁，就会返回SQLITE_BUSY，表现为database is locked错误。此外，在共享锁未被释放时发起写操作，也会因无法升级锁而阻塞。
另一个容易被忽略的点是，SQLite的写事务在开始执行第一条INSERT、UPDATE或DELETE时就会悄悄加保留锁，即便你还没显式COMMIT。如果此时另一个连接在持有读共享锁的上下文中尝试写，或者两个连接以相反顺序操作多个表，资源争用就会立刻出现。理解这些状态转换，是后续设计避锁方案的前提。
常见死锁场景与代码级复现
最常见的误用是在一个事务中交替读写多张表，且不同线程使用不同的访问顺序。下面这段伪代码展示了两个线程如何制造死锁：线程一先写表users再写表logs，线程二先写表logs再写表users，当二者交错执行且均未提交时，就会形成彼此等待。
import sqlite3
import threading
def worker_a():
conn = sqlite3.connect('app.db', timeout=5)
cur = conn.cursor()
cur.execute('BEGIN')
cur.execute('UPDATE users SET name='a' WHERE id=1')
# 模拟处理耗时
import time
time.sleep(1)
cur.execute('UPDATE logs SET msg='a' WHERE id=1')
conn.commit()
conn.close()
def worker_b():
conn = sqlite3.connect('app.db', timeout=5)
cur = conn.cursor()
cur.execute('BEGIN')
cur.execute('UPDATE logs SET msg='b' WHERE id=1')
import time
time.sleep(1)
cur.execute('UPDATE users SET name='b' WHERE id=1')
conn.commit()
conn.close()
t1 = threading.Thread(target=worker_a)
t2 = threading.Thread(target=worker_b)
t1.start()
t2.start()
t1.join()
t2.join()
上述代码在多线程同时跑时，很容易抛出database is locked。因为默认rollback journal下写事务占用保留锁，对方表的写操作必须等对方释放，而对方也在等自己，于是陷入僵局。解决思路之一是所有线程统一以相同顺序访问表，比如都先users后logs，这样最多是串行等待，不会循环死锁。
还有一种场景是读事务未及时关闭。某个连接执行了SELECT并保持了连接存活，未提交也未关闭，另一连接尝试写时就会被共享锁挡住。在Web应用中，如果使用了连接池但事务边界模糊，就容易出现这类问题。因此明确事务开始与结束、避免长事务，是规避死锁的基本纪律。
实用解决方案与WAL模式优化
最根本的避坑方法是统一资源访问顺序，并尽量缩短事务生命周期。把批量写操作合并到一个事务，且所有代码路径都按固定表顺序加锁，可以从结构上消除循环等待。同时应设置合理的busy_timeout，让SQLite在拿不到锁时自旋等待而不是立刻报错。
-- 设置等待时长，单位毫秒 PRAGMA busy_timeout = 5000; -- 开启WAL模式提升读写并发 PRAGMA journal_mode = WAL;
启用WAL（Write-Ahead Logging）模式后，写操作不再阻塞读操作，读使用旧快照、写追加到wal文件，提交时合并。这大幅降低了读写互相阻塞的概率，但WAL仍是库级写互斥，并发写之间依然要排队，只是死锁概率下降。配合统一的写顺序与重试逻辑，基本可以彻底解决业务层死锁。
在代码层建议封装一个带重试的写函数，捕获SQLITE_BUSY后按指数退避重试，并注意不要在写事务中穿插无关读操作。对于高频写场景，可考虑将SQLite仅作本地缓存，核心并发写交给服务器数据库，或采用连接队列串行化写请求。经过这些调整，原本随机出现的卡死和报错会消失，系统稳定性明显提升。
事务设计与监控的最佳实践
除了技术参数，团队规范也很关键。应当禁止隐式长事务，所有写逻辑显式BEGIN并在finally中commit或rollback。对批量任务拆批处理，每批控制在数百条以内，减少锁占用时间。同时在日志中记录SQLITE_BUSY发生的SQL与线程栈，便于回溯死锁源头。
监控方面，可定期执行PRAGMA lock_status（部分版本支持）或业务层统计busy次数。若发现busy频繁，说明并发模型需重构。通过压测模拟多连接交错的写顺序，提前暴露问题，比线上报错再排查更高效。把这些实践固化到脚手架中，新模块自然不易踩坑。
SQLitedeadlockdatabase_lock修改时间：2026-08-14 15:39:30