ObjectProvider源码

ObjectProvider的源码及解析如下：

public interface ObjectProvider extends ObjectFactory, Iterable {

// 返回指定类型的bean, 如果容器中不存在, 抛出NoSuchBeanDefinitionException异常<br />    // 如果容器中有多个此类型的bean, 抛出NoUniqueBeanDefinitionException异常<br />    T getObject(Object... args) throws BeansException;
// 如果指定类型的bean注册到容器中, 返回 bean 实例, 否则返回 null<br />    @Nullable<br />    T getIfAvailable() throws BeansException;
// 如果返回对象不存在，则进行回调，回调对象由Supplier传入<br />    default T getIfAvailable(Supplier<T> defaultSupplier) throws BeansException {<br />        T dependency = getIfAvailable();<br />        return (dependency != null ? dependency : defaultSupplier.get());<br />    }
// 消费对象的一个实例（可能是共享的或独立的），如果存在通过Consumer回调消耗目标对象。<br />    default void ifAvailable(Consumer<T> dependencyConsumer) throws BeansException {<br />        T dependency = getIfAvailable();<br />        if (dependency != null) {<br />            dependencyConsumer.accept(dependency);<br />        }<br />    }
// 如果不可用或不唯一（没有指定primary）则返回null。否则，返回对象。<br />    @Nullable<br />    T getIfUnique() throws BeansException;
// 如果存在唯一对象，则调用Supplier的回调函数<br />    default T getIfUnique(Supplier<T> defaultSupplier) throws BeansException {<br />        T dependency = getIfUnique();<br />        return (dependency != null ? dependency : defaultSupplier.get());<br />    }
// 如果存在唯一对象，则消耗掉该对象<br />    default void ifUnique(Consumer<T> dependencyConsumer) throws BeansException {<br />        T dependency = getIfUnique();<br />        if (dependency != null) {<br />            dependencyConsumer.accept(dependency);<br />        }<br />    }
// 返回符合条件的对象的Iterator，没有特殊顺序保证（一般为注册顺序）<br />    @Override<br />    default Iterator<T> iterator() {<br />        return stream().iterator();<br />    }
// 返回符合条件对象的连续的Stream，没有特殊顺序保证（一般为注册顺序）<br />    default Stream<T> stream() {<br />        throw new UnsupportedOperationException("Multi element access not supported");<br />    }
// 返回符合条件对象的连续的Stream。在标注Spring应用上下文中采用@Order注解或实现Order接口的顺序<br />    default Stream<T> orderedStream() {<br />        throw new UnsupportedOperationException("Ordered element access not supported");<br />    }<br />}<br />![](https://cdn.nlark.com/yuque/0/2021/gif/655064/1615345121483-548d374a-bdf5-4094-9d70-eae7e692ba93.gif#align=left&display=inline&height=20&margin=%5Bobject%20Object%5D&originHeight=20&originWidth=20&size=0&status=done&style=none&width=20)<br /> 

接口分析

在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 autowiredBeanNames, @Nullable TypeConverter typeConverter) throws BeansException {
// descriptor代表当前需要注入的那个字段，或者方法的参数，也就是注入点
// ParameterNameDiscovery用于解析方法参数名称
descriptor.initParameterNameDiscovery(getParameterNameDiscoverer());
// 1. Optional
if (Optional.class == descriptor.getDependencyType()) {
return createOptionalDependency(descriptor, requestingBeanName);
// 2. ObjectFactory、ObjectProvider
} else if (ObjectFactory.class == descriptor.getDependencyType() ||
ObjectProvider.class == descriptor.getDependencyType()) {
return new DependencyObjectProvider(descriptor, requestingBeanName);
// 3. javax.inject.Provider
} 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>
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的一系列方法，我们就能解决之前提到的问题。