每次数据库操作新建并关闭连接：性能影响、最佳实践及规模化问题

问题背景 #

我最近在桌面应用中遇到了如下错误：

org.sqlite.SQLiteException: [SQLITE_BUSY] The database file is locked (database is locked)

我判断原因是跨方法复用单个数据库连接进行读写操作导致的，于是改成每次读写时新建连接，示例代码如下：

try {
    Connection connection = DriverManager.getConnection(url);
    // 业务代码逻辑
    connection.close();
}
catch (SQLException e) {
    e.printStackTrace();
}

注：此修改已解决数据库锁问题

疑问解答 #

1. 上述做法是否会导致应用未来出现性能问题？ #

会存在一定性能损耗，但在桌面应用低负载场景下几乎可以忽略。创建SQLite连接的核心开销是文件打开、权限校验和连接上下文初始化，单次操作开销不大；但如果是高频次的小读写操作，累积的连接创建/销毁开销会逐渐显现。

2. 即使是极小的修改也新建连接是否为良好实践？ #

不算最佳实践。对于连续的、关联的极小数据库操作（比如连续查询多个关联表），复用同一个连接能减少重复初始化的开销；但如果是分散的、低频次的操作，新建连接的影响可以接受。核心原则是：在保证线程安全、避免锁冲突的前提下，尽量复用连接，但不要跨长时间/多方法持有连接导致锁占用。

3. 当应用发展为高负载数据库操作时，该做法有哪些利弊？ #

弊端

• 连接开销累积：高负载下频繁创建/销毁连接会占用大量CPU和IO资源，拖慢整体响应速度。
• 资源耗尽风险：SQLite同时打开的连接数受系统文件句柄限制，极端情况下可能出现无法创建新连接的错误。
• 事务效率低下：跨操作的事务无法在同一个连接中执行，要么放弃原子性，要么引入更复杂的事务实现，增加业务复杂度。

优势

• 避免锁冲突：每个操作用完即释放连接，不会长时间持有数据库锁，能大幅降低SQLITE_BUSY错误的概率。
• 实现简单：不需要维护连接池或连接复用逻辑，代码复杂度低，适合快速解决问题。

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