正如 RowMapper 采用 ResultSet 等底层结构并返回 Object 一样，平面文件处理也需要相同的结构来将 String 行转换为 Object，如下接口定义所示：

其基本约定是，在给定当前行及其关联行号的情况下，mapper 应返回一个结果 domain 对象。这与 RowMapper 类似，因为每一行都与其行号相关联，就像 ResultSet 中的每一行都与其行号相关联一样。这样，行号就可以与生成的 domain 对象绑定，以便进行 id 比较或记录更多信息。然而，与 RowMapper 不同的是，LineMapper 给出的是原始行，如上文所述，这只能实现一半的目标。必须将该行标记化为一个 FieldSet，然后将其映射到一个对象（如本文档稍后所述）。

将一行输入转化为 FieldSet 的抽象是必要的，因为可能有多种格式的平面文件数据需要转换为 FieldSet。在 Spring Batch 中，这个接口就是 LineTokenizer：

LineTokenizer 的约定是这样的：给定一行输入（理论上，String 可以包含多行），返回一个代表该行的 FieldSet。然后，该 FieldSet 可以传递给 FieldSetMapper。Spring Batch 包含以下 LineTokenizer 实现：

FieldSetMapper 接口定义了一个方法 mapFieldSet，该方法接收一个 FieldSet 对象并将其内容映射到一个对象。该对象可以是自定义 DTO、domain 对象或数组，具体取决于 job 的需要。FieldSetMapper 与 LineTokenizer 结合使用，可将资源中的一行数据转换为所需类型的对象，如下接口定义所示：

使用的 pattern 与 JdbcTemplate 使用的 RowMapper 相同。

既然已经定义了读取平面文件的基本接口，那么显然需要三个基本步骤：

上述两个接口分别代表两项不同的任务：将行转换为 FieldSet 和将 FieldSet 映射到 domain 对象。由于 LineTokenizer 的输入与 LineMapper 的输入（一行）相匹配，而 FieldSetMapper 的输出与 LineMapper 的输出相匹配，因此我们提供了一个同时使用 LineTokenizer 和 FieldSetMapper 的默认实现。DefaultLineMapper 如下面的类定义所示，代表了大多数用户需要的行为：

上述功能是在默认实现中提供的，而不是内置于 reader 本身（如框架以前的版本），以便用户在控制解析过程时有更大的灵活性，尤其是在需要访问原始行的情况下。

下面的示例说明了如何通过实际 domain 场景读取平面文件。该批处理任务从以下文件读入足球运动员：

该文件的内容映射到以下 Player domain 对象：

要将 FieldSet 映射到 Player 对象，需要定义一个返回 player 的 FieldSetMapper，如下例所示：

然后，可以通过正确构造一个 FlatFileItemReader 并调用 read 来读取文件，如下例所示：

每次调用 read 方法都会从文件中的每一行返回一个新的 Player 对象。当读取到文件末尾时，将返回 null 值。

DelimitedLineTokenizer 和 FixedLengthTokenizer 都允许一个额外的功能，其功能类似于 JDBC ResultSet。字段名称可以注入到任何一种 LineTokenizer 实现中，以增加映射函数的可读性。首先，将平面文件中所有字段的列名注入 tokenizer，如下例所示：

FieldSetMapper 可以如下使用这些信息：

对许多人来说，编写特定的 FieldSetMapper 就像为 JdbcTemplate 编写特定的 RowMapper 一样麻烦。Spring Batch 提供了一个 FieldSetMapper，通过使用 JavaBean 规范将字段名与对象上的 setter 进行匹配，从而自动映射字段，从而简化了这一工作。

对于 FieldSet 中的每个条目，mapper 都会在 Player 对象的新实例上查找相应的 setter（因此需要 prototype scope），就像 Spring 容器查找与属性名称匹配的 setter 一样。对 FieldSet 中的每个可用字段进行映射，然后返回结果 Player 对象，无需代码。

到目前为止，我们只详细讨论了分隔文件。然而，它们只代表了文件读取的一半。许多使用平面文件的组织都使用固定长度格式。下面是一个固定长度文件的示例：

