优雅终结启动顺序噩梦：ObjectProvider —— Spring 4.3 开始引入

🧑 博主简介：ZEEKLOG博客专家，「历代文学网」（PC端可以访问：https://lidaiwenxue.com/#/?__c=1000，移动端可关注公众号 “ 心海云图 ” 微信小程序搜索“历代文学”）总架构师，首席架构师，也是联合创始人！16年工作经验，精通Java编程，高并发设计，分布式系统架构设计，Springboot和微服务，熟悉Linux，ESXI虚拟化以及云原生Docker和K8s，热衷于探索科技的边界，并将理论知识转化为实际应用。保持对新技术的好奇心，乐于分享所学，希望通过我的实践经历和见解，启发他人的创新思维。在这里，我希望能与志同道合的朋友交流探讨，共同进步，一起在技术的世界里不断学习成长。
🤝商务合作：请搜索或扫码关注微信公众号 “ 心海云图 ”

优雅终结启动顺序噩梦：ObjectProvider —— Spring 4.3 开始引入

从“饥渴式依赖”到“按需获取”，一次依赖注入的思想跃迁

缘起：一个再普通不过的配置类，为何启动就报错？

就在上周，我在维护一个 Spring Boot 4.0 项目时遇到了一个棘手的问题：

@ConfigurationpublicclassWebmvcEncryptionConfiguration{@AutowiredprivateHttpMessageConverter<Object> httpMessageConverter;// 注入总为 null@BeanFilterRegistrationBean<EncryptedFilter>encryptedFilterRegistrationBean(){// 启动时抛出 NullPointerException，httpMessageConverter 未初始化！returnnewFilterRegistrationBean<>(newEncryptedFilter(httpMessageConverter));}}

无论我怎么调整注入方式——字段注入、构造器注入、方法参数注入——HttpMessageConverter 始终是 null。更诡异的是，只要注释掉这个配置类，整个应用就能正常启动，HttpMessageConverter 也能被完美初始化。

直觉告诉我：这不是注入“写错了”，而是 FilterRegistrationBean 的初始化时机早于 HttpMessageConverter 的自动配置。

Spring 容器尚未完成 WebMvc 基础设施的装配，我的过滤器却已经急不可耐地索要依赖——这就像在清晨 5 点去咖啡馆要一杯现磨手冲，咖啡师还在通勤路上。

如何让依赖“等等再给”？

答案就藏在 Spring 4.3 引入的一个低调接口中：ObjectProvider。

一、版本之问：ObjectProvider 究竟出生在哪一年？

关于 ObjectProvider 的引入版本，网上存在不少混淆信息。我需要在这里正本清源：

✅ Spring Framework 4.3 首次引入 ObjectProvider
❌ Spring 5.0 说、Spring Boot 2.0 说 均为误传

权威证据链：

1. Spring 官方博客（2016年3月）明确写道：“Spring Framework 4.3 引入了 ObjectProvider，它是现有 ObjectFactory 接口的扩展，提供 getIfAvailable 和 getIfUnique 等便捷签名”
2. 版本时间线：Spring 4.3.0.RC1 发布于 2016年3月，4.3.0.GA 发布于 2016年5月；而 Spring 5.0 在 2017年9月才正式发布
3. 历史实证：有开发者反馈在 Spring 4.2.4 中遇到 NoClassDefFoundError: org/springframework/beans/factory/ObjectProvider，升级到 4.3 后解决

为什么会有 5.0 的说法？因为 Spring 5.0 和 Spring Boot 2.0 增强了ObjectProvider（如添加 orderedStream() 方法），但它真正的诞生时刻是 2016 年 5 月，Spring Framework 4.3 GA。

二、原理深潜：ObjectProvider 为什么能解决顺序问题？

2.1 两种依赖获取哲学的较量

要理解 ObjectProvider 的优雅，首先要看清 @Autowired 的本质：

形象的比喻：

• @Autowired：“咖啡必须在我进办公室前就放在桌上”
• ObjectProvider：“给我一张咖啡券，我想喝的时候自己去打”

2.2 Spring 源码级的特殊对待

为什么 ObjectProvider 能“躲过”启动时的依赖解析？秘密藏在 DefaultListableBeanFactory.resolveDependency() 中 ：

@OverridepublicObjectresolveDependency(DependencyDescriptor descriptor,...){// 1. Optional<T>if(Optional.class== descriptor.getDependencyType()){returncreateOptionalDependency(descriptor, requestingBeanName);}// 2. ObjectFactory<T>、ObjectProvider<T> —— 重点在这里！elseif(ObjectFactory.class== descriptor.getDependencyType()||ObjectProvider.class== descriptor.getDependencyType()){// 不触发真正的依赖解析，直接返回一个“懒加载代理”returnnewDependencyObjectProvider(descriptor, requestingBeanName);}// ... 其他情况else{returndoResolveDependency(descriptor,...);// 立即解析}}

关键结论：当 Spring 发现你注入的是 ObjectProvider<T> 时，它不会去容器中查找 T 类型的 Bean，而是直接给你一个 DependencyObjectProvider 对象。真正的 Bean 查找被推迟到你第一次调用 getObject() 或 getIfAvailable() 的时刻。

这正是解决 FilterRegistrationBean 初始化顺序问题的终极武器——我的 Filter 可以提前注册，但 HttpMessageConverter 可以“按需再取”。

三、实战改造：从“饥渴注入”到“按需获取”

3.1 问题代码的完整解决方案

publicclassEncryptedFilterimplementsFilter{privatefinalWebClientConfigProperties properties;privatefinalRequestMappingHandlerMapping handlerMapping;privatefinalObjectProvider<HttpMessageConverter<?>> converterProvider;// 注入提供者publicEncryptedFilter(WebClientConfigProperties properties,RequestMappingHandlerMapping handlerMapping,ObjectProvider<HttpMessageConverter<?>> converterProvider){this.properties = properties;this.handlerMapping = handlerMapping;this.converterProvider = converterProvider;}@OverridepublicvoiddoFilter(ServletRequest request,ServletResponse response,FilterChain chain)throwsIOException,ServletException{// 真正需要转换器时才去获取——此时容器已完成自动配置HttpMessageConverter<?> converter = converterProvider.getIfAvailable();if(converter !=null){// 使用转换器处理加解密逻辑} chain.doFilter(request, response);}}

配置类（彻底抛弃字段注入）：

@ConfigurationpublicclassWebmvcEncryptionConfiguration{@BeanFilterRegistrationBean<EncryptedFilter>encryptedFilterRegistrationBean(WebClientConfigProperties webClientConfigProperties,RequestMappingHandlerMapping requestMappingHandlerMapping,ObjectProvider<HttpMessageConverter<?>> httpMessageConverterProvider){// 参数注入EncryptedFilter filter =newEncryptedFilter( webClientConfigProperties, requestMappingHandlerMapping, httpMessageConverterProvider);// 传递的是 Provider，不是具体的 ConverterFilterRegistrationBean<EncryptedFilter> registrationBean =newFilterRegistrationBean<>(); registrationBean.setOrder(Ordered.HIGHEST_PRECEDENCE); registrationBean.setFilter(filter); registrationBean.setName("encryptedFilter"); registrationBean.addUrlPatterns("/*");return registrationBean;}}

✅ 改动极小，但彻底解决了启动顺序问题。

四、ObjectProvider 的四大黄金场景

如果说解决启动顺序只是 ObjectProvider 的“意外之喜”，那么下面四个场景才是它真正的设计目标，也是每一位 Spring 开发者都应该掌握的进阶技巧。

场景一：优雅处理可选依赖（替代 @Autowired(required=false)）

传统写法——丑陋的空值检查：

@ServicepublicclassNotificationService{@Autowired(required =false)privateSmsService smsService;// 可能为 nullpublicvoidsendAlert(String message){if(smsService !=null){// 每次都要判空 smsService.send(message);}}}

ObjectProvider 写法——函数式、零判空：

@ServicepublicclassNotificationService{@AutowiredprivateObjectProvider<SmsService> smsServiceProvider;publicvoidsendAlert(String message){// 存在才执行，不存在什么都不发生 smsServiceProvider.ifAvailable(sms -> sms.send(message));// 或者提供默认实现SmsService sms = smsServiceProvider.getIfAvailable(()->newMockSmsService());}}

场景二：在单例 Bean 中正确获取原型 Bean（最核心用途）

错误示范——90% 开发者踩过的坑 ：

@Component@Scope("prototype")publicclassTaskProcessor{/* ... */}@Service// 默认单例publicclassTaskService{@AutowiredprivateTaskProcessor taskProcessor;// ❌ 仅在启动时注入一次，之后永远是同一个实例！publicvoidexecute(){ taskProcessor.process();// 每次用的都是同一个对象}}

ObjectProvider 拯救：

@ServicepublicclassTaskService{@AutowiredprivateObjectProvider<TaskProcessor> taskProcessorProvider;publicvoidexecute(){// 每次调用都从容器获取全新的原型实例TaskProcessor processor = taskProcessorProvider.getObject(); processor.process();}}

与 @Lookup 对比 ：

结论：原型 Bean 获取，首选 ObjectProvider。

场景三：动态筛选多个同类型 Bean

当一个接口有多个实现时，传统方式必须指定 @Qualifier 或 @Primary，编译时就决定了用哪一个。

ObjectProvider 实现运行时动态选择 ：

publicinterfacePaymentService{booleansupports(String type);voidpay(Order order);}@ServicepublicclassPaymentProcessor{@AutowiredprivateObjectProvider<PaymentService> paymentServiceProvider;publicvoidprocessPayment(Order order,String paymentType){PaymentService service = paymentServiceProvider.stream().filter(ps -> ps.supports(paymentType)).findFirst().orElseThrow(()->newUnsupportedOperationException("不支持的支付方式")); service.pay(order);}}

加上排序支持（Spring 5.1+）：

// 按照 @Order 或 Ordered 接口的顺序获取所有实现 paymentServiceProvider.orderedStream().forEach(PaymentService::someCommonOperation);

场景四：解决循环依赖

虽然 Spring 三级缓存能解决大部分 setter 注入的循环依赖，但对于构造器注入的循环依赖依然束手无策。ObjectProvider 可以轻松破局：

@ComponentpublicclassServiceA{privatefinalObjectProvider<ServiceB> serviceBProvider;publicServiceA(ObjectProvider<ServiceB> serviceBProvider){this.serviceBProvider = serviceBProvider;}publicvoiddoSomething(){// 需要 B 的时候再去拿，此时 B 一定已初始化完毕ServiceB b = serviceBProvider.getObject();}}@ComponentpublicclassServiceB{privatefinalServiceA serviceA;// 正常构造器注入publicServiceB(ServiceA serviceA){this.serviceA = serviceA;}}

五、与其他方案的对比：我该如何选择？

核心决策标准：只要存在 “依赖的创建/解析时机晚于当前 Bean 的初始化时机”，就应该考虑 ObjectProvider。

六、结语：为什么说 ObjectProvider 是一颗“时间胶囊”？

回顾开篇的问题，FilterRegistrationBean 之所以无法直接注入 HttpMessageConverter，本质上是 基础设施组件与业务组件初始化阶段的不匹配。

ObjectProvider 的伟大之处，不是它提供了什么复杂的功能，而是它改变了我们对依赖注入的思考方式：

• 从“饥渴式”到“按需式”：依赖不一定要在注入点就绪，可以等到真正使用时才获取
• 从“静态绑定”到“动态解析”：依赖的选择可以从编译期推迟到运行期
• 从“强依赖”到“可选依赖”：允许依赖的不确定性，并在语言层面优雅处理

这让我想起计算机科学中的一句名言：“计算机科学中的所有问题，都可以通过增加一个间接层来解决”。ObjectProvider<T> 正是这样一层优雅的“间接”——它将“依赖”封装成“获取依赖的能力”，将“对象”升级为“对象提供者”。

当你下次在 Spring Boot 启动过程中遇到类似的顺序问题时，不妨问问自己：

“我是否可以在当前 Bean 中，不为具体的依赖，而为它的‘提供者’预留一个位置？”

这个答案，早在 2016 年春天，Spring 4.3 就已经为你准备好了。

附录：ObjectProvider 核心 API 速查表

本文由真实生产问题驱动，结合 Spring 源码与官方文档撰写。