Spring Batch实战：CSV文件处理中ItemReader与ItemWriter的五大配置陷阱与解决方案

当你第一次在Spring Batch中成功运行CSV文件读写示例时，那种成就感可能让你误以为已经掌握了这项技术。但现实往往会在实际项目中给你当头一棒——文件编码乱码、字段映射失败、性能低下等问题接踵而至。本文将揭示那些官方文档没有明确指出的配置陷阱，帮助开发者从"能运行"进阶到"懂得为何这样配置且能稳定运行"。

1. 资源路径配置：ClassPathResource与FileSystemResource的隐藏差异

许多开发者在使用FlatFileItemReader和FlatFileItemWriter时，往往对Resource接口的不同实现类选择不当，导致文件找不到或权限问题。以下是两种常见Resource实现的对比：

典型错误示例：

java复制// 反例：生产环境可能找不到文件
reader.setResource(new ClassPathResource("data/input.csv"));

// 反例：Windows绝对路径导致Linux部署失败
writer.setResource(new FileSystemResource("C:/output/output.csv"));

最佳实践方案：

1. 对于输入文件，使用Spring的ResourceLoader动态加载：

java复制@Autowired
private ResourceLoader resourceLoader;

public ItemReader<Item> reader(@Value("${input.file}") String filePath) {
    FlatFileItemReader<Item> reader = new FlatFileItemReader<>();
    reader.setResource(resourceLoader.getResource(filePath));
    // 其他配置...
}

2. 对于输出文件，采用环境感知的路径策略：

properties复制# application.properties
output.directory=/var/batch/output

java复制@Value("${output.directory}")
private String outputDir;

public ItemWriter<Item> writer(@Value("${output.filename}") String filename) {
    Path outputPath = Paths.get(outputDir, filename);
    writer.setResource(new FileSystemResource(outputPath));
    // 其他配置...
}

提示：在Kubernetes环境中，考虑使用ConfigMap挂载文件路径而非硬编码

2. 字段映射陷阱：setNames方法的三个常见误区

BeanWrapperFieldSetMapper的字段映射看似简单，实则暗藏玄机。以下是开发者最常踩的坑：

• 误区一：字段名大小写不匹配
  JavaBean属性通常采用驼峰命名法，而CSV文件头可能使用下划线。例如CSV中的"user_name"需要映射到JavaBean的"userName"

• 误区二：忽略字段顺序
  DelimitedLineTokenizer默认按照setNames设置的顺序解析字段，与CSV列顺序必须严格一致

• 误区三：未处理空值
  CSV中的空字符串可能导致NumberFormatException等解析错误

增强型配置示例：

java复制reader.setLineMapper(new DefaultLineMapper<Item>() {{
    setLineTokenizer(new DelimitedLineTokenizer() {{
        setNames("id", "full_name", "created_at"); // CSV列名
        setStrict(false); // 允许列数不匹配
    }});
    setFieldSetMapper(new BeanWrapperFieldSetMapper<Item>() {{
        setTargetType(Item.class);
        setDistanceLimit(2); // 允许模糊匹配字段名
        setCustomEditors(Collections.singletonMap(
            LocalDateTime.class, 
            new CustomDateEditor("yyyy-MM-dd HH:mm")
        )); // 自定义类型转换
    }});
}});

字段映射验证清单：

1. 在CSV文件头行和setNames值之间建立明确的对应关系
2. 对于日期/数值等特殊类型，注册自定义PropertyEditor
3. 使用BeanValidation注解验证字段值合法性
4. 考虑添加@JsonIgnoreProperties(ignoreUnknown=true)防止未知字段报错

3. 分隔符配置：超越逗号的复杂场景处理

虽然CSV通常指"逗号分隔值"，但实际业务中可能遇到各种分隔符场景：

• 制表符分隔文件(TSV)
• 固定宽度字段文件
• 带引号的多行字段
• 含分隔符的字段内容

高级分隔符配置技巧：

java复制// 处理带引号的CSV
DelimitedLineTokenizer tokenizer = new DelimitedLineTokenizer();
tokenizer.setDelimiter(",");
tokenizer.setQuoteCharacter('"');
tokenizer.setStrict(false);

// 处理固定宽度文件
FixedLengthTokenizer tokenizer = new FixedLengthTokenizer();
tokenizer.setColumns(new Range(1-10), new Range(11-20));
tokenizer.setNames("field1", "field2");