虽然这看起来像一个大字段，但实际上代表了 4 个不同的字段：

在配置 FixedLengthLineTokenizer 时，必须以范围的形式提供这些长度。

由于 FixedLengthLineTokenizer 使用了与上文讨论的 LineTokenizer 相同的接口，因此它返回的 FieldSet 与使用了分隔符的 FieldSet 相同。这样，在处理其输出时就可以使用相同的方法，例如使用 BeanWrapperFieldSetMapper。

到此为止，所有的文件读取示例都为了简单起见做了一个关键假设：文件中的所有记录都具有相同的格式。然而，情况并非总是如此。很常见的情况是，文件中的记录可能具有不同的格式，需要以不同的方式标记并映射到不同的对象。下面的文件摘录就说明了这一点：

在这个文件中，我们有三种类型的记录："USER"、"LINEA" 和 "LINEB"。 "USER" 行对应一个 User 对象。"LINEA" 和 "LINEB" 都对应 Line 对象，但 "LINEA" 比 "LINEB" 包含更多信息。

ItemReader 会单独读取每一行，但我们必须指定不同的 LineTokenizer 和 FieldSetMapper 对象，以便 ItemWriter 接收到正确的项目。PatternMatchingCompositeLineMapper 允许将 pattern 映射到 LineTokenizer 和 pattern 映射到 FieldSetMapper，从而简化了这一过程。

在本例中，"LINEA" 和 "LINEB" 分别拥有不同的 LineTokenizer 实例，但它们都使用相同的 FieldSetMapper。

PatternMatchingCompositeLineMapper 使用 PatternMatcher#match 方法为每一行选择正确的委托。PatternMatcher 允许使用两个具有特殊含义的通配符：问号（"?"）匹配的是一个字符，而星号（"*"）匹配的是零个或多个字符。请注意，在前面的配置中，所有模式都以星号结尾，因此它们实际上是行的前缀。无论配置顺序如何，PatternMatcher 总是尽可能匹配最特殊的模式。因此，如果 "LINE*" 和 "LINEA*" 都被列为模式，"LINEA" 将匹配模式 "LINEA*"，而 "LINEB" 将匹配模式 "LINE*"。此外，单个星号（"*"）可以作为默认值，匹配任何其他模式不匹配的行。

还有一个 PatternMatchingCompositeLineTokenizer 可单独用于 tokenizer。

平面文件中包含跨多行记录的情况也很常见。要处理这种情况，需要采用更复杂的策略。在 multiLineRecords 示例中可以找到这种常见模式的演示。

在很多情况下，tokenizer 一行可能会导致异常抛出。许多平面文件并不完美，包含格式不正确的记录。许多用户选择跳过这些错误行，同时记录问题、原始行和行号。这些日志随后可以手动或通过其他批处理 job 进行检查。因此，Spring Batch 提供了一个处理解析异常的异常层次结构： FlatFileParseException 和 FlatFileFormatException。FlatFileItemReader 在尝试读取文件时遇到任何错误，就会抛出 FlatFileParseException。FlatFileFormatException 由 LineTokenizer 接口的实现抛出，表示在 tokenizer 过程中遇到了更具体的错误。

正如 LineTokenizer 接口需要将一个 item 转换成 String 一样，文件写入也必须有一种方法将多个字段聚合成一个字符串，以便写入文件。在 Spring Batch 中，这就是 LineAggregator，如下接口定义所示：

LineAggregator 与 LineTokenizer 在逻辑上正好相反。LineTokenizer 接收一个 String 并返回一个 FieldSet，而 LineAggregator 接收一个 item 并返回一个 String。

既然已经定义了 LineAggregator 接口及其最基本的实现，即 PassThroughLineAggregator，那么就可以解释写入的基本流程了：

下面摘录的 FlatFileItemWriter 代码表达了这一点：

前面的示例可能对写入文件的最基本用途有用。但是，FlatFileItemWriter 的大多数用户都有一个需要写出的 domain 对象，因此，必须将其转换成一行。在文件读取中，需要如下操作：

文件写入的步骤与此类似，但正好相反：

