本文详解 sqlite 在多线程客户端场景下的并发控制问题，重点解决“database is locked”和“unique constraint failed”异常，通过事务优化、原子性写入与隔离级别调整，实现无需手动加锁的健壮并发访问。
本文详解 sqlite 在多线程客户端场景下的并发控制问题，重点解决“database is locked”和“unique constraint failed”异常，通过事务优化、原子性写入与隔离级别调整，实现无需手动加锁的健壮并发访问。
在本地部署的 C/S 架构学习项目中，多个客户端通过独立线程与服务端通信，每个线程持有一个 SQLite 数据库连接。看似符合 ACID 原则，但实际运行时频繁抛出 SQLiteDatabaseLockException（数据库被锁定）和 SQLIntegrityConstraintViolationException（唯一约束失败），根本原因并非事务“未排队”，而是事务生命周期设计不当 + 竞态逻辑缺失。
? 核心问题剖析
- 事务未显式管理：SQLite JDBC 驱动默认启用自动提交（auto-commit = true）。这意味着每条 executeUpdate() 都是一个独立事务——看似原子，实则无法保证“检查 + 插入”这一复合操作的原子性；
- 竞态条件（Race Condition）：existsEntry() 与 addEntry() 是两个分离的语句，在多线程下，A 线程查到用户名不存在 → B 线程插入同名用户 → A 线程执行插入 → 触发 UNIQUE constraint failed；
- 长事务阻塞：若在事务中等待网络 I/O（如 ois.readObject()），事务长时间持有数据库锁，导致其他线程被阻塞并超时抛出 database is locked；
- SQLite 的轻量级锁机制：SQLite 使用文件级锁（EXCLUSIVE/SHARED），不支持行级锁。高并发写入极易触发 WAL 模式下的写冲突或传统 DELETE 模式下的忙等待失败。
✅ 正确实践：原子性 + 短事务 + 合理重试
1. 显式控制事务边界（关键！）
所有涉及读-写组合的操作必须包裹在显式事务中，并严格限制事务内仅执行数据库操作，禁止任何网络 I/O 或耗时计算：
private boolean performClientRegistration(ObjectInputStream ois, Connection dbConnection)
throws IOException, ClassNotFoundException, SQLException {
String userName = (String) ois.readObject();
String pwd = (String) ois.readObject();
String firstName = (String) ois.readObject();
String lastName = (String) ois.readObject();
// ✅ 所有客户端输入在事务外完成
dbConnection.setAutoCommit(false); // 关闭自动提交
try {
boolean success = DBHelper.registerUserAtomically(dbConnection, userName, pwd, firstName, lastName);
dbConnection.commit(); // 成功则提交
return success;
} catch (SQLException e) {
dbConnection.rollback(); // 失败则回滚
throw e;
} finally {
dbConnection.setAutoCommit(true); // 恢复自动提交（可选，但推荐）
}
}2. 使用原子 SQL 替代应用层检查
避免“先查后插”，改用带约束冲突处理的单条语句：
public static boolean registerUserAtomically(Connection conn, String userName, String pwd,
String firstName, String lastName) throws SQLException {
// ✅ 利用 SQLite 的 INSERT OR IGNORE + LAST_INSERT_ROWID()
String insertSql = "INSERT OR IGNORE INTO users (userName, pwd, firstName, lastName) " +
"VALUES (?, ?, ?, ?)";
try (PreparedStatement ps = conn.prepareStatement(insertSql)) {
ps.setString(1, userName);
ps.setString(2, pwd);
ps.setString(3, firstName);
ps.setString(4, lastName);
int affected = ps.executeUpdate();
return affected == 1; // 插入成功返回 true；已存在则为 0
}
}? 进阶方案：若需区分“注册成功”与“用户已存在”，可用 INSERT OR ABORT + 捕获 SQLITE_CONSTRAINT_UNIQUE 异常，或使用 UPSERT（SQLite 3.24+）：
INSERT INTO users (userName, pwd, firstName, lastName) VALUES (?, ?, ?, ?) ON CONFLICT(userName) DO NOTHING;
3. 调整 SQLite 运行模式（可选但推荐）
在初始化数据库连接时启用 WAL 模式，显著提升并发读写性能：
// 创建连接后立即执行
try (Statement stmt = connection.createStatement()) {
stmt.execute("PRAGMA journal_mode = WAL"); // 启用 WAL
stmt.execute("PRAGMA synchronous = NORMAL"); // 平衡安全性与性能
stmt.execute("PRAGMA busy_timeout = 5000"); // 设置忙等待超时（毫秒）
}4. 合理的重试策略（防御性编程）
对 SQLiteDatabaseLockException 可采用指数退避重试（最多 3 次），避免简单粗暴的无限等待：
public static boolean executeWithRetry(Supplier<Boolean> operation) {
int maxRetries = 3;
long delayMs = 100;
for (int i = 0; i <= maxRetries; i++) {
try {
return operation.get();
} catch (SQLException e) {
if (i == maxRetries || !e.getMessage().contains("database is locked")) {
throw e;
}
try {
Thread.sleep(delayMs);
delayMs *= 2; // 指数退避
} catch (InterruptedException ie) {
Thread.currentThread().interrupt();
throw new RuntimeException(ie);
}
}
}
return false;
}⚠️ 注意事项与总结
- 切勿使用 synchronized 包裹数据库操作：这会将并发降级为串行，违背数据库自身并发控制机制，且无法解决跨进程/跨 JVM 场景；
- 永远不在事务中做网络 I/O、文件读写或复杂计算：事务应是“最短路径”的纯数据库操作；
- SQLite 不适合高并发写密集型场景：若业务规模增长，应评估迁移到 PostgreSQL 或 MySQL；
- 连接池非必需但推荐：对于学习项目，每个线程独占连接可接受；生产环境建议使用 HikariCP 等轻量池化方案，并配置 connectionTimeout 和 maxLifetime；
- 日志与监控不可少：记录事务耗时、重试次数、锁等待时间，是定位并发瓶颈的第一手依据。
遵循以上原则，你的服务端即可在无需手动同步、不牺牲可读性的前提下，稳定支撑数十个并发客户端——这正是理解数据库事务本质与工程权衡的真正起点。
