Spring Boot @Scheduled执行失败，报SQL Error:17008,SQLState:08003

看你遇到的这个@Scheduled和@Transaction配合导致的SQL Error 17008（连接已关闭）错误，我之前踩过几乎一模一样的坑！虽然之前有类似问题，但这次大概率是事务生命周期和定时任务线程的配合问题，给你几个实打实的排查和解决方向：

1. 别把事务注解直接加在定时任务方法上 #

这是最常见的踩坑点！Spring的@Scheduled任务由调度线程池执行，而事务的上下文依赖线程绑定，如果直接给定时任务方法加@Transactional，很容易出现任务执行到一半，事务提前提交/关闭，但后续代码还在尝试使用已关闭的JDBC连接的情况。

正确的姿势是把事务逻辑抽成独立的Service方法，给这个Service方法加事务注解，再在定时任务里调用它：

// 定时任务类
@Component
public class DailyScheduler {
    @Autowired
    private DailyTaskService dailyTaskService;

    @Scheduled(cron = "0 0 0 * * ?")
    public void processDailyScheduler() {
        // 这里无事务，只做任务调度逻辑
        dailyTaskService.executeTransactionalDbOps();
    }
}

// 业务服务类
@Service
public class DailyTaskService {
    @Transactional(rollbackFor = Exception.class)
    public void executeTransactionalDbOps() {
        // 所有需要事务的DB操作都写在这里
    }
}

2. 检查连接池的超时回收配置 #

SQLState 08003本质就是连接已被关闭，很可能是你的数据库连接池（比如HikariCP、Druid）设置的连接存活时间太短，而定时任务的执行时间超过了这个阈值，导致连接池提前回收了正在使用的连接。

重点查这几个参数：

• HikariCP的maxLifetime、idleTimeout
• Druid的maxActive、minEvictableIdleTimeMillis
  确保这些参数的值大于定时任务的最长预期执行时间，避免连接被提前回收。

3. 调整事务的传播行为与超时设置 #

如果你的事务方法内部有嵌套调用，要注意事务的传播行为（默认的REQUIRED是否符合你的业务逻辑），避免不必要的事务嵌套导致连接被占用或提前释放。

另外可以给@Transactional显式设置超时时间，防止事务长时间占用连接不释放：

@Transactional(rollbackFor = Exception.class, timeout = 300) // 超时时间300秒
public void executeTransactionalDbOps() {
    // 业务逻辑
}

4. 避免在事务外持有未初始化的查询结果 #

如果你在事务方法里执行了DB查询，然后把懒加载的实体对象（比如JPA返回的未初始化对象）拿到事务外部去处理，就会出现事务关闭后，懒加载触发时尝试使用已关闭的连接，直接抛出17008错误。

解决办法是在事务内部把需要的数据完全初始化：

@Transactional(rollbackFor = Exception.class)
public List<OrderDTO> getDailyOrders() {
    List<Order> orders = orderRepository.findByCreateTimeBetween(startTime, endTime);
    // 手动初始化懒加载属性，或者转换成DTO
    return orders.stream().map(order -> {
        Hibernate.initialize(order.getOrderItems()); // 初始化关联对象
        return convertToDTO(order);
    }).collect(Collectors.toList());
}

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