Multithreaded Step

## The problem it solves By default a Spring Batch **chunk-oriented step** runs on a single thread: it reads N items (the chunk size), processes them, writes them in one transaction, commits, then repeats — strictly sequentially. If each write is I/O-bound (a DB insert, an HTTP call), the single thread spends most of its time waiting, leaving CPU idle. A **multithreaded step** lets multiple chunks be processed **concurrently on several threads inside the same JVM**. ## How to enable it You attach a Spring `org.springframework.core.task.TaskExecutor` to the step via the builder: ```java new StepBuilder("myStep", jobRepository) .<In, Out>chunk(100, transactionManager) .reader(reader).processor(processor).writer(writer) .taskExecutor(taskExecutor) // <-- makes it multithreaded .build(); ``` Internally the step's `RepeatTemplate` (a `TaskExecutorRepeatTemplate`) submits each chunk iteration to the executor. Use a real pooled executor like `ThreadPoolTaskExecutor`. If you pass `SyncTaskExecutor` (the default) it runs on the caller thread and stays single-threaded. ## The core gotcha: shared, stateful components There is exactly **one** `ItemReader` instance for the step, shared by every worker thread. Most built-in readers are **stateful** — e.g. `JdbcCursorItemReader` walks a JDBC cursor, `FlatFileItemReader` tracks the current line, `JpaPagingItemReader` tracks a page counter. Calling `read()` from multiple threads without synchronization corrupts that state: skipped rows, duplicates, `ArrayIndexOutOfBoundsException`, etc. The fix is `org.springframework.batch.item.support.SynchronizedItemStreamReader`, which wraps your reader and makes `read()` `synchronized`: ```java SynchronizedItemStreamReader<T> safe = new SynchronizedItemStreamReader<>(); safe.setDelegate(realReader); ``` (There is a matching `SynchronizedItemStreamWriter` if your writer is not thread-safe.) Note synchronizing `read()` serializes the reading — the parallelism win comes from processing and writing running concurrently, not reading. ## throttleLimit `throttleLimit` bounds how many chunks may be **in flight** (submitted but not yet completed) at once, independent of the executor's own pool size. Classically it defaulted to 4. In Spring Batch 5 the `throttleLimit(int)` builder method is **deprecated**; the recommended control is to size the `TaskExecutor`'s pool (core/max pool size, queue capacity) directly. Conceptually it prevents the step from flooding the executor's queue faster than workers can drain it. ## Ordering and restart caveats - **No ordering guarantee.** Chunks are processed concurrently, so items are read, written and committed out of order. Don't use it if downstream logic depends on input order. - **Restartability is weakened.** Spring Batch tracks progress by a single read-count in `BATCH_STEP_EXECUTION`. With concurrency, if the job fails mid-flight there can be gaps (chunk 5 committed but chunk 4 didn't), so re-running may reprocess or skip. For this reason multithreaded steps are best for **restart-from-scratch** / idempotent workloads, and `saveState(false)` is sometimes set on readers. - **Not fault-tolerant-friendly.** Combining with skip/retry and stateful readers multiplies the concurrency hazards. ## When to use vs alternatives Use a multithreaded step for a quick throughput win on **one JVM**, **I/O-bound** steps, where strict ordering and exact restart aren't required. When you need bounded data partitions, per-partition restartability, or to scale across JVMs, prefer **local/remote partitioning** (`Partitioner` + `PartitionHandler`) or **remote chunking**, which give each worker its own reader instance and avoid the shared-state problem entirely.