Spring Boot @Scheduled定时任务在GKE集群中运行失效排查

• 首先定位调度线程的实际运行状态
  • 执行 kubectl describe pod <目标Pod名称> 核对Pod的历史事件：确认是否存在被节点OOM Killer直接终止的记录，这类内核级别的进程终止不会输出任何应用层的停机日志，表现就是“应用对外REST服务还能正常响应，但后台调度线程已经被回收”
  • 执行 kubectl exec -n <目标命名空间> <目标Pod名称> -- jstack 1 拉取JVM全量线程栈：
    • 如果找不到名为 scheduling-1 的默认调度线程，说明调度器的线程池已经被提前销毁，需要进一步核对调度器的生命周期日志
    • 如果调度线程存在但一直处于BLOCKED/WAIT状态，说明定时任务的执行逻辑已经阻塞，后续所有调度动作都不会触发
• 对比两个部署应用的配置差异
  • 核对当前带REST接口的应用、以及旧的纯定时任务应用在GKE环境加载的Profile配置，检查是否存在误配置的调度参数：比如错误开启了调度器的无任务自动关闭逻辑、或者调度线程池的核心线程数被配置为0
  • 确认组件扫描范围是否偏移：如果当前应用的GKE环境配置中，单独指定了Spring的扫描路径仅覆盖REST控制器所在的包，会导致定时任务所在的类完全不被Spring容器管理，本地运行时因为加载的是本地开发Profile，没有这条扫描配置所以表现正常
• 排查手动依赖版本冲突的影响
  • 从提供的构建配置来看，存在手动指定多版本Spring生态组件的操作：单独写死了Actuator版本、MongoDB相关依赖的版本，没有完全对齐Spring Boot官方的依赖版本管理规则
  • 这类手动指定版本的操作很容易引发spring-context模块的版本冲突——而@Scheduled注解的解析、调度器的初始化逻辑全部依赖spring-context模块，版本不一致时很可能出现“调度器初始化时检测不到有效任务，直接关闭线程池”的异常，这类异常通常只会在特定运行环境（比如Alpine基础镜像的精简JRE环境）触发，本地开发时因为依赖缓存版本一致反而不会复现
• 修正日志配置导致的观测盲区
  • 定时任务中用LOGGER.finest()级别输出异常信息，而Java默认的日志输出级别是INFO，finest级别的内容默认会被完全过滤，哪怕定时任务执行失败也看不到任何日志，很容易误判为“任务从未触发”
  • 建议临时调整调度模块的日志级别为DEBUG，在GKE部署的启动参数里追加--logging.level.org.springframework.scheduling=DEBUG，就能看到完整的调度器生命周期日志，直接定位调度服务被关闭的触发原因
• 排除网络策略导致的线程阻塞
  • REST接口可正常访问仅能代表入站流量通畅，不代表Pod的出站流量无限制：如果GKE集群的网络策略限制了Pod访问Gmail IMAP服务的465出站端口，定时任务第一次执行时就会因为连接超时永久阻塞
  • 注意Spring Boot默认的调度线程池只有1个工作线程，一旦这个线程被网络超时永久阻塞，后续所有的定时任务都不会再被触发，表现和“定时任务从未执行”的现象完全匹配

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