在批量处理链路中，XML并没有因为JSON的流行而完全退出历史舞台。很多银行、保险、政务系统的接口仍然以XML作为标准交换格式，一个文件里常常包含数万甚至数十万条结构化记录。Spring Batch处理这类文件时，最忌讳的就是用DOM解析器一次性把整个文档加载进内存，那样很容易触发OutOfMemoryError。正确的做法是使用基于StAX的流式读取和写入，让框架一条一条地处理<user>这样的片段，内存中始终只保留少量对象。Spring Batch提供了StaxEventItemReader和StaxEventItemWriter两个组件，专门解决这种场景下的配置和运行问题。
下面围绕一个用户数据批处理任务展开：从C:\batch\input\users.xml读取用户信息，经过简单的处理逻辑后写入C:\batch\output\users_out.xml。整个配置过程包含依赖准备、Reader与Writer的独立配置、Job与Step组装，以及针对XML解析异常的容错策略。
引入依赖并准备待绑定的模型类
Spring Batch的XML处理能力依赖于spring-oxm模块，它提供了JAXB和XStream等编组器的统一抽象。如果项目基于Spring Boot，只需要引入spring-boot-starter-batch，再手动加上spring-oxm以及对应的XML绑定实现即可。下面是一个典型的Maven依赖片段，其中jaxb-api用于提供JAXB注解，如果使用JDK 11及以上版本，还需要额外引入jaxb-runtime，因为标准JDK已经不再内置JAXB实现。
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-batch</artifactId>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-oxm</artifactId>
</dependency>
<dependency>
<groupId>javax.xml.bind</groupId>
<artifactId>jaxb-api</artifactId>
<version>2.3.1</version>
</dependency>
<dependency>
<groupId>org.glassfish.jaxb</groupId>
<artifactId>jaxb-runtime</artifactId>
<version>2.3.1</version>
</dependency>
模型类需要使用JAXB注解来标识根节点和字段映射关系。例如一个用户对象对应XML中的<user>元素，内部包含id、name和email三个子元素。这样做的好处是编组器可以直接根据注解完成对象与XML片段之间的转换，无需编写额外的转换代码。
import javax.xml.bind.annotation.XmlElement;
import javax.xml.bind.annotation.XmlRootElement;
@XmlRootElement(name = "user")
public class User {
private Long id;
private String name;
private String email;
@XmlElement(name = "id")
public Long getId() {
return id;
}
public void setId(Long id) {
this.id = id;
}
@XmlElement(name = "name")
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
@XmlElement(name = "email")
public String getEmail() {
return email;
}
public void setEmail(String email) {
this.email = email;
}
}
如果团队更习惯使用XStream，也可以把JAXB注解替换成XStream的别名配置。后面会专门比较这两种绑定方式在Spring Batch中的差异。
配置StaxEventItemReader与StaxEventItemWriter
StaxEventItemReader的核心思想是按照指定的片段根元素名称，把XML文件切分成一个个独立的事件流。每遇到一个<user>开始标签，就交给内部的Unmarshaller转换成User对象；处理完这个片段后继续读取下一个，不会回退到文件开头。配置时需要设置三个关键属性：资源路径、片段根元素名称以及Unmarshaller。资源路径既可以是classpath下的文件，也可以是文件系统中的绝对路径。如果使用文件系统路径，建议通过FileSystemResource指定，避免相对路径在部署环境中产生歧义。
@Bean
public StaxEventItemReader<User> xmlReader() {
StaxEventItemReader<User> reader = new StaxEventItemReader<>();
reader.setResource(new FileSystemResource("C:\\batch\\input\\users.xml"));
reader.setFragmentRootElementName("user");
Jaxb2Marshaller unmarshaller = new Jaxb2Marshaller();
unmarshaller.setClassesToBeBound(User.class);
reader.setUnmarshaller(unmarshaller);
return reader;
}
上面的代码中，setFragmentRootElementName方法的值必须与XML文件中实际出现的片段元素完全一致。如果XML根节点是<users>，内部包含多个<user>，那么这里应该传user而不是users。否则Reader无法识别片段边界，会在启动时抛出异常。Jaxb2Marshaller通过setClassesToBeBound告知JAXB需要处理哪些类，框架会自动扫描类上的注解。
写入端使用StaxEventItemWriter，它负责把处理后的对象再次序列化为XML片段，并按照指定顺序写入目标文件。配置项包括输出资源、根标签名称以及Marshaller。根标签名称通常与读取时的根节点保持一致，但也可以是新的名称。需要注意的是，Writer默认会在每次任务启动时检查目标文件是否已存在，如果存在且没有开启重启状态保存，可能会直接覆盖或追加，具体行为与saveState参数有关。
@Bean
public StaxEventItemWriter<User> xmlWriter() {
StaxEventItemWriter<User> writer = new StaxEventItemWriter<>();
writer.setResource(new FileSystemResource("C:\\batch\\output\\users_out.xml"));
writer.setRootTagName("users");
writer.setMarshaller(marshaller());
writer.setSaveState(true);
return writer;
}
@Bean
public Jaxb2Marshaller marshaller() {
Jaxb2Marshaller marshaller = new Jaxb2Marshaller();
marshaller.setClassesToBeBound(User.class);
return marshaller;
}
这里把Marshaller单独声明为一个Bean，是为了让Reader和Writer共用同一个配置实例。实际项目中，如果读取和写入的模型类不同，可以拆成两个不同的Marshaller。setSaveState(true)表示在重启任务时记录写入位置，但XML写入的状态保存粒度取决于底层输出流，并不像关系型数据库那样精确到某一条记录。对于小规模批处理，可以关闭该选项以简化重启逻辑。
另外，如果XML文件头包含编码声明或者命名空间，Reader和Writer通常都能自动处理。但要注意命名空间前缀不一致的问题，JAXB默认对命名空间敏感，如果源文件和目标文件的命名空间定义不同，可能会在转换时产生异常。此时可以通过自定义Unmarshaller的namespace映射来解决。
组装Job与Step并加入容错策略
有了Reader和Writer之后，需要把它们放入一个Step中，再由Job统一调度。Spring Batch的Java配置方式非常直观，通过StepBuilderFactory和JobBuilderFactory可以快速完成组装。下面的例子定义了一个chunk大小为50的步骤，也就是每读完50条记录才执行一次事务提交。这样既能控制事务边界，又能减少频繁的数据库或文件写入操作。
@Bean
public Step xmlStep(StepBuilderFactory stepBuilderFactory,
StaxEventItemReader<User> reader,
StaxEventItemWriter<User> writer) {
return stepBuilderFactory.get("xmlStep")
.<User, User>chunk(50)
.reader(reader)
.processor(new UserNameUpperCaseProcessor())
.writer(writer)
.faultTolerant()
.skip(Exception.class)
.skipLimit(10)
.build();
}
@Bean
public Job xmlJob(JobBuilderFactory jobBuilderFactory, Step xmlStep) {
return jobBuilderFactory.get("xmlJob")
.start(xmlStep)
.build();
}
上面配置中加入了faultTolerant和skip策略，允许最多跳过10条异常记录。对于XML文件来说，跳过异常需要特别小心。如果某一条<user>片段格式错误，StaxEventItemReader在解析该片段时抛出异常，Step会尝试跳过这条记录并继续读取下一个片段。但如果错误导致XML事件流错乱，后续的片段可能也无法正确解析，最终造成大量连续跳过。因此，skipLimit不宜设置得过大，同时在Processor中应该进行必要的字段校验，从源头减少异常发生的概率。
如果需要在发生跳过时记录详细日志，可以配置SkipListener。它能在每条记录被跳过后拿到异常对象和当前记录内容，方便后续排查。例如把解析失败的XML片段保存到单独的错误目录中，而不是直接丢弃，这样运维人员可以结合日志定位问题。
XStream替代方案与性能调优建议
除了JAXB，Spring Batch同样支持XStream作为编组器。XStream的优势在于配置灵活，不需要在模型类上添加注解，适合那些无法修改源码的DTO或者第三方类。使用XStream时，只需要把XStreamMarshaller注入到Reader和Writer中，并显式设置类别名。下面的配置展示了如何将User类映射为<user>元素。
@Bean
public XStreamMarshaller xStreamMarshaller() {
XStreamMarshaller marshaller = new XStreamMarshaller();
Map<String, Class<?>> aliases = new HashMap<>();
aliases.put("user", User.class);
marshaller.setAliases(aliases);
return marshaller;
}
XStream在解析复杂嵌套结构时表现不错，但它的默认安全策略在较新版本中比较严格，可能会拒绝解析未明确授权的类。如果XML中包含特殊类型，需要在setAliases之前配置允许的类列表，否则任务启动阶段就会报ForbiddenClassException。相比之下，JAXB更贴近Java EE标准，对命名空间和Schema校验的支持也更直接。选择哪种方案主要看项目原有的XML处理习惯。
性能方面，StAX本身就是内存友好的，但在实际调优时还要关注几个细节。首先是chunk大小的选择，过小会导致事务提交频繁、写入端频繁刷新；过大则会让单次事务持有过多对象，增加内存波动。通常50到200是一个比较合理的区间，具体数值需要通过压力测试确定。其次，如果目标XML文件体积很大，建议开启Writer的缓冲区优化，避免每条记录都触发底层文件系统的写操作。最后，文件编码要保持一致，推荐在Reader和Writer上显式设置UTF-8，防止Windows环境下默认编码导致中文乱码。
还有一个容易忽略的点：Spring Batch的任务元数据表也会影响XML批处理的稳定性。如果Job实例重复启动但参数没有变化，可能因为唯一约束冲突而直接失败。对于按日期生成输出文件的批处理，建议把日期作为Job参数传入，而不是写死在Writer的路径中。这样每次运行都会产生新的Job实例，重启逻辑也更容易管理。
综合来看，Spring Batch读写XML文件的关键在于理解StAX事件流的边界控制，以及编组器与资源路径的配合。把Reader和Writer配置清晰之后，剩下的Job组装和异常处理与普通批处理任务没有本质区别。只要控制好内存占用和事务粒度，XML格式在批量场景中依然可以稳定承担大规模数据交换的任务。
Spring BatchXML文件读写StaxEventItemReader修改时间：2026-10-04 08:25:44