本节展示了 Spring Batch 5 的主要亮点。更多细节，请参考 迁移指南。

Spring Batch 5.0 中的新内容

本站（ springdoc.cn ）中的内容来源于 spring.io ，原始版权归属于 spring.io。由 springdoc.cn 进行翻译，整理。可供个人学习、研究，未经许可，不得进行任何转载、商用或与之相关的行为。 商标声明：Spring 是 Pivotal Software, Inc. 在美国以及其他国家的商标。

Spring Batch 5.0 有以下主要主题：

  • 需要 Java 17

  • 主要依赖的升级

  • 批处理的基础设施配置更新

  • 批处理测试配置更新

  • Job参数处理更新

  • Execution context 序列化更新

  • SystemCommandTasklet 更新

  • 新特性

  • 修剪

需要 Java 17

Spring Batch 在 Java 版本和第三方依赖方面都遵循Spring Framework的基线。随着Spring Batch 5的推出，Spring Framework版本将升级到Spring Framework 6，这需要Java 17。因此，Spring Batch的Java版本要求也将增加到Java 17。

主要依赖的升级

为了继续与Spring Batch使用的第三方库的支持版本进行整合，Spring Batch 5 正在将依赖全面更新为以下版本：

  • Spring Framework 6

  • Spring Integration 6

  • Spring Data 3

  • Spring AMQP 3

  • Spring for Apache Kafka 3

  • Micrometer 1.10

这个版本也标志着迁移到了：

  • Jakarta EE 9

  • Hibernate 6

批处理基础设施配置更新

Spring Batch 5包括以下基础设施配置更新：

数据源和事务管理器

历史上，Spring Batch提供了一个基 于 map 的 job repository 和 job explorer 的实现，以便与内存中的 job repository 一起工作。这些实现在版本4中被弃用，在版本5中被完全删除。推荐的替代方案是使用基于JDBC的实现，并使用嵌入式数据库，如H2、HSQL和其他。

在这个版本中，@EnableBatchProcessing 注解配置了一个基于 JDBC 的 JobRepository，这需要在应用上下文中定义一个 DataSource 和 PlatformTransactionManager Bean。DataSource Bean 可以引用一个嵌入式数据库来与内存中的 job repository 一起工作。

事务管理器 Bean 的暴露

直到4.3版本，@EnableBatchProcessing 注解在应用程序上下文中暴露了一个事务管理器bean。虽然这在许多情况下很方便，但无条件地暴露事务管理器会干扰用户定义的事务管理器。在这个版本中，@EnableBatchProcessing 不再在应用程序上下文中暴露一个事务管理器Bean。

EnableBatchProcessing 中新增的注解属性

在这个版本中，@EnableBatchProcessing 注解提供了新的属性，以指定哪些组件和参数应被用于配置批处理基础结构 bean。例如，现在可以指定Spring Batch应在 job repository 中配置哪些数据源和事务管理器，具体如下：

@Configuration
@EnableBatchProcessing(dataSourceRef = "batchDataSource", transactionManagerRef = "batchTransactionManager")
public class MyJobConfiguration {

	@Bean
	public Job job(JobRepository jobRepository) {
		return new JobBuilder("myJob", jobRepository)
				//define job flow as needed
				.build();
	}

}

在这个例子中，batchDataSource 和 batchTransactionManager 指的是应用程序上下文中的 bean，它们将被用来配置 job repository 和 job explorer。没有必要再定义一个自定义的 BatchConfigurer，在这个版本中已经删除。

基础设施bean的新配置类

在这个版本中，一个名为 DefaultBatchConfiguration 的新配置类可以被用来替代使用 @EnableBatchProcessing 来配置基础设施Bean。这个类为基础设施Bean提供了默认配置，可以根据需要进行定制。下面的片段显示了这个类的典型用法：

@Configuration
class MyJobConfiguration extends DefaultBatchConfiguration {

	@Bean
	public Job job(JobRepository jobRepository) {
		return new JobBuilder("myJob", jobRepository)
				//define job flow as needed
				.build();
	}

}

在这个例子中，注入 Job bean 定义中的 JobRepository bean被定义在 DefaultBatchConfiguration 类中。自定义参数可以通过覆盖相应的 getter 来指定。例如，下面的例子显示了如何覆盖 job repository 和 job explorer 中使用的默认字符编码：

@Configuration
class MyJobConfiguration extends DefaultBatchConfiguration {

	@Bean
	public Job job(JobRepository jobRepository) {
		return new JobBuilder("job", jobRepository)
				// define job flow as needed
				.build();
	}

	@Override
	protected Charset getCharset() {
		return StandardCharsets.ISO_8859_1;
	}
}

