使用MyBatis游标与Druid时Statement已关闭异常的解决及手动关闭

• Cursor本质是长连接态的流式结果集，查询执行后会持续持有对应的数据库连接、Statement、ResultSet三类核心资源，无法像普通分页查询那样执行完毕后立刻将连接归还连接池。框架内置自动关闭逻辑的核心目的是做资源兜底防护：当检测到游标消费完所有数据（即无更多可读取对象、达到预设读取条数上限时），如果用户没有手动触发资源释放，框架会主动关闭关联资源，避免连接泄漏被连接池强制回收引发的连锁异常。
• 该设计本身是为了适配原生JDBC驱动的行为，但和Druid连接池的Statement代理逻辑存在天然兼容冲突：Druid会对代理的Statement对象做全生命周期状态追踪，当MyBatis框架层触发ResultSet.close操作时，Druid的代理逻辑会级联将关联的Statement标记为已关闭；后续游标需要基于该Statement拉取后续批次数据时，就会触发No operations allowed after statement closed异常。

• 该报错是MyBatis Cursor与Druid 1.2.5版本的已知兼容问题，核心触发点是Druid的Statement状态校验规则与MyBatis游标长持有资源的场景不匹配：当Druid检测到ResultSet关闭时会直接级联关闭关联Statement，而MyBatis的内置关闭逻辑会在游标即将消费完毕时提前触发ResultSet关闭，造成Statement状态和实际使用需求不同步。
• 现有业务代码完全依赖框架的内置自动关闭逻辑，没有在游标消费完成后主动显式释放资源，进一步放大了状态不同步的问题。

3.1 Druid连接池参数适配调整 #

针对游标长持有连接的场景，调整Druid的拦截规则与资源回收逻辑，配置示例如下：

spring:
  datasource:
    druid:
      # 适配长连接游标场景，关闭Statement级联关闭的硬状态校验
      validation-query-timeout: 1000
      # 开启连接泄漏回收机制，兜底避免资源泄漏
      remove-abandoned: true
      # 按业务最大游标消费时长调整回收阈值，例如设置为10分钟
      remove-abandoned-timeout: 600
      # 打印泄漏连接的堆栈日志，便于排查异常
      log-abandoned: true
      # 关闭PSCache，避免流式查询下的缓存兼容问题
      pool-prepared-statements: false
      max-pool-prepared-statement-per-connection-size: -1

3.2 代码改造实现Cursor资源手动管控 #

Cursor本身实现了AutoCloseable接口，可通过try-with-resources语法在代码层面主动管控资源生命周期，绕开框架内置自动关闭逻辑和Druid的状态冲突，改造后的业务代码示例：

@Transactional(readOnly = true)
public void streamDriver(EnterpriseDTO dto) {
    // 通过try-with-resources包裹Cursor，无论消费正常结束还是抛出异常，都会主动触发close释放关联的连接、Statement、ResultSet资源
    try (Cursor<Driver> cursor = baseMapper.findNeedDriver(dto.getEnterpriseId());
         Iterator<Driver> iterator = cursor.iterator()) {
        while (iterator.hasNext()) {
            Driver driver = iterator.next();
            log.info(driver.getDriverName());
        }
    } catch (Exception e) {
        log.error("驱动流式查询消费异常", e);
        throw e;
    }
}

改造的核心收益：

• 主动触发的close操作会在游标正常消费完成、消费中途异常中断两类场景下都释放关联资源，不再把资源释放的责任完全交给框架的内置判断逻辑。
• 当MyBatis的内置自动关闭逻辑被触发时，因为Cursor已经被代码层显式标记为已关闭状态，不会再触发Druid代理层的状态校验冲突，彻底规避No operations allowed after statement closed异常。

3.3 落地注意事项 #

• 必须保证整个Cursor的消费逻辑全部运行在同一个事务上下文内，当前代码上标注的@Transactional(readOnly = true)是必需配置，严禁将Cursor实例跨方法、跨事务传递，否则连接会在事务提交后被连接池回收，必然触发资源已关闭的异常。
• 尽量缩短游标循环内的执行耗时，避免在循环逻辑中嵌入非必要的远程调用、长耗时数据库操作，防止连接持有时间过长触发连接池的回收阈值引发新的连接泄漏问题。
• 可针对MySQL流式查询的特性，在Mapper方法上补充显式的fetchSize配置，进一步降低驱动与连接池的参数适配问题：

  @Select("select * from t_driver t where t.enterprise_id = #{enterpriseId} and t.deleted = 0")
  @Options(fetchSize = Integer.MIN_VALUE)
  Cursor<Driver> findNeedDriver(@Param("enterpriseId") Long enterpriseId);
  

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