SpringBoot中的 ObjectProvider
本文出处 https://www.cnblogs.com/fengxueyi/p/13888562.html
自动配置中的ObjectProvider
在阅读Spring Boot自动配置源码中关于Tomcat的配置时,看到这样如下的自动配置配置源代码。
@Configuration(proxyBeanMethods = false) @ConditionalOnClass({Servlet.class,Tomcat.class, UpgradeProtocol.class }) @ConditionalOnMissingBean(value = ServletWebServerFactory.class, search = SearchStrategy.CURRENT) public static class EmbeddedTomcat { @Bean public TomcatServletWebServerFactory tomcatServletWebServerFactory( ObjectProvider<TomcatConnectorCustomizer> connectorCustomizers, ObjectProvider<TomcatContextCustomizer> contextCustomizers, ObjectProvider<TomcatProtocolHandlerCustomizer<?>> protocolHandlerCustomizers) { // ... } }
这就是一个常规的基于Java的配置类,那么你是否发现它在用法与其他的有所不同?是的,那就是三个ObjectProvider的参数。这也是本文要讲的内容。
Spring的注入
在介绍ObjectProvider的使用之前,我们先来回顾一下注入相关的知识。
在Spring的使用过程中,我们可以通过多种形式将一个类注入到另外一个类当中,比如通过@Autowired和@Resources注解。
而@Autowired又可以注解在不同的地方来达到注入的效果,
比如:
- 注解在构造函数上:
@Service public class FooService { private final FooRepository repository; @Autowired public FooService(FooRepository repository) { this.repository = repository } }
- 注解在属性上:
@Service public class FooService { @Autowired private final FooRepository repository; }
- 注解在setter方法上:
@Service public class FooService { private final FooRepository repository; @Autowired public void setFooRepository(FooRepository repository) { this.repository = repository } }
spring4.3新特性
上面是最常见的注入方式,如果忘记写@Autowired注解,那么在启动的时候就会抛出异常。
但在spring 4.3之后,引入了一个新特性:当构造方法的参数为单个构造参数时,可以不使用@Autowired进行注解。
因此,上面的代码可变为如下形式(亲测是可以的):
@Service public class FooService { private final FooRepository repository; public FooService(FooRepository repository) { this.repository = repository } }
使用此种形式便会显得优雅一些。该特性,在Spring Boot的自动配置类中大量被使用。
依赖关系的改进
同样是在Spring 4.3版本中,不仅隐式的注入了单构造参数的属性。还引入了ObjectProvider接口。
ObjectProvider接口是ObjectFactory接口的扩展,专门为注入点设计的,可以让注入变得更加宽松和更具有可选项。
public interface ObjectProvider<T> extends ObjectFactory<T>, Iterable<T> {...
那么什么时候使用ObjectProvider接口?
如果待注入参数的Bean为空或有多个时,便是ObjectProvider发挥作用的时候了。
- 如果注入实例为空时,使用ObjectProvider则避免了强依赖导致的依赖对象不存在异常;
- 如果有多个实例,ObjectProvider的方法会根据Bean实现的Ordered接口或@Order注解指定的先后顺序获取一个Bean。从而了提供了一个更加宽松的依赖注入方式。
Spring 5.1之后提供了基于Stream的orderedStream方法来获取有序的Stream的方法。
使用ObjectProvider之后,上面的代码便变为如下方式:
@Service public class FooService { private final FooRepository repository; public FooService(ObjectProvider<FooRepository> repositoryProvider) { this.repository = repositoryProvider.getIfUnique(); } }
或者这样也是一个不错的选择
@Service public class FooService { private final FooRepository repository; public FooService(ObjectProvider<FooRepository> repositoryProvider) { this.repository = repositoryProvider.orderedStream().findFirst().orElse(null); } }
这样的好处很显然,当容器中不存在FooRepository或存在多个时,可以从容处理。但坏处也很明显,如果FooRepository不能为null,则可能将异常从启动阶段转移到业务运行阶段。
ObjectProvider解决的问题
问题一
容器中没有Bean时,抛出Parameter 0 of constructor in com.example.demo.FooServicerequired a bean of type 'com.example.demo.FooRepository' that could not be found.。
解决方式:
@Component public class IndexService { private B b; public IndexService(ObjectProvider<B> b) { this.b = b.getIfAvailable(); } }
但是上面这种解决方式的弊病也很明显,就是b可能为空,则可能将异常从启动阶段转移到业务运行阶段。
问题二
容器中存在多个Bean时,抛出No qualifying bean of type 'com.example.demo.FooRepository'' available: expected single matching bean but found 2
@Component public class IndexService { private B b; public IndexService(ObjectProvider<B> b) { this.b = b.orderedStream().findFirst().orElse(null); } }
当容器存在多个Bean,我们可以调用它的流式方法获取一个自己想要的依赖。
ObjectProvider源码
ObjectProvider的源码及解析如下:
public interface ObjectProvider<T> extends ObjectFactory<T>, Iterable<T> { // 返回指定类型的bean, 如果容器中不存在, 抛出NoSuchBeanDefinitionException异常 // 如果容器中有多个此类型的bean, 抛出NoUniqueBeanDefinitionException异常 T getObject(Object... args) throws BeansException; // 如果指定类型的bean注册到容器中, 返回 bean 实例, 否则返回 null @Nullable T getIfAvailable() throws BeansException; // 如果返回对象不存在,则进行回调,回调对象由Supplier传入 default T getIfAvailable(Supplier<T> defaultSupplier) throws BeansException { T dependency = getIfAvailable(); return (dependency != null ? dependency : defaultSupplier.get()); } // 消费对象的一个实例(可能是共享的或独立的),如果存在通过Consumer回调消耗目标对象。 default void ifAvailable(Consumer<T> dependencyConsumer) throws BeansException { T dependency = getIfAvailable(); if (dependency != null) { dependencyConsumer.accept(dependency); } } // 如果不可用或不唯一(没有指定primary)则返回null。否则,返回对象。 @Nullable T getIfUnique() throws BeansException; // 如果存在唯一对象,则调用Supplier的回调函数 default T getIfUnique(Supplier<T> defaultSupplier) throws BeansException { T dependency = getIfUnique(); return (dependency != null ? dependency : defaultSupplier.get()); } // 如果存在唯一对象,则消耗掉该对象 default void ifUnique(Consumer<T> dependencyConsumer) throws BeansException { T dependency = getIfUnique(); if (dependency != null) { dependencyConsumer.accept(dependency); } } // 返回符合条件的对象的Iterator,没有特殊顺序保证(一般为注册顺序) @Override default Iterator<T> iterator() { return stream().iterator(); } // 返回符合条件对象的连续的Stream,没有特殊顺序保证(一般为注册顺序) default Stream<T> stream() { throw new UnsupportedOperationException("Multi element access not supported"); } // 返回符合条件对象的连续的Stream。在标注Spring应用上下文中采用@Order注解或实现Order接口的顺序 default Stream<T> orderedStream() { throw new UnsupportedOperationException("Ordered element access not supported"); } }
接口分析
在Spring4.3之前,如果你构造函数中要依赖另外一个bean,你必须显示依赖@Autowired(这里不考虑使用了自动注入的方式) ,像这样子
@Service public class FooService { private final FooRepository repository; @Autowired public FooService(FooRepository repository) { this.repository = repository } }
而在4.3版本之后,已经不需要这么做了,只要我们只提供了一个构造函数,并且构造函数所需要的参数都在Spring容器中(实际上官网中也指出,如果依赖关系是强制的,那么最好使用构造函数进行注入),那么不需要进行精确的指定使用@Autowired。相比于4.3版本这无疑简化了我们的开发,但是这种隐式的注入仍然存在一些不足。例如,就上面的例子而言,如果容器中存在了一个以上的FooRepository甚至一个都没有的情况下,抛出异常
Parameter 0 of constructor in com.example.demo.FooServicerequired a bean of type ‘com.example.demo.FooRepository’ that could not be found.
或者
No qualifying bean of type ‘com.example.demo.FooRepository’’ available: expected single matching bean but found 2:
那么我们有什么办法解决它呢?基于这个原因,ObjectProvider就出场了。如果注入实例为空时,使用ObjectProvider则避免了强依赖导致的依赖对象不存在异常;如果有多个实例,ObjectProvider的方法可以根据Bean实现的Ordered接口或@Order注解指定的先后顺序获取一个Bean。从而了提供了一个更加宽松的依赖注入方式。Spring主要在org.springframework.beans.factory.support.DefaultListableBeanFactory#resolveDependency方法中使用了它,具体代码如下:
@Override public Object resolveDependency(DependencyDescriptor descriptor, String requestingBeanName, Set<String> autowiredBeanNames, @Nullable TypeConverter typeConverter) throws BeansException { // descriptor代表当前需要注入的那个字段,或者方法的参数,也就是注入点 // ParameterNameDiscovery用于解析方法参数名称 descriptor.initParameterNameDiscovery(getParameterNameDiscoverer()); // 1. Optional<T> if (Optional.class == descriptor.getDependencyType()) { return createOptionalDependency(descriptor, requestingBeanName); // 2. ObjectFactory<T>、ObjectProvider<T> } else if (ObjectFactory.class == descriptor.getDependencyType() || ObjectProvider.class == descriptor.getDependencyType()) { return new DependencyObjectProvider(descriptor, requestingBeanName); // 3. javax.inject.Provider<T> } else if (javaxInjectProviderClass == descriptor.getDependencyType()) { return new Jsr330Factory().createDependencyProvider(descriptor, requestingBeanName); } else { // 4. @Lazy Object result = getAutowireCandidateResolver().getLazyResolutionProxyIfNecessary( descriptor, requestingBeanName); // 5. 正常情况 if (result == null) { result = doResolveDependency(descriptor, requestingBeanName, autowiredBeanNames, typeConverter); } return result; } }
其实不管是上面的哪个情况,最终都会调用到正常情况下的doResolveDependency方法中。我们着重关注上面的第二种情况,可以看到当注入点为ObjectFactory或者ObjectProvider时,会new一个DependencyObjectProvider返回出去,那么返回的这个DependencyObjectProvider是什么呢?
其继承关系如下:
这个DependencyObjectProvider对象,其实就是一个ObjectProvider,我们看看它是如何实现ObjectProvider中的方法的(方法的实现逻辑都差不多,这里就看一个方法):
public Object getIfAvailable() throws BeansException { // 用于解决嵌套的情况,像这种:ObjectProvider<Optional<T>> if (this.optional) { return createOptionalDependency(this.descriptor, this.beanName); } else { DependencyDescriptor descriptorToUse = new DependencyDescriptor(this.descriptor) { @Override public boolean isRequired() { return false; } }; // 最终还是会调用这个方法解决依赖 return doResolveDependency(descriptorToUse, this.beanName, null, null); } }
从上面的过程中我们可以看出,但Spring中某个Bean的依赖类型为ObjectProvider时,我们不需要提供一个ObjectProvider类型的Bean到容器中,只需要提供一个T类型的Bean到容器中,容器会自动将其包装成一个ObjectProvider,然后注入到依赖中。
而基于ObjectProvider的一系列方法,我们就能解决之前提到的问题。
posted on 2021-01-30 17:49 MaXianZhe 阅读(3647) 评论(0) 编辑 收藏 举报