由于框架无法知道需要写出对象中的哪些字段，因此必须编写一个 FieldExtractor 来完成将 item 转化为数组的任务，如下面的接口定义所示：

FieldExtractor 接口的实现应从所提供对象的字段中创建一个数组，然后可以在元素之间使用分隔符或作为固定宽度行的一部分写出。

最基本的平面文件格式是所有字段都用分隔符分隔。这可以使用 DelimitedLineAggregator 来实现。下面的示例写出了一个简单的 domain 对象，表示客户账户的贷记：

由于使用的是 domain 对象，因此必须提供 FieldExtractor 接口的实现以及要使用的分隔符。

在上一个示例中，本章前面介绍的 BeanWrapperFieldExtractor 用于将 CustomerCredit 中的 name 和 credit 字段转化为对象数组，然后在每个字段之间用逗号隔开。

也可以使用 FlatFileItemWriterBuilder.DelimitedBuilder 自动创建 BeanWrapperFieldExtractor 和 DelimitedLineAggregator，如下例所示：

分隔不是唯一的平面文件格式。许多人喜欢为每一列设定宽度，以便在字段之间划线，这通常被称为 "固定宽度"。Spring Batch 通过 FormatterLineAggregator 支持这种文件写入方式。

前面示例中的大部分内容都很熟悉。不过，format 属性的值是新的。

底层实现是使用作为 Java 5 一部分添加的 Formatter 构建的。Java Formatter 基于 C 语言的 printf 功能。有关如何配置 formatter 的详细信息，请参阅 Formatter 的 Javadoc。

也可以使用 FlatFileItemWriterBuilder.FormattedBuilder 自动创建 BeanWrapperFieldExtractor 和 FormatterLineAggregator，如下例所示：

FlatFileItemReader 与文件资源的关系非常简单。当 reader 初始化时，它会打开文件（如果存在的话），如果打不开则会抛出异常。文件写入就没那么简单了。乍一看，FlatFileItemWriter 似乎也应该有类似的直接约束： 如果文件已经存在，则抛出异常；如果不存在，则创建文件并开始写入。但是，重新启动 Job 可能会导致问题。在正常重启情况下，约束是相反的：如果文件存在，则从最后已知的良好位置开始写入，如果不存在，则抛出异常。但是，如果该任务的文件名总是相同，会发生什么情况呢？在这种情况下，如果文件存在，除非是重启，否则就应该删除。考虑到这种可能性，FlatFileItemWriter 包含了 shouldDeleteIfExists 属性。将此属性设置为 true 会导致在打开 writer 时删除同名的现有文件。

JdbcCursorItemReader 是基于游标技术的 JDBC 实现。它可直接与 ResultSet 一起使用，并要求针对从 DataSource 获取的连接运行 SQL 语句。以下面数据库 schema 为例：

许多人喜欢为每一行使用一个 domain 对象，因此下面的示例使用 RowMapper 接口的实现来映射 CustomerCredit 对象：

由于 JdbcCursorItemReader 与 JdbcTemplate 共享关键接口，因此我们有必要举例说明如何使用 JdbcTemplate 读取这些数据，以便与 ItemReader 进行对比。在本示例中，假设 CUSTOMER 数据库中有 1000 条记录。第一个示例使用 JdbcTemplate：

运行上述代码段后，customerCredits 列表中包含 1,000 个 CustomerCredit 对象。在 query 方法中，从 DataSource 获取连接，针对连接运行所提供的 SQL，并针对结果集中的每一行调用 mapRow 方法。这与下面示例中的 JdbcCursorItemReader 方法形成了鲜明对比：

运行上述代码段后，counter 等于 1,000。如果上面的代码将返回的 customerCredit 放入一个 list，结果将与 JdbcTemplate 示例完全相同。然而，ItemReader 的最大优势在于它允许对项目进行 "流式" 处理。只需调用一次 read 方法，ItemWriter 就能写出项目，然后通过 read 获取下一个项目。这样，项目读写就可以分 "块" 完成，并定期提交，这正是高性能批处理的精髓所在。此外，它还可以轻松配置，以便注入 Spring Batch Step。

