本文详解 sqlite 在多线程客户端场景下的并发控制问题，重点解决“database is locked”和“unique constraint failed”异常，强调事务最小化、显式管理与隔离级别优化，而非粗粒度线程锁。
本文详解 sqlite 在多线程客户端场景下的并发控制问题，重点解决“database is locked”和“unique constraint failed”异常，强调事务最小化、显式管理与隔离级别优化，而非粗粒度线程锁。
在本地多客户端/单服务器架构中（如您描述的基于 ServerSocket 的 Java 应用），每个客户端由独立线程处理，并持有一个专属 SQLite 数据库连接，看似符合“一连接一线程”原则，但实际极易触发两类典型异常：
- SQLiteDatabaseLockException（或 JDBC 中的 "database is locked"）：源于 SQLite 的写锁排他性——同一时刻仅允许一个写事务持有数据库文件锁；
- SQLIntegrityConstraintViolationException（"UNIQUE constraint failed"）：源于经典的检查-插入竞态（check-then-act race condition）：线程 A 查到用户名不存在 → 线程 B 同样查到不存在 → 两者先后执行 INSERT，后者因唯一约束失败。
⚠️ 关键误区：SQLite 不会自动“排队”事务。它遵循 ACID，但其默认的 DEFERRED 事务模式下，锁延迟到首次写操作才获取，且事务生命周期若横跨网络 I/O（如等待 ObjectInputStream.readObject()），将导致锁长期占用，加剧争用。
✅ 正确实践：短事务 + 原子性保障 + 隔离级调优
1. 强制使用显式、短生命周期事务
避免依赖 JDBC 默认的自动提交（auto-commit=true）。所有涉及读+写的业务逻辑（如注册）必须包裹在显式事务中，并确保事务范围严格限定在数据库操作内，绝不包含网络读写：
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 {
// ? 原子性插入：利用 UNIQUE 约束 + IGNORE 或 REPLACE 策略
PreparedStatement insertStmt = dbConnection.prepareStatement(
"INSERT OR IGNORE INTO users (userName, pwd, firstName, lastName) VALUES (?, ?, ?, ?)"
);
insertStmt.setString(1, userName);
insertStmt.setString(2, pwd);
insertStmt.setString(3, firstName);
insertStmt.setString(4, lastName);
int rowsAffected = insertStmt.executeUpdate();
// ✅ 成功插入返回 true；若已存在，rowsAffected == 0，但仍属成功（无异常）
dbConnection.commit();
return rowsAffected == 1;
} catch (SQLException e) {
dbConnection.rollback(); // ⚠️ 必须回滚！
throw e;
} finally {
dbConnection.setAutoCommit(true); // 恢复默认，避免影响后续操作
}
}? 为什么 INSERT OR IGNORE 更优？
它将“检查是否存在”和“插入”合并为单条原子语句，彻底消除竞态。若用户名已存在，语句静默跳过（executeUpdate() 返回 0），不抛异常；若插入成功，返回 1。无需 existsEntry() 查询，显著缩短事务时间。
2. 避免长事务：严禁在事务中进行网络 I/O
您的原始代码中，ois.readObject() 发生在事务开始前，这本身是正确的；但务必确保所有数据库操作（包括查询、更新）都在 commit() 前完成，且 commit() 后再执行 oos.writeObject()。错误示例：
// ❌ 危险：事务未结束就阻塞在网络写入上，锁被长期持有 dbConnection.commit(); oos.writeObject(Response.SUCCESS); // 若此处卡住，锁仍被占用！
✅ 正确顺序：
- 读取客户端数据（ois.readObject()）→
- 开启事务 →
- 执行所有 DB 操作 →
- commit() →
- 立即发送响应（oos.writeObject()）→
- 关闭资源。
3. 调整 SQLite 连接参数与隔离级别
在创建连接时，通过 JDBC URL 显式配置关键参数：
String url = "jdbc:sqlite:app.db" +
"?journal_mode=WAL" + // ✅ 启用 WAL 模式，提升并发读写能力
"&synchronous=NORMAL" + // 平衡性能与安全性（非 FULL）
"&busy_timeout=5000"; // ✅ 设置忙等待超时（毫秒），避免立即报 lock- journal_mode=WAL：使读操作不阻塞写，写操作不阻塞读（相比默认 DELETE 模式大幅提升并发）；
- busy_timeout：当遇到锁时，SQLite 会等待指定毫秒后重试，而非立刻抛异常，为重试逻辑提供缓冲；
- 避免使用 EXCLUSIVE 模式用于生产——它虽能测试锁问题，但会完全禁止其他连接，违背多客户端设计初衷。
4. 补充建议：连接池与重试机制（进阶）
- 对于更复杂的场景，考虑引入轻量连接池（如 HikariCP），复用连接并统一管理事务边界；
- 对于偶发的 SQLTimeoutException（超时锁），可实现指数退避重试（最多 3 次），但绝不能对 UNIQUE constraint failed 重试——它代表业务逻辑冲突，应直接返回用户“用户名已存在”。
总结
解决 SQLite 并发问题的核心不是加锁，而是尊重其嵌入式数据库的设计约束：
? 事务要短——只包裹纯数据库操作，剥离网络 I/O；
? 操作要原子——用 INSERT OR IGNORE / UPSERT 替代“先查后插”；
? 配置要合理——启用 WAL、设置 busy_timeout、显式控制 auto-commit；
? 异常要精准处理——区分锁超时（可重试）与约束冲突（业务失败）。
遵循以上原则，您的多客户端注册/登录服务即可在 SQLite 上稳定、高效运行，无需引入复杂同步机制。