Job 参数处理的更新

支持任何类型作为 job 参数

这个版本增加了对使用任何类型作为 job 参数的支持，而不是像第四版那样只有4种预定义的类型（long、double、string、date）。 这一变化对工作参数在数据库中的持久化有影响（不再有每种预定义类型的4个不同列）。请检查 BATCH_JOB_EXECUTION_PARAMS 中的列变化，了解DDL变化。现在，参数类型的全称是字符串，以及参数值被保存为 String。字符串被转换为标准 Spring 转换服务（conversion service）的参数类型。标准的转换服务可以用任何需要的 convert 来丰富，以将用户的特定类型转换为字符串。

默认的 job 参数转换

v4中 job 参数的默认符号被指定为如下：

[+|-]parameterName(parameterType)=value

其中 parameterType 是 [string,long,double,date] 之一。这种符号有局限性，有约束性，不能很好地使用环境变量，对Spring Boot也不友好。

在v5中，有两种方法来指定 job 参数：

默认符号

现在默认的符号指定如下：

parameterName=parameterValue,parameterType,identificationFlag

其中 parameterType 是参数类型的完全名称。Spring Batch 提供了 DefaultJobParametersConverter 来支持这种符号。

扩展符号

虽然默认符号很适合大多数使用情况，但当值包含逗号时，可能就不太方便了，例如。在这种情况下，可以使用扩展符号，其灵感来自于 Spring Boot 的 Json Application Properties，其指定方式如下：

parameterName='{"value": "parameterValue", "type":"parameterType", "identifying": "booleanValue"}'

其中 parameterType 是参数类型的完全名称。Spring Batch 提供了 JsonJobParametersConverter 来支持这种符号。

Execution context 序列化的更新

从v5开始，DefaultExecutionContextSerializer 被更新为将上下文 序列化为Base64，以及从 Base64 反序列化。

此外，由 @EnableBatchProcessing 或 DefaultBatchConfiguration 配置的默认 ExecutionContextSerializer 已从 JacksonExecutionContextStringSerializer 改为 DefaultExecutionContextSerializer。对Jackson的依赖是可选的。为了使用 JacksonExecutionContextStringSerializer，应该在classpath中添加 jackson-core。

SystemCommandTasklet 更新

在这个版本中，SystemCommandTasklet 被重新审视，并做了如下修改：

  • 引入了一个名为 CommandRunner 的新策略接口，以便将命令的执行与小任务的执行解耦。默认实现是 JvmCommandRunner，它使用 java.lang.Runtime#exec API来运行系统命令。这个接口可以被实现为使用任何其他API来运行系统命令。

  • 运行命令的方法现在接受一个代表命令及其参数的 String 数组。不再需要对命令进行标记，也不需要做任何预处理。这一变化使API更加直观，而且不容易出错。

批处理测试配置的更新

Spring Batch 5 包括以下测试配置更新：

从测试设施中移除自动注入

直到4.3版本，JobLauncherTestUtils 和 JobRepositoryTestUtils 用来自动注入被测 job 和测试数据源，以方便测试基础设置。虽然这对大多数用例来说是很方便的，但对于定义了多个 job 或多个数据源的测试环境来说，它被证明会引起一些问题。

在这个版本中，我们引入了一些变化，以移除这种依赖关系的自动注入，以避免在手动或通过 @SpringBatchTest 注解导入这些工具时出现任何问题。

迁移到 JUnit Jupiter

在这个版本中，Spring Batch 的整个测试套件已经迁移到了JUnit 5。虽然这并不直接影响最终用户，但它有助于Batch团队以及社区贡献者使用下一代的JUnit来编写更好的测试。

新特性

JobExplorer 和 JobOperator 中的事务支持

这个版本在通过 JobExplorerFactoryBean 创建的 JobExplorer 中引入了事务支持。现在，在查询批处理元数据时，可以指定使用哪个事务管理器来驱动只读事务，以及自定义事务属性。

同样的事务支持通过一个名为 JobOperatorFactoryBean 的新工厂 bean 被添加到 JobOperator 中。

用 EnableBatchProcessing 自动注册一个 JobOperator

从第4版开始，EnableBatchProcessing 注解提供了启动 Spring Batch job 所需的所有基本基础设施Bean。然而，它并没有注册一个 job operator bean，这是停止、重新启动和放弃 job 执行的主要入口。

虽然这些工具不像启动 job 那样经常使用，但在 application context 中自动添加 job operator，可以避免终端用户手动配置这种 bean。

改进对 Java Record 的支持

