本文详解如何在 spring batch 中配置 itemwriter，使其对每个处理项单独执行更新/插入操作并立即提交，避免重复处理失败重启后的已成功项。核心在于设置 chunk size=1，并合理选用 jdbcbatchitemwriter 或 repositoryitemwriter。
本文详解如何在 spring batch 中配置 itemwriter，使其对每个处理项单独执行更新/插入操作并立即提交，避免重复处理失败重启后的已成功项。核心在于设置 chunk size=1，并合理选用 jdbcbatchitemwriter 或 repositoryitemwriter。
在 Spring Batch 的标准设计中，ItemWriter
✅ 正确配置示例（Java Config）
@Bean
public Step processStep(JobRepository jobRepository, PlatformTransactionManager transactionManager) {
return Steps.get("processStep")
.jobRepository(jobRepository)
.transactionManager(transactionManager)
.<SourceItem, TargetEntity>chunk(1) // 关键：chunk size = 1
.reader(itemReader())
.processor(itemProcessor()) // 返回 null 跳过写入（自动过滤）
.writer(itemWriter())
.build();
}?️ Writer 选型建议
-
JdbcBatchItemWriter（推荐用于简单 SQL 场景）
即使 chunk size=1，它仍可复用 JDBC 批量 API，且无 JPA 开销。需手动编写 INSERT/UPDATE SQL：@Bean public ItemWriter<TargetEntity> itemWriter(DataSource dataSource) { JdbcBatchItemWriter<TargetEntity> writer = new JdbcBatchItemWriter<>(); writer.setDataSource(dataSource); writer.setSql("INSERT INTO target_table (id, name, status) VALUES (?, ?, ?) " + "ON DUPLICATE KEY UPDATE status = ?"); writer.setItemPreparedStatementSetter((item, ps) -> { ps.setLong(1, item.getId()); ps.setString(2, item.getName()); ps.setString(3, item.getStatus()); ps.setString(4, item.getStatus()); // for ON DUPLICATE UPDATE }); return writer; } -
RepositoryItemWriter（推荐用于领域逻辑复杂场景）
若需调用 Service 层方法（如关联校验、级联保存、事件发布），应封装业务逻辑至 Service，并在 Writer 中委托调用：@Bean public ItemWriter<TargetEntity> itemWriter(TargetService targetService) { RepositoryItemWriter<TargetEntity> writer = new RepositoryItemWriter<>(); writer.setRepository(targetRepository); // Spring Data JPA Repository // 或更灵活地：使用自定义 Writer 委托 Service return items -> { for (TargetEntity item : items) { targetService.upsertAndLog(item); // 包含事务内完整业务逻辑 } }; }
⚠️ 关键注意事项
- Processor 返回 null 自动跳过 Writer：Spring Batch 会过滤掉 null 项，确保仅处理有效数据，无需在 Writer 中做空值判断。
- 事务边界严格由 chunk size 控制：chunk(1) 意味着每个 write() 调用都在独立事务中执行，失败仅回滚当前项，不影响其他项。
- 避免在 Writer 中开启新事务：Writer 运行在 Step 的事务上下文中，自行 @Transactional 可能破坏事务传播行为，应统一由 Step 管理。
- 性能权衡：单条提交牺牲吞吐量换取强一致性。若数据量大且允许少量重复（通过幂等设计），可考虑增大 chunk size 并配合唯一约束/乐观锁。
综上，chunk(1) + RepositoryItemWriter（或自定义函数式 Writer）是最清晰、可维护性最高的方案——它既满足逐项提交的可靠性要求，又支持在 Service 层集中管控业务逻辑与数据一致性规则。
