Spring之什麼是ObjectFactory?什麼是ObjectProvider?
在Spring的學習過程中,總是學的越多,不懂的越多。本來隻是想將ApplicationContext的相關內容全部梳理一遍,結果發現涉及的東西越來越多,比如上篇文章中的ResolvableType,到這篇文章介紹的ObjectFactory跟ObjectProvider。不過想想也沒辦法,一步一步往前走唄,在這個過程中也確實學到瞭很多東西。廢話不多說,直接進入正文。
ObjectFactory
接口定義
// 一個對象工廠 public interface ObjectFactory<T> { // 返回一個對象 T getObject() throws BeansException; }
這個接口的定義非常簡單,就是一個對象工廠,定義瞭一個返回對象的工廠方法。回顧我們直接介紹過的一個內容FactroyBean
,其接口定義如下:
public interface FactoryBean<T> { @Nullable T getObject() throws Exception; @Nullable Class<?> getObjectType(); default boolean isSingleton() { return true; } }
可以看到兩者都有一個getObject
方法,那麼它們有什麼區別或者聯系呢?
跟FactoryBean的區別及聯系
聯系
二者在功能設計上是沒有什麼聯系的,他們最大的共同點就是都采用瞭工廠模式,通過工廠模式來返回一個對象
區別
FactoryBean
在BeanFacotry
的實現中有著特殊的處理,如果一個對象實現瞭FactoryBean
那麼通過它get出來的對象實際是factoryBean.getObject()
得到的對象,如果想得到FactoryBean
必須通過在 '&' + beanName
的方式獲取
FactoryBean
的設計主要是為瞭進行擴展容器中Bean的創建方式,所以FactoryBean著重於自定義創建對象過程,同時FactoryBean
都會放到容器中,FactoryBean
所創建的Bean也會放入容器中
ObjectFactory
則隻是一個普通的對象工廠接口。在Spring中主要兩處用瞭它
Scope接口中的get方法,需要傳入一個ObjectFactory
,如下:
Object get(String name, ObjectFactory<?> objectFactory);
這個方法的目的就是從對於的域中獲取到指定名稱的對象。為什麼要傳入一個objectFactory呢?主要是為瞭方便我們擴展自定義的域,而不是僅僅使用request,session等域。
ConfigurableListableBeanFactory類中的registerResolvableDependency方法,其定義如下,
void registerResolvableDependency(Class<?> dependencyType, @Nullable Object autowiredValue);
粗看起來,好像這個方法跟ObjectFactory
沒有什麼關聯,但是我們留意這個方法上面的JavaDoc,其中有一段關於參數autowiredValue的介紹,如下
@param autowiredValue the corresponding autowired value. This may also be an* implementation of the {@link org.springframework.beans.factory.ObjectFactory}* interface, which allows for lazy resolution of the actual target value.
從這段內容中我們能知道,autowiredValue
這個參數可能就是一個ObjectFactory
,主要是為瞭讓註入點能夠被延遲註入。
Spring通過這種方式註入瞭request,response等對象
beanFactory.registerResolvableDependency(ServletRequest.class, new RequestObjectFactory()); beanFactory.registerResolvableDependency(ServletResponse.class, new ResponseObjectFactory()); beanFactory.registerResolvableDependency(HttpSession.class, new SessionObjectFactory()); beanFactory.registerResolvableDependency(WebRequest.class, new WebRequestObjectFactory());
我們看看RequestObjectFactory的定義:
private static class RequestObjectFactory implements ObjectFactory<ServletRequest>, Serializable { @Override // 是從當前線程中獲取的 public ServletRequest getObject() { return currentRequestAttributes().getRequest(); } @Override public String toString() { return "Current HttpServletRequest"; } }
當我們在某一個類中如果註入瞭ServletRequest對象,並不會直接創建一個ServletRequest然後註入進去,而是註入一個代理類,代理類中的方法是通過ObjectFactoryDelegatingInvocationHandler
實現的,而這個對象中會持有一個RequestObjectFactory對象。
基於此,我們可以通過下面這種方式直接註入request對象,並且保證線程安全
@RestController public class AutowiredRequestController { @Autowired private HttpServletRequest request; }
ObjectProvider
接口定義
// 1.可以看到ObjectProvider本身繼承瞭ObjectFactory接口,所以它本身就是一個ObjectFactory // 2.從5.1之後,這個接口還多繼承瞭一個Iterable接口,意味著能對它進行迭代以及流式操作 public interface ObjectProvider<T> extends ObjectFactory<T>, Iterable<T> { // 返回用指定參數創建的bean, 如果容器中不存在, 拋出異常 T getObject(Object... args) throws BeansException; // 如果指定類型的bean註冊到容器中, 返回 bean 實例, 否則返回 null @Nullable T getIfAvailable() throws BeansException; // 如果返回對象不存在,則用傳入的Supplier獲取一個Bean並返回,否則直接返回存在的對象 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
(這裡不考慮使用瞭自動註入的方式,關於自動註入跟精確註入請參我之前的文章,《Spring官網閱讀》系列第二,三篇) ,像這樣子
@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的一系列方法,我們就能解決之前提到的問題。
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 { 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 { B b; public IndexService(ObjectProvider<B> b) { this.b = b.orderedStream().findFirst().orElse(null); } }
當容器存在多個Bean,我們可以調用它的流式方法獲取一個自己想要的依賴。
總結
本文介紹瞭ObjectFactory
跟ObjectProvider
,對於ObjectFactory
主要介紹瞭它的應用並且將其與我們之前學習過的FactoryBean
做瞭比較。
關於ObjectProvider
也對其中定義的方法,以及它解決的問題做瞭分析。可能有些讀者覺得這些東西也不是很重要,並不影響核心代碼的閱讀。不過筆者在閱讀源碼過程中,看到瞭不去弄明白實在是難受,本人也是秉著愚公移山的精神慢慢啃,一個知識點一個知識點慢慢摸索,雖然這樣慢瞭點,但是能學到東西也是有很大滿足感的。
以上為個人經驗,希望能給大傢一個參考,也希望大傢多多支持WalkonNet。
推薦閱讀:
- 關於Spring BeanPostProcessor的執行順序
- Spring擴展接口知識總結
- springboot bean循環依賴實現以及源碼分析
- Spring IOC容器FactoryBean工廠Bean實例
- Spring Cloud動態配置刷新RefreshScope使用示例詳解