[特殊字符] 事故报告：Hikari 连接池泄漏事故 - Connection leak detected

1. 问题现象

💡 简单说：系统发现有个数据库连接借出去5秒多了还没还！

2026-01-23 10:42:39.759 [HikariPool-1 housekeeper] WARN  com.zaxxer.hikari.pool.ProxyLeakTask - Connection leak detection triggered for com.mysql.cj.jdbc.ConnectionImpl@5d665c4c on thread global-pool-2, stack trace follows
java.lang.Exception: Apparent connection leak detected
    at com.zaxxer.hikari.HikariDataSource.getConnection(HikariDataSource.java:128)
    at org.springframework.jdbc.datasource.DataSourceUtils.fetchConnection(DataSourceUtils.java:158)
    at org.springframework.jdbc.datasource.DataSourceUtils.doGetConnection(DataSourceUtils.java:116)
    at org.springframework.jdbc.datasource.DataSourceUtils.getConnection(DataSourceUtils.java:79)
    at org.mybatis.spring.transaction.SpringManagedTransaction.openConnection(SpringManagedTransaction.java:80)
    at org.mybatis.spring.transaction.SpringManagedTransaction.getConnection(SpringManagedTransaction.java:67)

**2.**问题怎么发生的？

场景：批量处理100万条用户数据

// 原本的代码逻辑
public void test() {
    List<SysUser> 一百万条数据 = 获取数据();
    // 打算分2000批处理，每批500条
        processInBatch(一百万条数据, 500, mapperClazz, (mapper, partition) -> {
            processor.accept(partition);
        });
}

问题代码核心

// 有问题的批量处理方法
public <T, M> void processInBatch(List<T> list, int batchSize, Class<M> mapperClass, BiConsumer<M, List<T>> processor) {
    // 分片成2000个小任务
    // 交给线程池并发执行
    
    for (分片 : 所有分片) {
        线程池执行(() -> {
            processor.accept(分片);  // ⚠️ 问题就在这里！
        });
    }
}

🎯 根本原因：连接没还！

正常情况（单线程）：借了会还

员工借工具流程：
1. 去仓库借工具（获取数据库连接） ✅
2. 用工具干活（执行SQL）         ✅
3. 一小时后还工具（关闭连接）       ✅
4. 工具回到仓库（连接池）         ✅

完美闭环：借 → 用 → 还

出问题的情况（多线程）：借了不还

线程池员工A的悲惨一天：
早上9点：借了扳手（连接）干活任务1 → 干完没还 ❌
上午10点：直接用手里的扳手干任务2 → 干完还没还 ❌
上午11点：继续用这个扳手干任务3...
下午2点：仓库管理员发现："扳手借出5小时了！肯定是丢了！" ⚠️

问题流程：借 → 用 → 用 → 用 → 管理员报警

🛠️ 解决方案

方案一：调整报警时间（治标不治本）

# 就像把仓库的报警器调松一点
hikari:
  leakDetectionThreshold: 10000  # 10秒才报警
# 或者直接关掉报警
# leakDetectionThreshold: 0

方案二：重构代码（彻底解决）✅

核心思想：每个任务自己借，自己还！

    public <T, M> void processInBatch(List<T> list, int batchSize, Class<M> mapperClass, BiConsumer<M, List<T>> processor) {
        List<List<T>> partitions = ListUtil.partition(list, batchSize);
        for (List<T> partition: partitions) {
            ThreadPoolUtil.execute(() -> {
                SqlSession session = null;
                try {
                    // 1. 自己借工具
                    session = sqlSessionFactory.openSession();

                    // 2.获取Mapper
                    M mapper = session.getMapper(mapperClass);

                    // 3. 用工具干活
                    processor.accept(mapper, partition);

                    // 4. 提交
                    session.commit();

                } catch (Exception e) {
                    // 出问题就撤回
                    session.rollback();

                } finally {
                    // 5. 必须还工具！（重点⭐）
                    session.close();  // 确保归还连接
                }
            });
        }
    }

🎯总结：

根本原因 ：线程池破坏了 SqlSession 的 ThreadLocal 生命周期管理机制。

正常情况 （单线程）：

Spring/MyBatis 通过 ThreadLocal 管理 SqlSession，当线程结束时，框架会在 finally 中自动调用 close() 归还连接。

问题场景 （线程池）：

线程池中的线程是长期存活且复用的，不会"自然结束"。这导致：

• SqlSession 通过 ThreadLocal 绑定到线程池线程后无法自动清理

• 连接被长期持有且永不归还

• 框架依赖的"线程结束即清理"机制完全失效

本质 ：

线程池的长生命周期特性 与 ThreadLocal 的短生命周期假设发生了根本冲突，导致数据库连接"有借无还"。