同时运行多个Spring Batch作业时出现线程死锁问题

我之前确实碰到过和你一模一样的问题——Spring调度的多个Batch定时任务在应用重启后首次运行就挂起，查下来就是Bean初始化阶段的资源竞争导致死锁。下面是我一步步排查和解决的思路，应该能帮到你：

1. 深挖线程死锁报告的细节 #

从Java VisualVM导出的线程转储里，一定要定位清楚死锁线程各自持有的锁和等待的锁：

• 通常你会看到线程A拿着BeanX的初始化锁，同时在等BeanY的锁；而线程B拿着BeanY的锁，在等BeanX的锁，形成了循环等待。
• 重点对应这些线程到你的三个定时任务，看看它们在初始化哪些共享Bean——比如数据源、JobRepository、自定义的业务服务类这类单例Bean，几乎都是竞争的核心。

2. 梳理定时任务的Bean依赖链 #

• 检查三个任务对应的Job/Step是不是都依赖了同一个单例Bean，而且这些Bean的初始化方法（比如@PostConstruct注解的方法）里有没有同步逻辑、耗时操作，或者在初始化时又触发了其他Bean的初始化，形成交叉依赖。
• 举个例子：如果任务A依赖ServiceA，ServiceA初始化时要调用ServiceB；任务B依赖ServiceB，ServiceB初始化时要调用ServiceA，这种循环依赖在并行初始化时就很容易死锁。

3. 验证Job启动的时机与方式 #

• 如果你是用@Scheduled直接调用JobLauncher.run()，要注意JobLauncher默认是单例，而且run()内部的同步逻辑可能和Bean初始化锁冲突。另外，多个任务同时启动时，会不会同时触发JobRepository的初始化（比如首次访问数据库）？
• 可以先做个快速验证：给三个任务加个启动延迟，比如第一个0秒、第二个2秒、第三个4秒，如果死锁消失了，那基本就是首次启动的并行初始化竞争导致的。

4. 检查Bean的作用域与懒加载策略 #

• 确认竞争的Bean是不是单例（默认是），如果不是必须提前初始化的，可以给这些Bean加上@Lazy注解，让它们在真正被任务调用时才初始化，分散初始化压力。
• 要是你开了全局懒加载（spring.main.lazy-initialization=true），反而可能因为多个任务同时触发懒加载引发竞争，这时候可以给核心Bean（比如JobRepository）设置@Lazy(false)，强制提前初始化完成。

5. 提前初始化核心Batch组件 #

• JobRepository是Spring Batch的核心，所有任务都会用到它。如果它的初始化需要访问数据库，而数据库连接池首次获取连接时要做初始化，多个任务同时抢着初始化JobRepository就容易锁死。
• 可以在应用启动阶段提前触发它的初始化：写个配置类，加个@PostConstruct方法，里面调用jobRepository.getJobInstances("test", 0, 1)这类简单方法，让它在任务启动前就完成初始化。

6. 开启Spring调试日志追踪 #

把org.springframework包的日志级别设为DEBUG，你能看到Bean初始化的完整顺序和锁的获取过程：

• 重点找Creating shared instance of singleton bean和Waiting for bean initialization这类日志，很容易发现哪个Bean的初始化卡在了等待其他Bean的锁上。

• 解决循环依赖：如果是Bean循环依赖导致的死锁，用@Lazy或者ObjectProvider延迟获取依赖Bean，避免初始化时的直接循环。
• 串行化启动：给定时任务的启动逻辑加个单线程池，或者用本地锁确保同一时间只有一个任务在初始化核心Bean——这会牺牲一点并行性，但能解决启动阶段的死锁问题。
• 优化初始化逻辑：把@PostConstruct里的耗时操作（比如数据库连接、第三方服务调用）移出去，改成懒加载或者异步初始化，避免Bean初始化时长时间持有锁。

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