Spring 6与Spring Batch 5迁移后@Autowired注入失效问题求助

问题背景 #

从Spring 5+Spring Batch 4迁移到Spring 6+Spring Batch 5后，部分@Autowired注入失效。具体场景是构建Step时无法注入ItemProcessor：

Step定义代码 #

@Bean
public Step fileBrowseMultiThreadStep(JobRepository jobRepository,
  PlatformTransactionManager transactionManager, 
  ItemProcessor<? super ApiDTO, ? extends ApiDTO> itemProcessorSelector) {
     return new StepBuilder("File read and save in database", jobRepository)
             .chunk(chunkSize, transactionManager)
             .reader(...)
             .processor(itemProcessorSelector)
             .writer(...)
             .build();
}

启动时错误 #

Error creating bean with name 'fileBrowseMultiThreadStep' defined in class path resource [...BatchConfiguration.class]: Unsatisfied dependency expressed through method 'fileBrowseMultiThreadStep' parameter 3: No qualifying bean of type 'org.springframework.batch.item.ItemProcessor<fr.test.dto.ApiDTO, fr.test.dto.ApiDTO>' available: expected at least 1 bean which qualifies as autowire candidate. Dependency annotations: {}

相关Bean定义 #

StepScope的Processor选择器：

@Bean
@StepScope
public ItemProcessor<? extends ApiDTO, ? extends ApiDTO> itemProcessorSelector(
  JobBeanProvider jobBeanProviderForThisJob) {
   return jobBeanProviderForThisJob.itemProcessor();
}

JobBeanProvider接口方法：

ItemProcessor<? extends ApiDTO, ? extends ApiDTO> itemProcessor();

矛盾点 #

• Step方法参数要求ItemProcessor<? super ApiDTO, ? extends ApiDTO>（匹配Spring Batch的processor方法参数类型）
• JobBeanProvider的实现返回ItemProcessor<ActivityApiDTO, ActivityApiDTO>（ActivityApiDTO是ApiDTO的子类），若修改接口方法为ItemProcessor<? super ApiDTO, ? extends ApiDTO>，实现类会编译失败（因为ActivityApiDTO不是ApiDTO的父类，不满足super通配符要求）

原因分析 #

Spring 6对泛型类型的匹配规则做了严格升级，相比Spring 5的宽松匹配，现在会严格遵循Java泛型的协变/逆变规则：

• ItemProcessor<? extends ApiDTO, ? extends ApiDTO>表示输入是ApiDTO的子类，而Step要求的? super ApiDTO表示输入可以是ApiDTO或其父类，两者的输入类型通配符不兼容，导致Spring无法找到匹配的Bean进行注入。

解决方案 #

方案1：显式类型转换（已验证可行） #

直接在Step的processor调用处做类型转换，绕过泛型检查：

.processor((ItemProcessor<? super ApiDTO, ? extends ApiDTO>) itemProcessorSelector)

该方法已通过编译并正常启动，需重点验证业务逻辑是否正常——确保实际返回的ActivityApiDTO处理器能兼容ApiDTO类型的输入（若业务中Step的Reader确实返回ActivityApiDTO或其子类，类型转换是安全的）。

方案2：调整Processor的泛型声明兼容输入类型 #

如果业务允许，可让实现类的Processor直接支持ApiDTO类型的输入：

// 实现类的Processor声明
public class ActivityProcessor implements ItemProcessor<ApiDTO, ActivityApiDTO> {
    @Override
    public ActivityApiDTO process(ApiDTO item) throws Exception {
        // 若item是ActivityApiDTO类型则处理，否则抛出异常或兼容处理
        if (item instanceof ActivityApiDTO activityItem) {
            // 业务逻辑
            return activityItem;
        }
        throw new IllegalArgumentException("Unsupported item type");
    }
}

之后修改JobBeanProvider的方法返回类型为ItemProcessor<ApiDTO, ? extends ApiDTO>，即可直接匹配Step的参数要求，无需类型转换。

方案3：放宽Spring泛型匹配严格性（临时 workaround，不推荐） #

Spring 6默认启用严格的泛型匹配，可通过配置参数临时放宽：
在application.properties中添加：

spring.generic.allow-wildcard-type-mismatch=true

该配置会让Spring回到类似Spring 5的宽松泛型匹配逻辑，但长期来看会隐藏类型安全问题，仅建议作为过渡方案使用。

内容的提问来源于stack exchange，提问作者Mançaux Pierre-Alexandre