Spring Boot定时任务执行长耗时存储过程引发GC超限OOM求助

核心结论 #

不存在线程调用超3小时SQL语句的原生限制（MS SQL数据库、Java线程均无此限制），GC overhead limit exceeded错误本质是内存无法有效回收，而非执行时长限制。以下是针对性排查方向：

1. 检查存储过程返回数据量 #

• 若三个存储过程返回百万级以上结果集，JDBC驱动会将结果集全量加载至内存（哪怕未显式处理），三个线程同时返回大结果时会快速耗尽堆内存。
• 直接在数据库客户端执行存储过程，确认返回数据量是否符合预期；若数据量过大，修改存储过程逻辑（如分页返回、仅返回必要字段），或在Java代码中分批处理结果集。
• 调整MS SQL JDBC驱动的fetchSize参数，避免一次性加载全量数据：

  stmt.setFetchSize(1000); // 按需设置分批获取的行数
  

2. 修复线程池重复创建问题 #

• 若每次定时任务执行时都新建Executors.newFixedThreadPool(3)，会导致旧线程池未被回收（未调用shutdown()），累积大量线程及关联内存资源。
• 将线程池改为全局单例，避免重复创建：

  @Configuration
  public class ThreadPoolConfig {
      @Bean(name = "spExecutor")
      public ExecutorService spExecutor() {
          return Executors.newFixedThreadPool(3);
      }
  }
  
  // 定时任务类中注入使用
  @Autowired
  @Qualifier("spExecutor")
  private ExecutorService spExecutor;
  

3. 排查JDBC资源泄漏 #

• 调用存储过程时，未正确关闭Connection、CallableStatement、ResultSet会导致资源无法被GC回收，长期累积引发内存泄漏。
• 强制使用try-with-resources自动关闭资源：

  private void callStoredProc() throws SQLException {
      try (Connection conn = dataSource.getConnection();
           CallableStatement stmt = conn.prepareCall("{call your_sp(?)}")) {
          stmt.setInt(1, param);
          try (ResultSet rs = stmt.executeQuery()) {
              // 逐行处理结果，避免持有整个结果集引用
              while (rs.next()) {
                  // 处理单条数据逻辑
              }
          }
      }
  }
  

4. 分析堆转储定位根因 #

针对GC overhead limit exceeded错误，重点查看堆转储中的以下内容：

• 存活对象占比：确认是否是ResultSet、JDBC驱动内部对象（如SQLServerResultSet）占比过高；
• 线程引用链：检查执行存储过程的线程是否持有大对象引用，或定时任务线程是否未释放对Future、线程池的引用；
• 内存泄漏点：使用堆分析工具（如VisualVM、MAT）查找无法被回收的对象的根引用，定位泄漏来源。

5. 调整定时任务触发逻辑 #

虽然fixedDelay=2000是上一次任务结束后再延迟执行，但需确认长耗时任务是否被异常重复触发：

• 检查定时任务线程池配置是否正确，确保长耗时任务占用的线程不会影响其他任务；
• 若该任务无需高频执行，可将fixedDelay调整为大于任务执行时长的数值，避免任务堆积。

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