Spring Batch为何为每个线程分配一个数据库连接？

结合你提到的技术栈（Java 8、Spring Boot 1.5、Spring Batch 3.0.7、HikariCP 2.7.6）和多数据源、多线程Job的配置，我来拆解背后的核心原因：

1. 事务隔离与JDBC连接的线程绑定特性 #

Spring Batch的核心是分块处理（Chunk-oriented processing），每个线程会独立处理一组Chunk数据。而JDBC连接本身是通过ThreadLocal实现线程绑定的——如果多个线程共享同一个连接，不同Chunk的事务会互相干扰，比如一个线程的事务回滚会破坏另一个线程的操作完整性。

所以每个线程启动Step执行时，会从对应的数据源获取专属连接，直到当前Chunk处理完成（事务提交/回滚）后才会归还到连接池，以此保证事务的隔离性。

2. JobRepository的线程安全需求 #

Spring Batch依赖JobRepository存储Job/Step的执行状态、Chunk处理记录（比如已读/已写数据量），你用的batcdb就是承载这个逻辑的数据源。为了保证多线程下状态更新的安全性，每个线程必须持有独立的数据库连接，避免并发操作时出现脏读、数据覆盖等问题。

3. HikariCP连接池的适配逻辑 #

你配置的HikariCP连接池，核心设计就是为每个请求（这里指线程的Chunk处理请求）分配空闲连接。当ThreadPoolTaskExecutor启动多个线程时，每个线程会向用到的数据源（比如readdb用于读、writedb用于写、batcdb用于JobRepository）分别申请连接，直到任务完成后释放。

这里要注意：如果你的Step同时涉及多个数据源，每个线程会从每个用到的数据源各占用一个连接——比如线程池大小设为15，但每个数据源默认只有10个连接，很容易出现连接耗尽的问题，需要根据实际场景调整两者的大小配比。

4. 多线程Step的设计约束 #

Spring Batch的多线程Step本质是让每个线程独立执行完整的ItemReader → ItemProcessor → ItemWriter流程，这个流程内的所有操作都处于同一个事务上下文。而事务的载体就是数据库连接，必须为每个线程分配专属连接来维持事务的完整性——比如你的Job1中，读数据、写数据、更新Job状态这一系列操作，都需要绑定到当前线程的连接上，确保要么全部成功，要么全部回滚。

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