Spring Batch的chunk属性预期行为是什么？不同消息队列表现为何不同

云原生阿岚

2026-10-8

问题结论与原理说明

Spring Batch Chunk机制核心设计

Spring Batch的chunk配置的是单批次最大处理条目数，而非最小凑单阈值，核心执行逻辑如下：

循环调用ItemReader的read()方法读取单条数据
累计读取到的条目数达到chunk配置值时，触发一次Processor批量处理、Writer批量写入
若read()方法返回null（表示当前数据源已无更多可用数据），只要当前累计读取到的条目数>0，不管有没有达到chunk阈值，都会直接触发当前批次的Processor和Writer执行，不会等待凑满。

两种消息队列表现差异的原因

两种行为都符合Spring Batch的核心设计，差异来自不同ItemReader实现的策略不同：

RabbitMQ AmqpItemReader默认行为：当队列中没有可用消息时，read()方法会立刻返回null，不会阻塞等待后续消息。所以队列中只有1条消息时，Reader读完1条后下一次调用直接返回null，触发不满10条的批次提交，因此Processor和Writer可以正常执行。
你使用的Step配置如下：

Step employersStep = stepBuilderFactory.get("employersStep")
        .<Employer, EmployerEntity>chunk(10)
        .reader(amqpReader())
        .processor(processor)
        .writer(entityWriter)
        .build();

Kafka KafkaItemReader默认行为：默认采用阻塞等待策略，调用poll()拉取消息时如果没有新消息，不会立刻返回null，而是会持续等待新消息达到配置的超时时间后，才会判定为数据源耗尽返回null。默认超时时间较长，因此当topic中消息数少于chunk配置的10条时，Reader还在等待新消息，不会触发未满批次的提交，表现为只有消息数≥10时才会执行Processor和Writer。