Spring之什么是ObjectFactory?什么是ObjectProvider?
在Spring的學(xué)習(xí)過程中,總是學(xué)的越多,不懂的越多。本來只是想將ApplicationContext的相關(guān)內(nèi)容全部梳理一遍,結(jié)果發(fā)現(xiàn)涉及的東西越來越多,比如上篇文章中的ResolvableType,到這篇文章介紹的ObjectFactory跟ObjectProvider。不過想想也沒辦法,一步一步往前走唄,在這個(gè)過程中也確實(shí)學(xué)到了很多東西。廢話不多說,直接進(jìn)入正文。
ObjectFactory
接口定義
// 一個(gè)對(duì)象工廠 public interface ObjectFactory<T> { // 返回一個(gè)對(duì)象 T getObject() throws BeansException; }
這個(gè)接口的定義非常簡(jiǎn)單,就是一個(gè)對(duì)象工廠,定義了一個(gè)返回對(duì)象的工廠方法?;仡櫸覀冎苯咏榻B過的一個(gè)內(nèi)容FactroyBean
,其接口定義如下:
public interface FactoryBean<T> { @Nullable T getObject() throws Exception; @Nullable Class<?> getObjectType(); default boolean isSingleton() { return true; } }
可以看到兩者都有一個(gè)getObject
方法,那么它們有什么區(qū)別或者聯(lián)系呢?
跟FactoryBean的區(qū)別及聯(lián)系
聯(lián)系
二者在功能設(shè)計(jì)上是沒有什么聯(lián)系的,他們最大的共同點(diǎn)就是都采用了工廠模式,通過工廠模式來返回一個(gè)對(duì)象
區(qū)別
FactoryBean
在BeanFacotry
的實(shí)現(xiàn)中有著特殊的處理,如果一個(gè)對(duì)象實(shí)現(xiàn)了FactoryBean
那么通過它get出來的對(duì)象實(shí)際是factoryBean.getObject()
得到的對(duì)象,如果想得到FactoryBean
必須通過在 '&' + beanName
的方式獲取
FactoryBean
的設(shè)計(jì)主要是為了進(jìn)行擴(kuò)展容器中Bean的創(chuàng)建方式,所以FactoryBean著重于自定義創(chuàng)建對(duì)象過程,同時(shí)FactoryBean
都會(huì)放到容器中,FactoryBean
所創(chuàng)建的Bean也會(huì)放入容器中
ObjectFactory
則只是一個(gè)普通的對(duì)象工廠接口。在Spring中主要兩處用了它
Scope接口中的get方法,需要傳入一個(gè)ObjectFactory
,如下:
Object get(String name, ObjectFactory<?> objectFactory);
這個(gè)方法的目的就是從對(duì)于的域中獲取到指定名稱的對(duì)象。為什么要傳入一個(gè)objectFactory呢?主要是為了方便我們擴(kuò)展自定義的域,而不是僅僅使用request,session等域。
ConfigurableListableBeanFactory類中的registerResolvableDependency方法,其定義如下,
void registerResolvableDependency(Class<?> dependencyType, @Nullable Object autowiredValue);
粗看起來,好像這個(gè)方法跟ObjectFactory
沒有什么關(guān)聯(lián),但是我們留意這個(gè)方法上面的JavaDoc,其中有一段關(guān)于參數(shù)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.
從這段內(nèi)容中我們能知道,autowiredValue
這個(gè)參數(shù)可能就是一個(gè)ObjectFactory
,主要是為了讓注入點(diǎn)能夠被延遲注入。
Spring通過這種方式注入了request,response等對(duì)象
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 // 是從當(dāng)前線程中獲取的 public ServletRequest getObject() { return currentRequestAttributes().getRequest(); } @Override public String toString() { return "Current HttpServletRequest"; } }
當(dāng)我們?cè)谀骋粋€(gè)類中如果注入了ServletRequest對(duì)象,并不會(huì)直接創(chuàng)建一個(gè)ServletRequest然后注入進(jìn)去,而是注入一個(gè)代理類,代理類中的方法是通過ObjectFactoryDelegatingInvocationHandler
實(shí)現(xiàn)的,而這個(gè)對(duì)象中會(huì)持有一個(gè)RequestObjectFactory對(duì)象。
基于此,我們可以通過下面這種方式直接注入request對(duì)象,并且保證線程安全
@RestController public class AutowiredRequestController { @Autowired private HttpServletRequest request; }
ObjectProvider
接口定義
// 1.可以看到ObjectProvider本身繼承了ObjectFactory接口,所以它本身就是一個(gè)ObjectFactory // 2.從5.1之后,這個(gè)接口還多繼承了一個(gè)Iterable接口,意味著能對(duì)它進(jìn)行迭代以及流式操作 public interface ObjectProvider<T> extends ObjectFactory<T>, Iterable<T> { // 返回用指定參數(shù)創(chuàng)建的bean, 如果容器中不存在, 拋出異常 T getObject(Object... args) throws BeansException; // 如果指定類型的bean注冊(cè)到容器中, 返回 bean 實(shí)例, 否則返回 null @Nullable T getIfAvailable() throws BeansException; // 如果返回對(duì)象不存在,則用傳入的Supplier獲取一個(gè)Bean并返回,否則直接返回存在的對(duì)象 default T getIfAvailable(Supplier<T> defaultSupplier) throws BeansException { T dependency = getIfAvailable(); return (dependency != null ? dependency : defaultSupplier.get()); } // 消費(fèi)對(duì)象的一個(gè)實(shí)例(可能是共享的或獨(dú)立的),如果存在通過Consumer回調(diào)消耗目標(biāo)對(duì)象。 // 如果不存在則直接返回 default void ifAvailable(Consumer<T> dependencyConsumer) throws BeansException { T dependency = getIfAvailable(); if (dependency != null) { dependencyConsumer.accept(dependency); } } // 如果不可用或不唯一(沒有指定primary)則返回null。否則,返回對(duì)象。 @Nullable T getIfUnique() throws BeansException; // 如果不存在唯一對(duì)象,則調(diào)用Supplier的回調(diào)函數(shù) default T getIfUnique(Supplier<T> defaultSupplier) throws BeansException { T dependency = getIfUnique(); return (dependency != null ? dependency : defaultSupplier.get()); } // 如果存在唯一對(duì)象,則消耗掉該對(duì)象 default void ifUnique(Consumer<T> dependencyConsumer) throws BeansException { T dependency = getIfUnique(); if (dependency != null) { dependencyConsumer.accept(dependency); } } // 返回符合條件的對(duì)象的Iterator,沒有特殊順序保證(一般為注冊(cè)順序) @Override default Iterator<T> iterator() { return stream().iterator(); } // 返回符合條件對(duì)象的連續(xù)的Stream,沒有特殊順序保證(一般為注冊(cè)順序) default Stream<T> stream() { throw new UnsupportedOperationException("Multi element access not supported"); } // 返回符合條件對(duì)象的連續(xù)的Stream。在標(biāo)注Spring應(yīng)用上下文中采用@Order注解或?qū)崿F(xiàn)Order接口的順序 default Stream<T> orderedStream() { throw new UnsupportedOperationException("Ordered element access not supported"); } }
接口分析
在Spring4.3之前,如果你構(gòu)造函數(shù)中要依賴另外一個(gè)bean,你必須顯示依賴@Autowired
(這里不考慮使用了自動(dòng)注入的方式,關(guān)于自動(dòng)注入跟精確注入請(qǐng)參我之前的文章,《Spring官網(wǎng)閱讀》系列第二,三篇) ,像這樣子
@Service public class FooService { private final FooRepository repository; @Autowired public FooService(FooRepository repository) { this.repository = repository } }
而在4.3版本之后,已經(jīng)不需要這么做了,只要我們只提供了一個(gè)構(gòu)造函數(shù),并且構(gòu)造函數(shù)所需要的參數(shù)都在Spring容器中(實(shí)際上官網(wǎng)中也指出,如果依賴關(guān)系是強(qiáng)制的,那么最好使用構(gòu)造函數(shù)進(jìn)行注入),那么不需要進(jìn)行精確的指定使用@Autowired
。
相比于4.3版本這無疑簡(jiǎn)化了我們的開發(fā),但是這種隱式的注入仍然存在一些不足。
例如,就上面的例子而言,如果容器中存在了一個(gè)以上的FooRepository甚至一個(gè)都沒有的情況下,拋出異常
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:
那么我們有什么辦法解決它呢?
基于這個(gè)原因,ObjectProvider
就出場(chǎng)了。如果注入實(shí)例為空時(shí),使用ObjectProvider則避免了強(qiáng)依賴導(dǎo)致的依賴對(duì)象不存在異常;如果有多個(gè)實(shí)例,ObjectProvider的方法可以根據(jù)Bean實(shí)現(xiàn)的Ordered接口或@Order注解指定的先后順序獲取一個(gè)Bean。從而了提供了一個(gè)更加寬松的依賴注入方式。
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代表當(dāng)前需要注入的那個(gè)字段,或者方法的參數(shù),也就是注入點(diǎn) // ParameterNameDiscovery用于解析方法參數(shù)名稱 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; } }
其實(shí)不管是上面的哪個(gè)情況,最終都會(huì)調(diào)用到正常情況下的doResolveDependency
方法中。
我們著重關(guān)注上面的第二種情況,可以看到當(dāng)注入點(diǎn)為ObjectFactory
或者ObjectProvider
時(shí),會(huì)new一個(gè)DependencyObjectProvider
返回出去,那么返回的這個(gè)DependencyObjectProvider
是什么呢?
其繼承關(guān)系如下:
這個(gè)DependencyObjectProvider
對(duì)象,其實(shí)就是一個(gè)ObjectProvider
,我們看看它是如何實(shí)現(xiàn)ObjectProvider
中的方法的(方法的實(shí)現(xiàn)邏輯都差不多,這里就看一個(gè)方法):
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; } }; // 最終還是會(huì)調(diào)用這個(gè)方法解決依賴 return doResolveDependency(descriptorToUse, this.beanName, null, null); } }
從上面的過程中我們可以看出,但Spring中某個(gè)Bean的依賴類型為ObjectProvider時(shí),我們不需要提供一個(gè)ObjectProvider類型的Bean到容器中,只需要提供一個(gè)T類型的Bean到容器中,容器會(huì)自動(dòng)將其包裝成一個(gè)ObjectProvider,然后注入到依賴中。
而基于ObjectProvider的一系列方法,我們就能解決之前提到的問題。
ObjectProvider解決的問題
問題一
容器中沒有Bean時(shí),拋出
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可能為空,則可能將異常從啟動(dòng)階段轉(zhuǎn)移到業(yè)務(wù)運(yùn)行階段。
問題二
容器中存在多個(gè)Bean時(shí),拋出
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); } }
當(dāng)容器存在多個(gè)Bean,我們可以調(diào)用它的流式方法獲取一個(gè)自己想要的依賴。
總結(jié)
本文介紹了ObjectFactory
跟ObjectProvider
,對(duì)于ObjectFactory
主要介紹了它的應(yīng)用并且將其與我們之前學(xué)習(xí)過的FactoryBean
做了比較。
關(guān)于ObjectProvider
也對(duì)其中定義的方法,以及它解決的問題做了分析。可能有些讀者覺得這些東西也不是很重要,并不影響核心代碼的閱讀。不過筆者在閱讀源碼過程中,看到了不去弄明白實(shí)在是難受,本人也是秉著愚公移山的精神慢慢啃,一個(gè)知識(shí)點(diǎn)一個(gè)知識(shí)點(diǎn)慢慢摸索,雖然這樣慢了點(diǎn),但是能學(xué)到東西也是有很大滿足感的。
以上為個(gè)人經(jīng)驗(yàn),希望能給大家一個(gè)參考,也希望大家多多支持腳本之家。
相關(guān)文章
詳解springboot+mybatis-plue實(shí)現(xiàn)內(nèi)置的CRUD使用詳情
這篇文章主要介紹了詳解springboot+mybatis-plue實(shí)現(xiàn)內(nèi)置的CRUD使用詳情,文中通過示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2020-07-07淺談java中異步多線程超時(shí)導(dǎo)致的服務(wù)異常
下面小編就為大家?guī)硪黄獪\談java中異步多線程超時(shí)導(dǎo)致的服務(wù)異常。小編覺得挺不錯(cuò)的,現(xiàn)在就分享給大家,也給大家做個(gè)參考。一起跟隨小編過來看看吧2016-06-06springBoot基于webSocket實(shí)現(xiàn)掃碼登錄
最近做了個(gè)新項(xiàng)目,涉及到掃碼登錄。之前項(xiàng)目使用的是 ajax輪詢的方式。感覺太low了。所以這次用webSocket的方式進(jìn)行實(shí)現(xiàn),感興趣的可以了解一下2021-06-06java數(shù)據(jù)庫開發(fā)之JDBC的完整封裝兼容多種數(shù)據(jù)庫
這篇文章主要介紹了java數(shù)據(jù)庫開發(fā)之JDBC的完整封裝兼容多種數(shù)據(jù)庫,需要的朋友可以參考下2020-02-02java 中InputStream,String,File之間的相互轉(zhuǎn)化對(duì)比
這篇文章主要介紹了java 中InputStream,String,File之間的相互轉(zhuǎn)化對(duì)比的相關(guān)資料,需要的朋友可以參考下2017-04-04java微信公眾號(hào)開發(fā)第一步 公眾號(hào)接入和access_token管理
這篇文章主要為大家介紹了java微信公眾號(hào)開發(fā),主要內(nèi)容包括公眾號(hào)接入和access_token管理,感興趣的小伙伴們可以參考一下2016-01-01