Flussi Reader-Processor-Writer orientati ai chunk
Colleghi i componenti ItemReader, ItemProcessor e ItemWriter per un’elaborazione scalabile a chunk.
Flussi Reader-Processor-Writer orientati ai chunk è una lezione Spring Boot 4 Complete Guide gratuita su CoddyKit. Questa è la lezione 2 di 4. Puoi leggere la lezione completa qui gratuitamente — poi esercitati direttamente nel browser con un editor di codice integrato e un tutor IA disponibile 24/7. Fa parte del percorso di apprendimento Spring Boot 4 Complete Guide, e i tuoi progressi si sincronizzano tra il web e l'app CoddyKit. Il corso Spring Boot 4 Complete Guide include 4 lezioni in totale.
Parti di questa lezione non sono ancora state tradotte e vengono mostrate in inglese.
Why Chunk-Oriented Processing?
Spring Batch reads, processes, and writes data in chunks instead of one record at a time. A chunk is a configurable number of items (the commit-interval) handled inside a single transaction.
- Read N items one by one with an
ItemReader. - Process each item with an
ItemProcessor. - Write the whole batch of N at once with an
ItemWriter.
Writing in bulk and committing per chunk is what makes batch jobs scale to millions of rows without exhausting memory.
The Three Core Interfaces
Every chunk step is built from three single-method interfaces. Knowing their contracts is the foundation of the whole pattern.
ItemReader<I>→I read()returns the next item, ornullwhen the input is exhausted.ItemProcessor<I, O>→O process(I item)transforms an input into an output; returningnullfilters the item out.ItemWriter<O>→void write(Chunk<? extends O> chunk)persists the accumulated chunk.
public interface ItemReader<I> {
I read() throws Exception; // null = end of input
}
public interface ItemProcessor<I, O> {
O process(I item) throws Exception; // null = filter
}
public interface ItemWriter<O> {
void write(Chunk<? extends O> chunk) throws Exception;
}Defining a Domain Type
A chunk step flows typed data from reader to processor to writer. Let's model a simple input and output. The reader emits raw Customer records and the writer stores normalized ones.
Using a Java record keeps these immutable value types concise. This snippet is plain Java with no framework, so it runs standalone.
public class DomainDemo {
record Customer(String name, String email) {}
public static void main(String[] args) {
Customer c = new Customer(" Ada ", "ADA@MAIL.COM");
Customer normalized = new Customer(
c.name().trim(),
c.email().toLowerCase());
System.out.println(normalized);
}
}Building the ItemReader
For database input, JdbcCursorItemReader streams rows one at a time so memory stays flat. You give it a DataSource, a SQL query, and a RowMapper to turn each row into a domain object.
Spring Batch calls read() repeatedly until it returns null, advancing the cursor each time.
@Bean
public JdbcCursorItemReader<Customer> reader(DataSource dataSource) {
return new JdbcCursorItemReaderBuilder<Customer>()
.name("customerReader")
.dataSource(dataSource)
.sql("SELECT name, email FROM customers WHERE active = true")
.rowMapper((rs, rowNum) ->
new Customer(rs.getString("name"), rs.getString("email")))
.build();
}Building the ItemProcessor
The processor is where business logic lives: validation, enrichment, transformation, or filtering. Its input and output types may differ.
- Return a transformed object to pass it downstream.
- Return
nullto skip the item entirely — it never reaches the writer.
Keep processors stateless and idempotent so they behave correctly when chunks are retried.
@Bean
public ItemProcessor<Customer, Customer> processor() {
return customer -> {
if (customer.email() == null || !customer.email().contains("@")) {
return null; // filter invalid records out of the chunk
}
return new Customer(
customer.name().trim(),
customer.email().toLowerCase());
};
}Building the ItemWriter
The writer receives the whole processed chunk at once via a Chunk<O>. Writing in bulk — one batched INSERT per chunk instead of one per row — is the key performance win.
JdbcBatchItemWriter uses a parameterized SQL statement and a bean-property parameter source to map fields automatically.
@Bean
public JdbcBatchItemWriter<Customer> writer(DataSource dataSource) {
return new JdbcBatchItemWriterBuilder<Customer>()
.dataSource(dataSource)
.sql("INSERT INTO customers_clean (name, email) VALUES (:name, :email)")
.beanMapped()
.build();
}Wiring the Chunk Step
A Step ties the three components together. The generic types <Customer, Customer> declare the input and output of the chunk, and the integer is the commit-interval.
With a chunk size of 100, Spring Batch reads 100 items, processes each, then writes all survivors in one transaction before committing.
@Bean
public Step chunkStep(JobRepository jobRepository,
PlatformTransactionManager txManager,
ItemReader<Customer> reader,
ItemProcessor<Customer, Customer> processor,
ItemWriter<Customer> writer) {
return new StepBuilder("chunkStep", jobRepository)
.<Customer, Customer>chunk(100, txManager)
.reader(reader)
.processor(processor)
.writer(writer)
.build();
}Assembling the Job
A Job is an ordered set of steps. For a single chunk step, the job simply starts with it. Spring Boot auto-detects the Job bean and runs it on startup.
The JobRepository records execution metadata — status, read/write counts, and the last committed position — enabling restartability.
@Bean
public Job importCustomersJob(JobRepository jobRepository, Step chunkStep) {
return new JobBuilder("importCustomersJob", jobRepository)
.start(chunkStep)
.build();
}Choosing the Chunk Size
The commit-interval is a tuning lever, not a magic number.
- Too small (e.g. 1): one transaction per row — high commit overhead, slow.
- Too large (e.g. 100,000): bigger transactions, more memory and rollback cost if a chunk fails.
- Typical sweet spot: 100–1000, tuned by measuring throughput against your database and row size.
Remember: a failed item rolls back the entire chunk, so larger chunks mean more work redone on failure.
Fault Tolerance: Skip and Retry
Real input is messy. Wrap the step with .faultTolerant() to keep processing despite isolated failures.
.skip(...)— tolerate up toskipLimitbad items instead of failing the job..retry(...)— re-attempt transient errors (e.g. deadlocks) up toretryLimitbefore giving up.
On a skip or retry, Spring Batch re-scans the chunk item by item, isolating the offending record.
@Bean
public Step faultTolerantStep(JobRepository jobRepository,
PlatformTransactionManager txManager,
ItemReader<Customer> reader,
ItemProcessor<Customer, Customer> processor,
ItemWriter<Customer> writer) {
return new StepBuilder("ftStep", jobRepository)
.<Customer, Customer>chunk(100, txManager)
.reader(reader)
.processor(processor)
.writer(writer)
.faultTolerant()
.skip(FlatFileParseException.class)
.skipLimit(20)
.retry(DeadlockLoserDataAccessException.class)
.retryLimit(3)
.build();
}The Chunk Lifecycle in Order
Putting it together, each chunk follows the same loop inside one transaction:
- 1. Read: call
read()repeatedly until chunk-size items are buffered (ornullends input). - 2. Process: call
process()on each item; nulls are filtered out. - 3. Write: pass the surviving items as one
Chunktowrite(). - 4. Commit: commit the transaction and record progress in the
JobRepository.
Then the loop repeats for the next chunk until the reader is exhausted.
Quick Check
Test your understanding of the chunk pipeline.
Recap
You wired a complete chunk-oriented flow in Spring Batch:
- ItemReader streams input one item at a time, returning
nullat the end. - ItemProcessor transforms or filters items;
nulldrops an item. - ItemWriter persists the whole chunk in bulk for performance.
- The Step binds them with a
chunk(size, txManager)commit-interval, and the Job orchestrates the steps. - Tune chunk size for throughput, and add
.faultTolerant()with skip/retry for resilient pipelines.
This read-process-write loop, committed per chunk, is the backbone of scalable batch processing.
Domande Frequenti
La lezione «Flussi Reader-Processor-Writer orientati ai chunk» è gratuita?
Sì — il testo completo di «Flussi Reader-Processor-Writer orientati ai chunk» è gratuito qui sul web. Per esercitarvi in modo interattivo (un editor di codice integrato e un tutor IA 24/7) e sbloccare il resto del corso Spring Boot 4 Complete Guide, passa a CoddyKit PRO. Il corso Spring Boot 4 Complete Guide include 4 lezioni in totale.
Cosa imparerò in «Flussi Reader-Processor-Writer orientati ai chunk»?
Colleghi i componenti ItemReader, ItemProcessor e ItemWriter per un’elaborazione scalabile a chunk. Eserciti Spring Boot 4 Complete Guide con codice pratico che esegui direttamente nel browser, e un tutor IA 24/7 risponde alle tue domande mentre lavori sulla lezione.
Ho bisogno di esperienza per iniziare Spring Boot 4 Complete Guide?
Non è richiesta alcuna esperienza precedente. Spring Boot 4 Complete Guide su CoddyKit è strutturato per principianti e studenti avanzati, quindi puoi iniziare da qui o dall'inizio e procedere al tuo ritmo. Questa è la lezione 2 di 4.
Quanto tempo richiede la lezione «Flussi Reader-Processor-Writer orientati ai chunk»?
La maggior parte delle lezioni CoddyKit richiede circa 5–10 minuti. Ogni lezione è breve e interattiva, quindi fai progressi costanti e riprendi esattamente da dove hai lasciato su web e app.
Posso scrivere ed eseguire codice in questa lezione Spring Boot 4 Complete Guide?
Sì. Ogni lezione Spring Boot 4 Complete Guide include un editor di codice integrato, quindi scrivi ed esegui codice reale direttamente nel tuo browser e ricevi feedback istantaneo dall'IA — nessuna configurazione locale necessaria.
Tutte le lezioni di questo corso
- Job, step e modello JobRepository
- Flussi Reader-Processor-Writer orientati ai chunk
- Tolleranza ai guasti, skip e policy di retry
- Partizionamento ed esecuzione parallela degli step