Spring Batch Parallelism: Multi-Threaded, Async, Partitioning

Spring Batch has four parallelism strategies, and the right one depends on where the bottleneck is.

Multi-threaded step:

• One step, multiple threads share reader/writer
• Reader must be thread-safe — wrap in SynchronizedItemStreamReader
• Restart semantics weaken — ExecutionContext position imprecise
• Use for I/O-bound steps where restart-order isn't critical

Parallel steps via split:

• Independent steps run concurrently using a TaskExecutor
• Each step has its own reader/writer — no thread-safety issues
• Each has independent restart state
• Use for genuinely independent workloads (loading reference tables in parallel)

Async processor/writer:

• AsyncItemProcessor wraps the processor in a Future on a thread pool
• AsyncItemWriter unwraps the futures and writes actual results
• Reader stays single-threaded — no thread-safety issues
• Use when the processor is I/O-bound (HTTP calls, external lookups)

Partitioning:

• Master step splits input via Partitioner into N slices
• Each slice runs as an independent worker step with its own reader/writer
• Local partitioning — workers in one JVM via TaskExecutor
• Remote partitioning — workers on separate JVMs via Kafka, AMQP, JMS messaging
• Worker step must be @StepScope to receive partition context via @Value("#{stepExecutionContext['x']}")
• Best scalability + restart semantics — failed partitions restart independently

Decision framework:

• Bottleneck in processor (per-item I/O) → async processor/writer
• Multiple independent workloads → parallel steps
• Huge dataset that splits naturally → partitioning
• Simple single-machine, restart not critical → multi-threaded
• None fit or small dataset → stay single-threaded; tune chunk size and writer choice first

Pitfalls to call out:

• Multi-threaded + non-thread-safe reader — corruption
• Partitioning + non-idempotent writer — duplicates on restart
• Oversized/undersized grid — framework overhead or idle workers
• Skewed partitioner — one worker does 90% of work; prefer hash for uniformity
• Writer contention on a single DB index — all partitions serialize on the same lock

In an interview I'd emphasize that you measure first, then pick the strategy. Multi-threaded step is rarely the right answer in 2026 — async or partitioning almost always beat it on both performance and correctness.