常见问题解答
是否可以在多个线程或多个进程中执行作业？
有三种方法可以解决这个问题 - 但我们建议在分析这些需求时要谨慎（真的有必要吗？
-
添加
TaskExecutor到步骤中。为配置 Steps 提供的 'StepBuilder' 具有您可以设置的 “taskExecutor” 属性。只要该步骤本质上是可重新启动的（有效幂等），这就有效。并行作业示例显示了它在实践中的工作原理 - 它使用 “process indicator” 模式在业务事务中将输入记录标记为完成。 -
使用
PartitionStep在多个 Step 实例之间显式拆分 Step 执行。Spring Batch 具有 main 策略的本地多线程实现（PartitionHandler），这使其成为 IO 密集型作业的绝佳选择。记得使用scope="step"对于以这种方式执行的步骤中的有状态组件，以便每个步骤执行都会创建单独的实例，并且线程之间没有串扰。 -
使用 Remote Chunking 方法，如
spring-batch-integration模块。这需要一些持久的中间件（例如 JMS）来实现驾驶步骤和远程工作人员之间的可靠通信。基本思路是使用特殊的ItemWriter在驱动进程上，以及工作进程上的侦听器模式（通过ChunkProcessor).
如何确保项目读取器线程安全？
您可以将read()方法（例如，将其包装在执行同步的委托人中）。
请记住，您将失去可重启性，因此最佳做法是将步骤标记为不可重启，并且为了安全（和高效），您还可以设置saveState=false在阅读器上。
Spring Batch 关于使用灵活策略和默认实现的理念是什么？你能为这个或那个属性添加一个公共 getter 吗？
Spring Batch 中有许多扩展点供框架开发人员（而不是业务逻辑的实现者）使用。
我们希望客户端创建自己的更具体的策略，这些策略可以插入来控制诸如提交间隔 （CompletionPolicy),
有关如何处理异常 （ExceptionHandler） 等。
通常，我们试图劝阻用户扩展框架类。Java 语言没有给我们提供将类和接口标记为 internal 的灵活性。
通常，您可以在 packages 中源代码树的顶层期望任何内容org.springframework.batch.*是 public，但不一定是 subclassable。
不鼓励扩展大多数策略的具体实现，而支持组合或分叉方法。
如果你的代码只能使用 Spring Batch 中的接口，那可以为你提供最大的可移植性。
Spring Batch 与 Quartz 有何不同？在解决方案中，他们俩都有一席之地吗？
Spring Batch 和 Quartz 有不同的目标。Spring Batch 提供处理大量数据的功能，而 Quartz 提供调度任务的功能。
因此，Quartz 可以补充 Spring Batch，但不排除技术。一个常见的组合是使用 Cron 表达式将 Quartz 用作 Spring Batch 作业的触发器
和 Spring Core 的便利性SchedulerFactoryBean.
如何使用 Spring Batch 安排作业？
使用日程安排工具。他们有很多。示例：Quartz、Control-M、Autosys。
Quartz 不具备 Control-M 或 Autosys 的所有功能 - 它应该是轻量级的。
如果您想要更轻量级的东西，您可以只使用作系统 （cron,at等）。
简单的 Sequential 依赖关系可以使用 Spring Batch 的 job-steps 模型和 Spring Batch 中的非 Sequential 功能来实现。 我们认为这很常见。事实上，它使纠正调度器的常见误用变得更加容易 - 配置了数百个作业， 其中许多不是独立的，而只是相互依赖。
Spring Batch 如何允许项目优化性能和可扩展性（通过并行处理或其他）？
我们认为这是Job或Step.Step 的一个具体实现处理了分解业务逻辑的问题
并在并行进程或处理器之间有效共享它（请参阅PartitionStep).有许多技术可以在这里发挥作用。
实质上只是对可以处理某些业务处理的分布式代理的一组并发远程调用。
由于业务处理通常已经是模块化的 - 例如，输入一个项目，处理它 - Spring Batch 可以通过多种方式制定分发策略。
我们有一些经验的一种实现是一组处理业务处理的远程 Web 服务。
我们将输入的特定范围的主键发送到许多远程调用中的每一个。
相同的基本策略适用于任何 Spring Remoting 协议（普通 RMI、HttpInvoker、JMS、Hessian 等），只需更改几行即可
在 execution layer configuration 中。
如何使用消息传递来扩展批处理架构？
现有项目的大量实际证据表明，批处理的管道方法非常有益，可以带来弹性和高吞吐量。 我们经常面临任务关键型应用程序，其中审计跟踪是必不可少的，并且需要有保证的处理，但存在极其严格的限制 在负载下的性能上，或者在高吞吐量带来竞争优势的情况下。
Matt Welsh 的研究表明，与更严格的处理架构相比，分阶段事件驱动架构 （SEDA） 具有巨大的优势。
和面向消息的中间件（JMS、AQ、MQ、Tibco 等）为我们提供了许多开箱即用的弹性。有特别的好处
一个在下游和上游阶段之间存在反馈的系统，因此可以根据需求量调整消费者的数量。
那么，这如何适应 Spring Batch 呢？spring-batch-integration 项目在 Spring Integration 中实现了这个模式。
并可用于扩展需要处理许多项目的任何步骤的远程处理。
请特别参见 “chunk” 包，以及ItemWriter和ChunkHandlerimplementations 中。