Spring Batch异常：未完成全量记录处理却触发afterStep方法

针对你遇到的单线程Step中afterStep提前触发（处理1条记录就执行）的问题，结合Spring Batch 3.0.7版本和你的配置，给出以下排查方向：

1. 修复Reader的拼写错误 #

你的HibernateCursorItemReader配置中有明显拼写错误：

reader.setUseSatelessSesion(true);

正确写法是setUseStatelessSession(true)。这个错误会导致Hibernate无法正确创建无状态会话，可能引发会话管理异常，进而导致Step的执行状态被错误标记为结束，触发afterStep，但Cursor并未关闭，后续继续读取处理第二条记录。

2. 检查Step配置是否缺失Chunk大小 #

你的Step配置代码中没有显式指定.chunk()大小，而Spring Batch的Chunk-oriented Step必须配置Chunk大小（未配置会导致初始化异常或执行逻辑混乱）。补充Chunk配置：

return stepBuilderFactory.get("myStep")
    .<MyObject, MyObject>chunk(2) // 根据业务需求设置合适的Chunk大小
    .reader(myStepReader)
    .processor(processor)
    .writer(writer)
    .listener(listener)
    .build();

未配置Chunk大小可能导致Step执行流程异常，触发监听器提前执行。

3. 排查afterStep方法内的逻辑 #

检查afterStep方法是否存在修改Step执行状态的代码：

• 是否调用了stepExecution.setTerminateOnly()强制终止Step？
• 是否设置了ExitStatus为COMPLETED或FAILED，导致Step被判定为结束？
  这些操作会让Spring Batch提前触发afterStep，但Cursor Reader可能因未关闭继续读取数据。

4. 开启DEBUG日志追踪执行流程 #

开启Spring Batch的DEBUG级别日志，重点关注以下内容：

• StepExecution的状态变化（何时被标记为STARTED/COMPLETED/FAILED）
• Chunk的读取、处理、写入流程
• afterStep方法的触发时机与Step状态的关联
  通过日志可以明确Step提前触发监听器的具体原因。

5. 确认监听器的注册范围 #

确保MyListenerClass仅通过.listener(listener)注册为Step级别监听器，未被误注册为Item级监听器（如processor.listener()或writer.listener()）。虽然你继承的是StepExecutionListenerSupport，但误注册仍可能引发流程异常。

内容的提问来源于stack exchange，提问作者pitagram