就像普通 Spring 用户在决定是否使用 ORM 解决方案时会影响他们是否使用 JdbcTemplate 或 HibernateTemplate 一样，Spring Batch 用户也有同样的选择。HibernateCursorItemReader 是游标技术的 Hibernate 实现。在批处理中使用 Hibernate 一直颇具争议。这主要是因为 Hibernate 最初是为支持在线应用程序风格而开发的。但这并不意味着它不能用于批处理。解决这个问题的最简单方法是使用无状态会话（StatelessSession）而不是标准会话。这就去除了 Hibernate 采用的所有缓存和脏检查功能，而这些功能在批处理场景中可能会造成问题。有关无状态会话与普通 Hibernate 会话之间区别的更多信息，请参阅特定 Hibernate 版本的文档。HibernateCursorItemReader 可以让你声明一条 HQL 语句并传入一个 SessionFactory，它会以与 JdbcCursorItemReader 相同的基本方式，在每次调用读取时传回一个项目。以下示例配置使用了与 JDBC reader 相同的 'customer credit' 示例：

该配置的 ItemReader 返回 CustomerCredit 对象的方式与 JdbcCursorItemReader 所描述的方式完全相同，前提是已为 Customer 表正确创建了 hibernate 映射文件。使用无状态会话（useStatelessSession）属性的默认值为 true，但在此添加该属性是为了引起人们对开启或关闭该属性功能的注意。值得注意的是，底层游标的取值大小可以通过 setFetchSize 属性来设置。与 JdbcCursorItemReader 一样，配置也很简单。

有时需要使用存储过程来获取游标数据。StoredProcedureItemReader 的工作原理与 JdbcCursorItemReader 类似，只不过它不是运行查询来获取游标，而是运行一个存储过程来返回游标。存储过程可以通过三种不同方式返回游标：

前面的示例依赖于存储过程提供一个 ResultSet 作为返回结果（前面的选项 1）。

如果存储过程返回一个 ref-cursor（选项 2），那么我们就需要提供作为返回 ref-cursor 的 out 参数的位置。

如果游标是从存储函数中返回的（选项 3），我们需要将属性 "function" 设为 true。默认值为 false。

在所有这些情况下，我们都需要定义 RowMapper 以及 DataSource 和实际存储过程名称。

如果存储过程或函数需要参数，则必须使用 parameters 属性声明和设置参数。下面这个 Oracle 示例声明了三个参数。第一个是 out 参数，用于返回 ref-cursor，第二个和第三个是 in 参数，用于获取 INTEGER 类型的值。

除了参数声明外，我们还需要指定一个 PreparedStatementSetter 实现来设置调用的参数值。这与上述 JdbcCursorItemReader 的工作原理相同。其他属性 中列出的所有附加属性也适用于 StoredProcedureItemReader。

JdbcPagingItemReader 是分页 ItemReader 的一种实现。JdbcPagingItemReader 需要一个 PagingQueryProvider，负责提供用于分页的 SQL 查询。由于每个数据库都有自己的分页支持策略，因此我们需要为每种支持的数据库类型使用不同的 PagingQueryProvider。SqlPagingQueryProviderFactoryBean 也能自动检测正在使用的数据库，并确定合适的 PagingQueryProvider 实现。这简化了配置，是推荐的最佳做法。

SqlPagingQueryProviderFactoryBean 要求你指定一个 select 子句和一个 from 子句。你还可以提供一个可选的 where 子句。这些子句和所需的 sortKey 用于创建 SQL 语句。

reader 打开后，每次调用 read 都会传回一个 item，其基本方式与其他 ItemReader 相同。当需要额外的行时，就会在背后进行分页。

此配置的 ItemReader 使用必须指定的 RowMapper 返回 CustomerCredit 对象。'pageSize' 属性决定了每次查询运行时从数据库读取的实体数量。

parameterValues 属性可用于指定查询的参数值 Map 。如果在 where 子句中使用命名参数，则每个 entry 的 key 值应与命名参数的名称相匹配。如果使用传统的 '?' 占位符，则每个 entry 的 key 应为占位符的编号，从 1 开始。

