Spring Batch 5.2 中的新增功能
本节重点介绍 Spring Batch 5.2 中的主要更改。有关更改的完整列表，请参阅发行说明。
Spring Batch 5.2 包括以下功能：
依赖项升级
在此版本中，Spring 依赖项升级到以下版本：
-
Spring 框架 6.2.0
-
Spring 集成 6.4.0
-
Spring 数据 3.4.0
-
Spring 重试 2.0.10
-
Spring LDAP 3.2.8 版本
-
Spring AMQP 3.2.0
-
Spring Kafka 3.3.0 版本
-
千分尺 1.14.1
MongoDB 作业存储库支持
此版本引入了第一个由 MongoDB 支持的 NoSQL 作业存储库实现。 与关系作业存储库实现类似， Spring Batch 附带了一个脚本来创建 MongoDB 中必要的集合，以便保存和检索批量元数据。
此实现需要 MongoDB 版本 4 或更高版本，并且基于 Spring Data MongoDB。
为了使用此作业存储库，您需要做的就是定义一个MongoTemplate以及MongoTransactionManager新添加的MongoJobRepositoryFactoryBean:
@Bean
public JobRepository jobRepository(MongoTemplate mongoTemplate, MongoTransactionManager transactionManager) throws Exception {
MongoJobRepositoryFactoryBean jobRepositoryFactoryBean = new MongoJobRepositoryFactoryBean();
jobRepositoryFactoryBean.setMongoOperations(mongoTemplate);
jobRepositoryFactoryBean.setTransactionManager(transactionManager);
jobRepositoryFactoryBean.afterPropertiesSet();
return jobRepositoryFactoryBean.getObject();
}定义 MongoDB 作业存储库后，您可以将其作为常规作业存储库注入任何作业或步骤中。 您可以在 MongoDBJobRepositoryIntegrationTests 中找到完整的示例。
新的无资源作业存储库
在 v5 中，出于多种原因，删除了内存中基于 Map 的作业存储库实现。 Spring Batch 中唯一剩下的作业存储库实现是 JDBC 实现，它需要一个数据源。 虽然这适用于 H2 或 HSQLDB 等内存数据库，但需要数据源是一个强大的限制 对于我们社区的许多用户，他们过去使用基于 Map 的存储库，而没有任何额外的依赖项。
在此版本中，我们引入了JobRepository不以任何形式使用或存储批量元数据的实现
（甚至不在内存中）。它是一个 “NoOp” 实现，丢弃批处理元数据，不与任何资源交互
（因此得名 “resourceless job repository”，它以 “resourceless transaction manager” 命名）。
此实现适用于不需要可重启性且不涉及执行上下文的用例 以任何方式（例如通过执行上下文在步骤之间共享数据，或分区元数据所在的分区步骤 通过 execution context 在 Manager 和 worker 之间共享，等等）。
此实现适用于在自己的 JVM 中执行的一次性作业。它适用于事务步骤（配置了
一个DataSourceTransactionManager）以及非事务性步骤（配置了ResourcelessTransactionManager).
该实现不是线程安全的，不应在任何并发环境中使用。
Composite Item Reader 实现
与CompositeItemProcessor和CompositeItemWriter，我们引入了一个新的CompositeItemReader实现
，该 API 旨在从具有相同格式的多个源中按顺序读取数据。这在数据分布时非常有用
并编写自定义读取器不是一种选择。
一个CompositeItemReader与其他复合工件的工作方式类似，通过将读取作委托给常规 Item Reader
挨次。下面是一个快速示例，显示了一个复合读取器，该读取器从平面文件中读取 people 数据，然后从数据库表中读取 people：
@Bean
public FlatFileItemReader<Person> itemReader1() {
return new FlatFileItemReaderBuilder<Person>()
.name("personFileItemReader")
.resource(new FileSystemResource("persons.csv"))
.delimited()
.names("id", "name")
.targetType(Person.class)
.build();
}
@Bean
public JdbcCursorItemReader<Person> itemReader2() {
String sql = "select * from persons";
return new JdbcCursorItemReaderBuilder<Person>()
.name("personTableItemReader")
.dataSource(dataSource())
.sql(sql)
.beanRowMapper(Person.class)
.build();
}
@Bean
public CompositeItemReader<Person> itemReader() {
return new CompositeItemReader<>(Arrays.asList(itemReader1(), itemReader2()));
}java.util.function API 的新适配器
似FucntionItemProcessor它适应了java.util.function.Function对于项目处理器，此版本
为其他java.util.function接口，如Supplier,Consumer和Predicate.
新添加的适配器包括：SupplierItemReader,ConsumerItemWriter和PredicateFilteringItemProcessor.
关于这些新适配器的更多细节，请参考 org.springframework.batch.item.function 包。
具有阻止队列项目读取器和写入器的并发步骤
分阶段事件驱动架构 （SEDA） 是一种 强大的架构风格，可在队列连接的阶段中处理数据。此样式直接适用于数据 管道，并且由于能够将作业设计为一系列步骤，因此在 Spring Batch 中很容易实现。
这里唯一缺少的部分是如何从中间队列读取数据以及将数据写入中间队列。此版本引入了项目读取器
和 item writer 读取数据并将其写入BlockingQueue.有了这两个新类，人们可以设计第一步
，在队列中准备数据，第二个步骤使用来自同一队列的数据。这样，两个步骤可以同时运行
以无阻塞、事件驱动的方式高效处理数据。
JPA 项目读取器中的查询提示支持
在版本 5.1 之前，JPA 游标和分页项读取器不支持查询提示（如获取大小、超时等）。 用户需要提供自定义查询提供程序才能指定自定义提示。
在此版本中，JPA 读取器及其各自的生成器已更新为在定义要使用的 JPA 查询时接受查询提示。
JDBC 项读取器中的数据类支持
该版本在 JDBC 游标和分页项读取器的构建器中引入了一种新方法，允许用户指定DataClassRowMapper当项类型为数据类（Java 记录或 Kotlin 数据类）时。
名为dataRowMapper(TargetType.class)类似于beanRowMapper(TargetType.class)并设计
使行映射器的配置在常规类 （Java bean） 和数据类 （Java 记录） 之间保持一致。
RecursiveCollectionLineAggregator 中的可配置行分隔符
到目前为止，浏览器中的 line separator 属性RecursiveCollectionLineAggregator设置为 System 的行分隔符值。
虽然可以通过 System 属性更改值，但此配置样式与其他属性不一致
的批处理工件。
该版本在RecursiveCollectionLineAggregator，允许用户将自定义值
行分隔符，而无需使用 System 属性。
作业登记改进
在版本 5.1 中，更新了批处理基础结构 bean 的默认配置以自动填充作业注册表
通过定义JobRegistryBeanPostProcessorbean 中。在 Spring Framework 最近的更改之后
，这将BeanPostProcessorChecker，则与JobRegistryBeanPostProcessor是
登录到典型的 Spring Batch 应用程序。这些警告是由于JobRegistryBeanPostProcessor具有依赖项
更改为JobRegistrybean，不建议这样做，这可能会导致 bean 生命周期问题。
在此版本中，通过更改填充JobRegistry通过使用BeanPostProcessor使用SmartInitializingSingleton.这JobRegistryBeanPostProcessor现已弃用，取而代之的是新添加的JobRegistrySmartInitializingSingleton.