// 自定义复杂分隔符
PatternMatchingCompositeLineTokenizer tokenizer = 
    new PatternMatchingCompositeLineTokenizer();
tokenizer.setTokenizers(Map.of(
    "HEADER*", headerTokenizer,
    "*", defaultTokenizer
));

性能优化配置：

properties复制# 针对大文件处理的优化参数
spring.batch.chunk.size=1000
spring.batch.reader.buffer.size=8192
spring.batch.writer.transactional=false

4. 文件编码问题：从乱码到BOM头的全面解决方案

编码问题堪称CSV处理中的"幽灵问题"，常见症状包括：

• 中文字符显示为乱码
• 文件开头出现特殊字符(如BOM头)
• 换行符跨平台不一致

编码问题诊断表：

带编码处理的完整Reader配置：

java复制public FlatFileItemReader<Item> reader(Resource resource) throws Exception {
    BufferedReaderFactory bufferedReaderFactory = new DefaultBufferedReaderFactory();
    BufferedReader reader = bufferedReaderFactory.create(resource, "UTF-8");
    
    // 处理BOM头
    PushbackInputStream pushbackInputStream = 
        new PushbackInputStream(resource.getInputStream(), 3);
    byte[] bom = new byte[3];
    if (pushbackInputStream.read(bom) != -1) {
        if (!(bom[0] == (byte) 0xEF && bom[1] == (byte) 0xBB && bom[2] == (byte) 0xBF)) {
            pushbackInputStream.unread(bom);
        }
    }
    
    FlatFileItemReader<Item> itemReader = new FlatFileItemReader<>();
    itemReader.setResource(new InputStreamResource(pushbackInputStream));
    itemReader.setLinesToSkip(1); // 跳过标题行
    itemReader.setEncoding("UTF-8");
    // 其他配置...
    return itemReader;
}

5. 性能陷阱：大文件处理时的内存与事务优化

当处理GB级CSV文件时，以下配置不当会导致内存溢出或性能低下：

1. 未合理设置chunk size
   过大导致内存压力，过小导致事务开销过高

2. 未启用批处理模式
   JDBC Writer未使用批处理语句

3. 不必要的事务回滚
   单条记录失败导致整个chunk回滚

高性能Writer配置示例：

java复制@Bean
public JdbcBatchItemWriter<Item> writer(DataSource dataSource) {
    return new JdbcBatchItemWriterBuilder<Item>()
        .itemSqlParameterSourceProvider(new BeanPropertyItemSqlParameterSourceProvider<>())
        .sql("INSERT INTO items (id, name) VALUES (:id, :name)")
        .dataSource(dataSource)
        .assertUpdates(false) // 允许0行更新
        .itemPreparedStatementSetter(new ItemPreparedStatementSetter())
        .build();
}

// 配合以下事务配置
@Bean
public Step step(StepBuilderFactory stepBuilderFactory) {
    return stepBuilderFactory.get("step")
        .<Input, Output>chunk(1000)
        .reader(reader())
        .processor(processor())
        .writer(writer())
        .faultTolerant()
        .skipLimit(1000)
        .skip(Exception.class)
        .noRetry(Exception.class)
        .transactionAttribute(new DefaultTransactionAttribute(
            Propagation.REQUIRED.value(),
            Collections.singletonList(
                new RetryRuleExceptionClassifierBuilder()
                    .retryOn(DeadlockLoserDataAccessException.class)
                    .build()
            )
        ))
        .build();
}

性能监控建议：

java复制// 添加性能监控拦截器
@Bean
public StepExecutionListener performanceMonitor() {
    return new StepExecutionListener() {
        private long startTime;
        
        @Override
        public void beforeStep(StepExecution stepExecution) {
            startTime = System.currentTimeMillis();
        }
        
        @Override
        public ExitStatus afterStep(StepExecution stepExecution) {
            long duration = System.currentTimeMillis() - startTime;
            log.info("Step {} completed in {} ms", 
                stepExecution.getStepName(), duration);
            return null;
        }
    };
}

在最近的一个电商订单处理项目中，我们遇到了一个典型场景：需要每日处理包含百万级订单的CSV文件。最初版本处理一个文件需要2小时，经过上述优化后，时间缩短到15分钟。关键优化点包括：将chunk size从100调整为5000、使用批处理JDBC写入、跳过错单而非整个chunk回滚。