SqlSession关闭后，其持有的数据库连接如何释放？

Question

在使用 MyBatis 进行数据库操作时，SqlSession 负责管理数据库连接的获取与交互。常见的问题是：当调用 SqlSession 的 close() 方法后，其持有的数据库连接是否一定会被释放回连接池？在实际开发中，若 SqlSession 由 Spring 管理且与事务结合使用，close() 调用可能并不会立即释放底层连接，而是交由事务管理器决定。此外，若未正确配置连接池（如 Druid、HikariCP）或忽略了异常处理导致 SqlSession 未被正常关闭，连接可能长时间占用无法释放，最终引发连接泄漏或连接池耗尽。因此，需明确 SqlSession 关闭机制与连接池协同工作的原理，确保连接在适当时机安全归还。

Answer 1

一、SqlSession 与数据库连接的基本关系

在 MyBatis 中，SqlSession 是执行 SQL 操作的核心接口，它封装了与数据库的交互过程。每一个 SqlSession 实例通常持有一个底层的 JDBC Connection 对象。

当通过 sqlSessionFactory.openSession() 创建会话时，MyBatis 会从配置的数据源（DataSource）中获取一个连接。这个连接可能来自连接池（如 HikariCP 或 Druid），也可能是一个直连。

调用 SqlSession.close() 方法时，MyBatis 并不直接关闭底层连接，而是将其归还给数据源。是否真正释放取决于数据源的实现机制。

调用方法	行为描述	连接状态变化
openSession()	从 DataSource 获取连接	连接被占用
close()	通知 DataSource 连接可用	连接归还池中（若为池化）
commit()/rollback()	事务提交或回滚	不影响连接释放时机

二、Spring 集成下的 SqlSession 生命周期管理

在 Spring + MyBatis 的典型应用中，SqlSession 通常由 SqlSessionTemplate 或 MapperFactoryBean 自动管理，开发者无需手动创建和关闭。

Spring 使用 SqlSessionUtils 来绑定当前线程的 SqlSession 到事务同步管理器（TransactionSynchronizationManager）。这意味着：

• 在事务范围内，同一个线程多次获取 SqlSession 会复用同一个实例。
• 即使显式调用了 close()，Spring 可能仅做引用计数递减，而非立即释放连接。
• 真正的连接释放发生在事务结束（提交或回滚）之后，由事务管理器触发。

@Autowired
private SqlSessionTemplate sqlSession;

public void updateUser(User user) {
    try {
        sqlSession.update("updateUser", user);
        sqlSession.close(); // 实际未释放连接
    } catch (Exception e) {
        throw new RuntimeException(e);
    }
}
    

上述代码中，close() 调用可能被 Spring 拦截并忽略物理关闭，直到事务完成。

三、连接池协同工作机制解析

主流连接池如 HikariCP 和 Druid，在 MyBatis 底层通过 DataSource 接口与之交互。连接的“释放”本质上是将连接对象返回给连接池的空闲队列。

关键流程如下：

1. MyBatis 从 DataSource.getConnection() 获取连接。
2. 执行 SQL 操作期间，连接处于活跃状态。
3. 调用 SqlSession.close() → 触发 Connection.close()。
4. 连接池重写 close() 方法，实际执行归还逻辑而非物理断开。

以 HikariCP 为例，其 HikariProxyConnection 的 close() 方法内部调用 poolEntry.recycle()，将连接重新置为空闲状态。

四、异常场景下的连接泄漏风险分析

尽管框架提供了自动管理机制，但在以下情况下仍可能导致连接无法释放：

• 未使用 try-with-resources 或 finally 块关闭 SqlSession。
• 抛出异常导致后续 close() 语句未执行。
• 自定义拦截器中持有连接引用未清理。
• 连接池配置不合理，如最大空闲时间过长或泄露检测关闭。

例如：

SqlSession session = sqlSessionFactory.openSession();
try {
    User user = session.selectOne("selectUser", 1);
    int result = 1 / 0; // 抛出异常
    session.close();
} catch (Exception e) {
    // session 未正确关闭
}
    

该情况会导致连接未归还，持续占用直至超时或 GC。

五、最佳实践与解决方案汇总

为确保连接安全释放，建议采取以下措施：

方案	说明	适用场景
使用 Spring 声明式事务	交由容器管理生命周期	Web 服务、企业级应用
启用 try-with-resources	确保 close() 必然执行	独立运行的批处理任务
开启连接池泄露检测	Druid: testWhileIdle, removeAbandoned	高并发系统
监控连接使用情况	通过 JMX 或 Prometheus 暴露指标	生产环境运维

同时可结合 AOP 或日志埋点追踪 SqlSession 的打开与关闭匹配情况。

六、可视化流程：SqlSession 关闭与连接归还流程图

以下 Mermaid 流程图展示了从调用 close() 到连接最终归还的完整路径：

graph TD
    A[调用 SqlSession.close()] --> B{是否在Spring事务中?}
    B -- 是 --> C[SqlSessionHolder 引用计数 -1]
    C --> D{计数是否为0?}
    D -- 否 --> E[暂不释放连接]
    D -- 是 --> F[触发 Connection.close()]
    B -- 否 --> F
    F --> G{Connection 是否来自连接池?}
    G -- 是 --> H[连接池回收连接至空闲队列]
    G -- 否 --> I[物理关闭 TCP 连接]
    H --> J[连接可被后续请求复用]
    I --> K[资源彻底释放]