分页 ItemReader 的另一种实现是 JpaPagingItemReader。JPA 没有类似于 Hibernate StatelessSession 的概念，因此我们必须使用 JPA 规范提供的其他功能。由于 JPA 支持分页，因此在使用 JPA 进行批处理时，这是一个自然的选择。在读取每个分页后，实体都会被分离，持久化上下文（persistence context）也会被清除，以便在分页处理完毕后对实体进行垃圾回收。

JpaPagingItemReader 可让你声明一个 JPQL 语句并传入一个 EntityManagerFactory。然后，它将每次调用传回一个 item，以与其他 ItemReader 相同的基本方式进行读取。当需要额外的实体时，分页会在幕后进行。

假设 CustomerCredit 对象具有正确的 JPA 注解或 ORM 映射文件，则此配置的 ItemReader 将以与上述 JdbcPagingItemReader 完全相同的方式返回 CustomerCredit 对象。pageSize 属性决定了每次执行查询时从数据库读取的实体数量。

最后一个挑战是让 ItemReader 可以重新启动。目前，如果处理中断并重新开始，ItemReader 必须从头开始。这其实在很多情况下都是有效的，但有时批处理 job 最好从中断的地方重新开始。关键的判别因素通常是 reader 是有状态的还是无状态的。无状态 reader 不需要担心可重启性，但有状态 reader 必须在重启时尝试重建其最后的已知状态。因此，我们建议尽可能保持自定义 reader 的无状态状态，这样就不必担心重启问题。

如果确实需要存储状态，则应使用 ItemStream 接口：

每次调用 ItemStream update 方法时，ItemReader 的当前索引都会以 'current.index' 为 key 存储在提供的 ExecutionContext 中。调用 ItemStream open 方法时，会检查 ExecutionContext 是否包含具有该 key 的条目。如果 key 被找到，当前索引就会被移动到该位置。这是一个相当琐碎的示例，但仍然符合一般的要求：

大多数 ItemReader 的重启逻辑要复杂得多。例如，JdbcCursorItemReader 会存储游标中最后处理行的行 ID。

还值得注意的是，ExecutionContext 中使用的 key 不应是琐碎的。这是因为一个 Step 中的所有 ItemStreams 都使用相同的 ExecutionContext。在大多数情况下，只需在 key 前加上类名就足以保证唯一性。但是，在极少数情况下，同一 step 中会使用两个相同类型的 ItemStream（如果需要输出两个文件，就会出现这种情况），这时就需要一个更唯一的名称。因此，许多 Spring Batch ItemReader 和 ItemWriter 实现都有一个 setName() 属性，允许重写 key 名。

要使 ItemWriter 可以重新启动，我们需要遵循与 ItemReader 相同的流程，添加并实现 ItemStream 接口，以同步执行上下文。在示例中，我们可能需要计算已处理 item 的数量，并将其添加为页脚记录。如果需要这样做，我们可以在 ItemWriter 中实现 ItemStream，这样在重新打开流时，计数器就会从执行上下文中重新生成。

在许多实际情况中，自定义 ItemWriter 还会委托给另一个 writer，而该 writer 本身是可重启的（例如，当写入文件时），或者写入事务性资源，因此不需要重启，因为它是无状态的。当你有一个有状态的 writer 时，你可能应该确保实现 ItemStream 以及 ItemWriter。还要记住，writer 的客户端需要知道 ItemStream，因此可能需要在配置中将其注册为 stream。

当使用非线程安全的 ItemReader 时，Spring Batch 提供了 SynchronizedItemStreamReader 装饰器，可用于使 ItemReader 成为线程安全的。Spring Batch 提供了一个 SynchronizedItemStreamReaderBuilder，用于构建 SynchronizedItemStreamReader 的实例。

例如，FlatFileItemReader 不是线程安全的，不能在多线程 step 中使用。这种 reader 可以用 SynchronizedItemStreamReader 来装饰，以便在多线程 step 中安全使用。下面是一个如何装饰这种 reader 的示例：

