Entity Framework多线程并发提交时SQLite报数据库锁定问题排查

你遇到的SQLite Error 5: 'database is locked'是多线程并发提交直接触发的数据库层锁冲突，和你用ServiceScopeFactory隔离线程作用域的实现无关。

• 你当前的服务配置完全符合EF Core的规范：Scoped生命周期的DbContext、仓储、工作单元，搭配每个操作独立创建服务Scope的写法，已经彻底避免了DbContext跨线程复用的非线程安全问题。
• 单线程批量写入10000+实体运行正常的现象，恰好说明应用层逻辑、EF上下文的生命周期配置没有问题；多线程并发提交时报错，问题完全出在SQLite的并发管控机制上。

SQLite作为单文件嵌入式数据库，没有独立的后台服务进程做全局并发调度，所有并发管控都是基于本地文件锁实现的，这是它的固有设计特性，不是使用不当导致的异常：

• 写操作采用全局排他锁：同一时刻仅允许一个数据库连接持有写权限执行事务提交，其他尝试发起写操作的连接会直接触发锁冲突
• 默认锁超时时间为0：只要发起写操作时没抢到锁，会立刻抛出database is locked错误，不会自动等待重试
• 三个并发线程对应的是三个独立的数据库连接，同时发起提交操作时会互相抢夺唯一的写锁，这是SQLite默认配置下多并发写操作时的正常表现，不是数据库损坏或者代码逻辑错误导致的异常。

• 调整连接字符串的锁等待配置：添加Default Timeout=30参数，让没抢到锁的连接最多等待30秒再重试，避免瞬时抢锁失败直接抛错，可解决绝大多数低并发场景下的随机锁问题
• 开启WAL日志模式：将SQLite默认的删除日志模式切换为预写日志模式，写操作会写入独立的日志文件，既保留写操作的排他性，又能消除读写操作之间的锁冲突，大幅降低并发写入时的锁触发概率
• 高并发写入场景下增加应用层写队列：将所有需要写入的实体统一投递到队列，由单个消费线程完成批量提交，从根本上避免多个数据库连接同时抢夺写锁的情况
• 注意不要为了规避锁问题把DbContext、仓储、工作单元改为Singleton生命周期，这会重新引入DbContext跨线程复用的线程安全问题，违背你最初用独立Scope隔离上下文的设计初衷

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