对 Java Record 作为面向块的 step 中的项目的支持最初是在v4.3中引入的，但由于v4以Java 8为基线，这种支持很有限。最初的支持是基于反射技巧来创建 Java Record 并将数据填充到其中，而无法访问在Java 16中最终确定的 java.lang.Record API。

现在 v5 以 Java 17 为基准，我们通过在框架的不同部分利用 Record API来改进 Spring Batch 中的 Record 支持。例如，FlatFileItemReaderBuilder 现在能够检测 item 类型是 record 还是普通类，并相应地配置相应的 FieldSetMapper 实现（即 record 的 RecordFieldSetMapper 和普通类的 BeanWrapperFieldSetMapper）。这里的目标是使所需 FieldSetMapper 类型的配置对用户透明。

用 Micrometer 进行 Batch trace

随着 Micrometer 1.10 的升级，除了批处理指标，你现在还可以获得批处理 trace。Spring Batch 将为每个 job 创建一个 span，为一个 job 中的每个 step 创建一个span。这种 trace 元数据可以被收集起来，并在 Zipkin 等仪表盘上查看。

此外，这个版本还引入了新的指标，如当前的活动 step，以及通过所提供的 JobLauncher 的 job 启动计数。

Java 8 的功能更新

我们利用这个重要版本的机会，用Java 8+的功能来改进代码库，例如：

  • 在接口中使用默认方法，废除 "support" 类（见 issue 3924）。

  • 在 public API 中适当添加 @FunctionalInterface（见 issue 4107）。

  • 增加对使用 Date 和 Time API 的类型作为 job 参数的支持。(见 issue 1035)

支持 SAP HANA 的 job repository

这个版本引入了对 SAP HANA 的支持，作为 job repository 的额外支持数据库。

完全支持 MariaDB 作为一个独立的产品

直到 v4.3，Spring Batch 为 MariaDB 提供支持，将其视为 MySQL。在这个版本中，MariaDB 被视为一个独立的产品，有自己的 DDL 脚本和 DataFieldMaxValueIncrementer。

用于 Spring Batch 模块的新 Maven 物料清单

这个功能已经被要求了好几次，终于在v5中发布了。 现在可以使用新增加的 Maven BOM 来导入具有一致版本号的Spring Batch模块。

默认为UTF-8

多年来，在框架的不同领域都报告了一些与字符编码有关的问题，如基于文件的 item reader 和 writer 之间的默认编码不一致，在执行环境中处理多字节字符时的序列化/反序列化问题，等等。

本着与 JEP 400 相同的精神，并遵循 UTF-8 manifesto，该版本将框架的所有区域的默认编码更新为UTF-8，并确保该默认编码可根据需要进行配置。

完全支持GraalVM native

我们从 v4.2 开始努力提供支持，使用 GraalVM 原生镜像编译器将 Spring Batch 应用程序编译为本地可执行文件，并在v4.3中作为实验性文件交付。

在这个版本中，通过提供必要的 runtime hint，native 支持得到了极大的改善，可以用 GraalVM native 编译 Spring Batch 应用程序，现在被认为已经脱离了测试阶段。

Execution context 元数据的改进

除了 Spring Batch 已经在运行时信息（如 step 类型、重启标志等）方面保存的内容外，该版本在执 execution context 中增加了一个重要的细节，即用来序列化上下文的 Spring Batch 版本。

虽然这似乎是一个细节，但在调试 execution context 序列化和反序列化方面的升级问题时，它具有巨大的附加价值。

改进文档

在这个版本中，文档被更新为使用 Spring Asciidoctor 后端。这个后端确保所有项目都遵循相同的文档风格。为了与其他项目保持一致，在这个版本中，Spring Batch 的参考文档也更新为使用这个后端。

修剪

Spring Batch 5 删除了一些不再需要的项目，包括：

API的废弃和删除

在这个主要版本中，所有在以前的版本中被废弃的API都已经被删除。此外，一些API在v5.0中已经被废弃，并计划在v5.2中删除。最后，由于实际原因，一些API被转移或删除，但没有被废弃。

关于这些变化的更多细节，请参考 迁移指南。

移除 SQLFire 的支持

SqlFire 已经被宣布从2014年11月1日起停止使用。对 SQLFire 作为 job repository 的支持在v4.3版本中被废弃，在v5.0版本中被移除。

移除 GemFire 的支持

基于 Spring Data 停止对 Apache Geode 的支持 的决定，Spring Batch中对Geode的支持被移除。这些代码被转移到 spring-batch-extensions repository，作为社区驱动的努力。

移除 JSR-352 的实现

由于没有被采用，在这个版本中已经停止了对 JSR-352 实现的支持。