Spring Batch 包含一个装饰器，可为 ItemReader 添加一个 peek 方法。这方法可让用户提前“偷看”一个 item。重复调用该 peek 方法会返回相同的 item，这就是 read 方法返回的下一个 item。Spring Batch 提供了一个 SingleItemPeekableItemReaderBuilder，用于构建 SingleItemPeekableItemRea`der 的实例。

当使用非线程安全的 ItemWriter 时，Spring Batch 提供了 SynchronizedItemStreamWriter 装饰器，可用于使 ItemWriter 成为线程安全的。Spring Batch 提供了一个 SynchronizedItemStreamWriterBuilder，用于构建 SynchronizedItemStreamWriter 的实例。

例如，FlatFileItemWriter 不是线程安全的，不能在多线程 step 中使用。这种 writer 可以用 SynchronizedItemStreamWriter 来装饰，以便在多线程 step 中安全使用。下面是一个如何装饰这种 writer 的示例：

MultiResourceItemWriter 封装了一个 ResourceAwareItemWriterItemStream，并在当前资源中写入的 item 数超过 itemCountLimitPerResource 时创建一个新的输出资源。Spring Batch 提供了一个 MultiResourceItemWriterBuilder，用于构建 MultiResourceItemWriter 的实例。

ClassifierCompositeItemWriter 会根据通过提供的 Classifier 实现的路由器模式，为每个 item 调用一系列 ItemWriter 实现中的一个。如果所有委托（delegate）都是线程安全的，那么该实现就是线程安全的。Spring Batch 提供了一个 ClassifierCompositeItemWriterBuilder，用于构建 ClassifierCompositeItemWriter 的实例。

ClassifierCompositeItemProcessor 是一个 ItemProcessor，它根据通过提供的 Classifier 实现的路由器模式，调用一系列 ItemProcessor 实现中的一个。Spring Batch 提供了一个 ClassifierCompositeItemProcessorBuilder，用于构建 ClassifierCompositeItemProcessor 的实例。

AmqpItemReader 是使用 AmqpTemplate 从 exchange 接收或转换消息的 ItemReader。Spring Batch 提供了一个 AmqpItemReaderBuilder，用于构建 AmqpItemReader 的实例。

AmqpItemWriter 是一种使用 AmqpTemplate 向 AMQP exchange 发送消息的 ItemWriter。如果所提供的 AmqpTemplate 未指定名称，则消息会被发送到无名 exchange。Spring Batch 提供了一个 AmqpItemWriterBuilder，用于构建 AmqpItemWriter 的实例。

JmsItemReader 是使用 JmsTemplate 的 JMS ItemReader。该 template 应有一个默认 destination，用于为 read() 方法提供 item。Spring Batch 提供了一个 JmsItemReaderBuilder，用于构建 JmsItemReader 的实例。

JmsItemWriter 是使用 JmsTemplate 的 JMS ItemWriter。该 template 应有一个默认 destination，用于在 write(List) 中发送 item。Spring Batch 提供了一个 JmsItemWriterBuilder，用于构建 JmsItemWriter 的实例。

KafkaItemReader 是 Apache Kafka topic 的 ItemReader。它可以配置为从同一 topic 的多个分区读取消息。它在执行上下文中存储消息偏移量，以支持重启功能。Spring Batch 提供了一个 KafkaItemReaderBuilder，用于构建 KafkaItemReader 的实例。

KafkaItemWriter 是 Apache Kafka 的 ItemWriter，它使用 KafkaTemplate 向默认主题发送事件。Spring Batch 提供了一个 KafkaItemWriterBuilder 来构建 KafkaItemWriter 的实例。

Neo4jItemReader 是一个 ItemReader，它使用分页技术从图数据库 Neo4j 中读取对象。Spring Batch 提供了一个 Neo4jItemReaderBuilder，用于构建 Neo4jItemReader 的实例。

MongoItemReader 是一种通过分页技术从 MongoDB 读取文档的 ItemReader。Spring Batch 提供了一个 MongoItemReaderBuilder，用于构建 MongoItemReader 的实例。

HibernateCursorItemReader 是在 Hibernate 基础上构建的用于读取数据库记录的 ItemStreamReader。它执行 HQL 查询，然后在初始化后，在调用 read() 方法时遍历结果集，连续返回与当前行对应的对象。Spring Batch 提供了一个 HibernateCursorItemReaderBuilder，用于构建 HibernateCursorItemReader 的实例。

HibernatePagingItemReader 是一种 ItemReader，用于读取建立在 Hibernate 基础上的数据库记录，一次最多只能读取固定数量的 item。Spring Batch 提供了一个 HibernatePagingItemReaderBuilder，用于构建 HibernatePagingItemReader 的实例。

RepositoryItemReader 是通过使用 PagingAndSortingRepository 来读取记录的 ItemReader。Spring Batch 提供了一个 RepositoryItemReaderBuilder，用于构建 RepositoryItemReader 的实例。

Neo4jItemWriter 是向 Neo4j 数据库写入数据的 ItemWriter 实现。Spring Batch 提供了一个 Neo4jItemWriterBuilder，用于构建 Neo4jItemWriter 实例。

MongoItemWriter 是一个 ItemWriter 实现，它使用 Spring Data 的 MongoOperations 实现写入 MongoDB 存储。Spring Batch 提供了一个 MongoItemWriterBuilder，用于构建 MongoItemWriter 的实例。

RepositoryItemWriter 是 Spring Data CrudRepository 的 ItemWriter wrapper。Spring Batch 提供了一个 RepositoryItemWriterBuilder，用于构建 RepositoryItemWriter 的实例。

HibernateItemWriter 是一种 ItemWriter，它使用 Hibernate session 来保存或更新不属于当前 Hibernate session 的实体。Spring Batch 提供了一个 HibernateItemWriterBuilder，用于构建 HibernateItemWriter 的实例。

JdbcBatchItemWriter 是一个 ItemWriter，它使用 NamedParameterJdbcTemplate 的批处理功能，为所有提供的项目执行一批语句。Spring Batch 提供了一个 JdbcBatchItemWriterBuilder，用于构建 JdbcBatchItemWriter 的实例。

JpaItemWriter 是一个 ItemWriter，它使用 JPA EntityManagerFactory 来合并不属于 persistence context 的任何实体。Spring Batch 提供了一个 JpaItemWriterBuilder，用于构建 JpaItemWriter 的实例。

LdifReader 可从 Resource 中读取 LDIF（LDAP 数据交换格式）记录，对其进行解析，并为每次 read 返回一个 LdapAttribute 对象。Spring Batch 提供了一个 LdifReaderBuilder，用于构建 LdifReader 的实例。

MappingLdifReader 从 Resource 中读取 LDIF（LDAP 数据交换格式）记录，对其进行解析，然后将每条 LDIF 记录映射到 POJO（Plain Old Java 对象）。每次读取都会返回一个 POJO。Spring Batch 提供了一个 MappingLdifReaderBuilder，用于构建 MappingLdifReader 的实例。

AvroItemReader 可从 Resource 中读取序列化的 Avro 数据。每次读取都会返回一个由 Java 类或 Avro Schema 指定类型的实例。reader 可选择是否为嵌入 Avro schema 的输入进行配置。Spring Batch 提供了一个 AvroItemReaderBuilder，用于构建 AvroItemReader 的实例。

SimpleMailMessageItemWriter 是一个可以发送邮件信息的 ItemWriter。它将实际发送邮件的任务委托给 MailSender 实例。Spring Batch 提供了一个 SimpleMailMessageItemWriterBuilder，用于构建 SimpleMailMessageItemWriter 的实例。

AvroItemWrite 根据给定的类型或 Schema 将 Java 对象序列化为可写资源。可选择是否将 writer 配置为在输出中嵌入 Avro schema。Spring Batch 提供了一个 AvroItemWriterBuilder，用于构建 AvroItemWriter 的实例。

ScriptItemProcessor 是一个项目处理器（ItemProcessor），它将当前要处理的 item 传递给所提供的脚本，脚本的结果由处理器返回。Spring Batch 提供了一个 ScriptItemProcessorBuilder，用于构建 ScriptItemProcessor 的实例。