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的一系列方法，我們就能解決之前提到的問題。