在Spring Batch分区中，PartitionHandler的 gridSize 与Partitioner返回的ExecutionContext的数量之间的关系有点令人困惑 . 例如，MultiResourcePartitioner声明它忽略了gridSize，但 Partitioner 文档没有解释何时/为什么这是可以接受的 .
例如，假设我有一个 taskExecutor ，我希望在不同的并行步骤中重复使用，并且我将其大小设置为20.如果我使用网格大小为5的TaskExecutorPartitionerHandler和返回任意数字的 MultiResourcePartitioner 分区（每个文件一个），并行性如何实际表现？
假设 MultiResourcePartitioner 为特定运行返回10个分区 . 这是否意味着它们中只有5个会一直执行，直到所有10个完成，并且20个线程中不会有超过5个线程用于此步骤？
如果是这种情况，何时/为什么在用自定义实现覆盖 Parititioner 时可以忽略'gridSize'参数？我认为如果在文档中描述这将有所帮助 .
如果不是这种情况，我该如何实现？也就是说，如何重新使用任务执行程序并单独定义可以为该步骤并行运行的分区数以及实际创建的分区数？
1 回答
这里有一些很好的问题，所以让我们逐个介绍它们：
TaskExecutorPartitionHandler将并发限制推迟到您提供的TaskExecutor. 因此，在您的示例中，PartitionHandler将使用最多20个线程，因为TaskExecutor允许 .当我们查看分区步骤时，有两个值得关注的组件：
Partitioner和PartitionHandler.Partitioner负责了解要分割的数据以及最佳方式 .PartitionHandler负责将该工作委托给从属执行 . 为了使PartitionHandler执行其委派，它需要了解它正在使用的"fabric"（本地线程，远程从属进程等） .在划分要处理的数据时（通过
Partitioner），了解有多少 Worker 可用是很有用的 . 但是，该指标不是't always very useful based on the data you'正在使用 . 例如，划分数据库行，将它们均匀地除以可用的工作者数量是有意义的 . 但是，它更容易为每个文件创建一个分区 . 这两种情况都取决于您试图划分的数据，以确定gridSize是否有用 .如果你正在重新使用
TaskExecutor，那么你可能无法做到TaskExecutor可能正在做其他事情 . 我想知道你为什么只在分区步骤运行时创建了'd re-use one given the relatively low overhead of creating one dedicated (you can even make it step scoped so it' .