
精品專欄
原文出自:http://cmsblogs.com
doCreateBean() 主要用於完成 bean 的建立和初始化工作,我們可以將其分為四個過程:
createBeanInstance()實體化 beanpopulateBean()屬性填充- 迴圈依賴的處理
initializeBean()初始化 bean
第一個過程實體化 bean 已經在前面兩篇部落格分析完畢了,這篇部落格開始分析 屬性填充,也就是 populateBean(),該函式的作用是將 BeanDefinition 中的屬性值賦值給 BeanWrapper 實體物件(對於 BeanWrapper 我們後續專門寫文分析)。
protected void populateBean(String beanName, RootBeanDefinition mbd, @Nullable BeanWrapper bw) {// 沒有實體化物件if (bw == null) {// 有屬性丟擲異常if (mbd.hasPropertyValues()) {throw new BeanCreationException(mbd.getResourceDescription(), beanName, "Cannot apply property values to null instance");}else {// 沒有屬性直接傳回return;}}// 在設定屬性之前給 InstantiationAwareBeanPostProcessors 最後一次改變 bean 的機會boolean continueWithPropertyPopulation = true;// bena 不是"合成"的,即未由應用程式本身定義// 是否持有 InstantiationAwareBeanPostProcessorif (!mbd.isSynthetic() && hasInstantiationAwareBeanPostProcessors()) {// 迭代所有的 BeanPostProcessorsfor (BeanPostProcessor bp : getBeanPostProcessors()) {// 如果為 InstantiationAwareBeanPostProcessorif (bp instanceof InstantiationAwareBeanPostProcessor) {InstantiationAwareBeanPostProcessor ibp = (InstantiationAwareBeanPostProcessor) bp;// 傳回值為是否繼續填充 bean// postProcessAfterInstantiation:如果應該在 bean上面設定屬性則傳回true,否則傳回false// 一般情況下,應該是傳回true,傳回 false 的話,// 將會阻止在此 Bean 實體上呼叫任何後續的 InstantiationAwareBeanPostProcessor 實體。if (!ibp.postProcessAfterInstantiation(bw.getWrappedInstance(), beanName)) {continueWithPropertyPopulation = false;break;}}}}// 如果後續處理器發出停止填充命令,則終止後續操作if (!continueWithPropertyPopulation) {return;}// bean 的屬性值PropertyValues pvs = (mbd.hasPropertyValues() ? mbd.getPropertyValues() : null);if (mbd.getResolvedAutowireMode() == RootBeanDefinition.AUTOWIRE_BY_NAME ||mbd.getResolvedAutowireMode() == RootBeanDefinition.AUTOWIRE_BY_TYPE) {// 將 PropertyValues 封裝成 MutablePropertyValues 物件// MutablePropertyValues 允許對屬性進行簡單的操作,// 並提供建構式以支援Map的深度複製和構造。MutablePropertyValues newPvs = new MutablePropertyValues(pvs);// 根據名稱自動註入if (mbd.getResolvedAutowireMode() == RootBeanDefinition.AUTOWIRE_BY_NAME) {autowireByName(beanName, mbd, bw, newPvs);}// 根據型別自動註入if (mbd.getResolvedAutowireMode() == RootBeanDefinition.AUTOWIRE_BY_TYPE) {autowireByType(beanName, mbd, bw, newPvs);}pvs = newPvs;}// 是否已經註冊了 InstantiationAwareBeanPostProcessorsboolean hasInstAwareBpps = hasInstantiationAwareBeanPostProcessors();// 是否需要進行依賴檢查boolean needsDepCheck = (mbd.getDependencyCheck() != RootBeanDefinition.DEPENDENCY_CHECK_NONE);if (hasInstAwareBpps || needsDepCheck) {if (pvs == null) {pvs = mbd.getPropertyValues();}// 從 bw 物件中提取 PropertyDescriptor 結果集// PropertyDescriptor:可以透過一對存取方法提取一個屬性PropertyDescriptor[] filteredPds = filterPropertyDescriptorsForDependencyCheck(bw, mbd.allowCaching);if (hasInstAwareBpps) {for (BeanPostProcessor bp : getBeanPostProcessors()) {if (bp instanceof InstantiationAwareBeanPostProcessor) {InstantiationAwareBeanPostProcessor ibp = (InstantiationAwareBeanPostProcessor) bp;// 對所有需要依賴檢查的屬性進行後處理pvs = ibp.postProcessPropertyValues(pvs, filteredPds, bw.getWrappedInstance(), beanName);if (pvs == null) {return;}}}}if (needsDepCheck) {// 依賴檢查,對應 depends-on 屬性checkDependencies(beanName, mbd, filteredPds, pvs);}}if (pvs != null) {// 將屬性應用到 bean 中applyPropertyValues(beanName, mbd, bw, pvs);}}
處理流程如下:
- 根據 hasInstantiationAwareBeanPostProcessors 屬性來判斷是否需要在註入屬性之前給 InstantiationAwareBeanPostProcessors 最後一次改變 bean 的機會,此過程可以控制 Spring 是否繼續進行屬性填充。
- 根據註入型別的不同來判斷是根據名稱來自動註入(
autowireByName())還是根據型別來自動註入(autowireByType()),統一存入到 PropertyValues 中,PropertyValues 用於描述 bean 的屬性。 - 判斷是否需要進行 BeanPostProcessor 和 依賴檢測。
- 將所有 PropertyValues 中的屬性填充到 BeanWrapper 中。
自動註入
Spring 會根據註入型別( byName / byType )的不同,呼叫不同的方法( autowireByName() / autowireByType())來註入屬性值。
autowireByName()
方法 autowireByName() 是根據屬性名稱完成自動依賴註入的,程式碼如下:
protected void autowireByName(String beanName, AbstractBeanDefinition mbd, BeanWrapper bw, MutablePropertyValues pvs) {// 對 Bean 物件中非簡單屬性String[] propertyNames = unsatisfiedNonSimpleProperties(mbd, bw);for (String propertyName : propertyNames) {// 如果容器中包含指定名稱的 bean,則將該 bean 註入到 bean中if (containsBean(propertyName)) {// 遞迴初始化相關 beanObject bean = getBean(propertyName);// 為指定名稱的屬性賦予屬性值pvs.add(propertyName, bean);// 屬性依賴註入registerDependentBean(propertyName, beanName);if (logger.isDebugEnabled()) {logger.debug("Added autowiring by name from bean name '" + beanName +"' via property '" + propertyName + "' to bean named '" + propertyName + "'");}}else {if (logger.isTraceEnabled()) {logger.trace("Not autowiring property '" + propertyName + "' of bean '" + beanName +"' by name: no matching bean found");}}}}
該方法邏輯很簡單,獲取該 bean 的非簡單屬性,什麼叫做非簡單屬性呢?就是型別為物件型別的屬性,但是這裡並不是將所有的物件型別都都會找到,比如 8 個原始型別,String 型別 ,Number型別、Date型別、URL型別、URI型別等都會被忽略,如下:
protected String[] unsatisfiedNonSimpleProperties(AbstractBeanDefinition mbd, BeanWrapper bw) {Set<String> result = new TreeSet<>();PropertyValues pvs = mbd.getPropertyValues();PropertyDescriptor[] pds = bw.getPropertyDescriptors();for (PropertyDescriptor pd : pds) {if (pd.getWriteMethod() != null && !isExcludedFromDependencyCheck(pd) && !pvs.contains(pd.getName()) &&!BeanUtils.isSimpleProperty(pd.getPropertyType())) {result.add(pd.getName());}}return StringUtils.toStringArray(result);}
過濾條件為:有可寫方法、依賴檢測中沒有被忽略、不是簡單屬性型別。其實這裡獲取的就是需要依賴註入的屬性。
獲取需要依賴註入的屬性後,透過迭代、遞迴的方式初始化相關的 bean,然後呼叫 registerDependentBean()完成註冊依賴,如下:
public void registerDependentBean(String beanName, String dependentBeanName) {String canonicalName = canonicalName(beanName);synchronized (this.dependentBeanMap) {Set<String> dependentBeans =this.dependentBeanMap.computeIfAbsent(canonicalName, k -> new LinkedHashSet<>(8));if (!dependentBeans.add(dependentBeanName)) {return;}}synchronized (this.dependenciesForBeanMap) {Set<String> dependenciesForBean =this.dependenciesForBeanMap.computeIfAbsent(dependentBeanName, k -> new LinkedHashSet<>(8));dependenciesForBean.add(canonicalName);}}
autowireByType()
protected void autowireByType(String beanName, AbstractBeanDefinition mbd, BeanWrapper bw, MutablePropertyValues pvs) {// 獲取 TypeConverter 實體// 使用自定義的 TypeConverter,用於取代預設的 PropertyEditor 機制TypeConverter converter = getCustomTypeConverter();if (converter == null) {converter = bw;}Set<String> autowiredBeanNames = new LinkedHashSet<>(4);// 獲取非簡單屬性String[] propertyNames = unsatisfiedNonSimpleProperties(mbd, bw);for (String propertyName : propertyNames) {try {// 獲取 PropertyDescriptor 實體PropertyDescriptor pd = bw.getPropertyDescriptor(propertyName);// 不要嘗試按型別if (Object.class != pd.getPropertyType()) {// 探測指定屬性的 set 方法MethodParameter methodParam = BeanUtils.getWriteMethodParameter(pd);boolean eager = !PriorityOrdered.class.isInstance(bw.getWrappedInstance());DependencyDescriptor desc = new AbstractAutowireCapableBeanFactory.AutowireByTypeDependencyDescriptor(methodParam, eager);// 解析指定 beanName 的屬性所匹配的值,並把解析到的屬性名稱儲存在 autowiredBeanNames 中// 當屬性存在過個封裝 bean 時將會找到所有匹配的 bean 並將其註入Object autowiredArgument = resolveDependency(desc, beanName, autowiredBeanNames, converter);if (autowiredArgument != null) {pvs.add(propertyName, autowiredArgument);}// 迭代方式註入 beanfor (String autowiredBeanName : autowibeanredBeanNames) {registerDependentBean(autowiredBeanName, beanName);if (logger.isDebugEnabled()) {logger.debug("Autowiring by type from bean name '" + beanName + "' via property '" +propertyName + "' to bean named '" + autowiredBeanName + "'");}}autowiredBeanNames.clear();}}catch (BeansException ex) {throw new UnsatisfiedDependencyException(mbd.getResourceDescription(), beanName, propertyName, ex);}}}
其實主要過程和根據名稱自動註入差不多都是找到需要依賴註入的屬性,然後透過迭代的方式尋找所匹配的 bean,最後呼叫 registerDependentBean() 註冊依賴。不過相對於 autowireByName() 而言,根據型別尋找相匹配的 bean 過程比較複雜,下麵我們就分析這個複雜的過程,如下:
public Object resolveDependency(DependencyDescriptor descriptor, @Nullable String requestingBeanName,@Nullable Set<String> autowiredBeanNames, @Nullable TypeConverter typeConverter) throws BeansException {// 初始化引數名稱發現器,該方法並不會在這個時候嘗試檢索引數名稱// getParameterNameDiscoverer 傳回 parameterNameDiscoverer 實體,parameterNameDiscoverer 方法引數名稱的解析器descriptor.initParameterNameDiscovery(getParameterNameDiscoverer());// 依賴型別為 Optional 型別if (Optional.class == descriptor.getDependencyType()) {// 建立 Optional 實體依賴型別return createOptionalDependency(descriptor, requestingBeanName);}// 依賴型別為ObjectFactory、ObjectProviderelse if (ObjectFactory.class == descriptor.getDependencyType() ||ObjectProvider.class == descriptor.getDependencyType()) {// ObjectFactory / ObjectProvider 用於 用於延遲解析依賴項return new DefaultListableBeanFactory.DependencyObjectProvider(descriptor, requestingBeanName);}else if (javaxInjectProviderClass == descriptor.getDependencyType()) {// javaxInjectProviderClass 類註入的特殊處理return new DefaultListableBeanFactory.Jsr330ProviderFactory().createDependencyProvider(descriptor, requestingBeanName);}else {// 為實際依賴關係標的的延遲解析構建代理// 預設實現傳回 nullObject result = getAutowireCandidateResolver().getLazyResolutionProxyIfNecessary(descriptor, requestingBeanName);if (result == null) {// 通用處理邏輯result = doResolveDependency(descriptor, requestingBeanName, autowiredBeanNames, typeConverter);}return result;}}
這裡我們關註通用處理邏輯: doResolveDependency(),如下:
public Object doResolveDependency(DependencyDescriptor descriptor, @Nullable String beanName,@Nullable Set<String> autowiredBeanNames, @Nullable TypeConverter typeConverter) throws BeansException {// 註入點InjectionPoint previousInjectionPoint = ConstructorResolver.setCurrentInjectionPoint(descriptor);try {// 針對給定的工廠給定一個快捷實現的方式,例如考慮一些預先解析的資訊// 在進入所有bean的常規型別匹配演演算法之前,解析演演算法將首先嘗試透過此方法解析快捷方式。// 子類可以改寫此方法Object shortcut = descriptor.resolveShortcut(this);if (shortcut != null) {// 傳回快捷的解析資訊return shortcut;}// 依賴的型別Class> type = descriptor.getDependencyType();// 支援 Spring 的註解 @valueObject value = getAutowireCandidateResolver().getSuggestedValue(descriptor);if (value != null) {if (value instanceof String) {String strVal = resolveEmbeddedValue((String) value);BeanDefinition bd = (beanName != null && containsBean(beanName) ? getMergedBeanDefinition(beanName) : null);value = evaluateBeanDefinitionString(strVal, bd);}TypeConverter converter = (typeConverter != null ? typeConverter : getTypeConverter());return (descriptor.getField() != null ?converter.convertIfNecessary(value, type, descriptor.getField()) :converter.convertIfNecessary(value, type, descriptor.getMethodParameter()));}// 解析複合 bean,其實就是對 bean 的屬性進行解析// 包括:陣列、Collection 、Map 型別Object multipleBeans = resolveMultipleBeans(descriptor, beanName, autowiredBeanNames, typeConverter);if (multipleBeans != null) {return multipleBeans;}// 查詢與型別相匹配的 bean// 傳回值構成為:key = 匹配的 beanName,value = beanName 對應的實體化 beanMap<String, Object> matchingBeans = findAutowireCandidates(beanName, type, descriptor);// 沒有找到,檢驗 @autowire 的 require 是否為 trueif (matchingBeans.isEmpty()) {// 如果 @autowire 的 require 屬性為 true ,但是沒有找到相應的匹配項,則丟擲異常if (isRequired(descriptor)) {raiseNoMatchingBeanFound(type, descriptor.getResolvableType(), descriptor);}return null;}String autowiredBeanName;Object instanceCandidate;if (matchingBeans.size() > 1) {// 確認給定 bean autowire 的候選者// 按照 @Primary 和 @Priority 的順序autowiredBeanName = determineAutowireCandidate(matchingBeans, descriptor);if (autowiredBeanName == null) {if (isRequired(descriptor) || !indicatesMultipleBeans(type)) {// 唯一性處理return descriptor.resolveNotUnique(type, matchingBeans);} else {// 在可選的Collection / Map的情況下,默默地忽略一個非唯一的情況:可能它是一個多個常規bean的空集合return null;}}instanceCandidate = matchingBeans.get(autowiredBeanName);} else {// We have exactly one match.Map.Entry<Staring, Object> entry = matchingBeans.entrySet().iterator().next();autowiredBeanName = entry.getKey();instanceCandidate = entry.getValue();}if (autowiredBeanNames != null) {autowiredBeanNames.add(autowiredBeanName);}if (instanceCandidate instanceof Class) {instanceCandidate = descriptor.resolveCandidate(autowiredBeanName, type, this);}Object result = instanceCandidate;if (result instanceof NullBean) {if (isRequired(descriptor)) {raiseNoMatchingBeanFound(type, descriptor.getResolvableType(), descriptor);}result = null;}if (!ClassUtils.isAssignableValue(type, result)) {throw new BeanNotOfRequiredTypeException(autowiredBeanName, type, instanceCandidate.getClass());}return result;} finally {ConstructorResolver.setCurrentInjectionPoint(previousInjectionPoint);}}
到這裡就已經完成了所有屬性的註入了。 populateBean() 該方法就已經完成了一大半工作了,下一步則是對依賴 bean 的檢測和 PostProcessor 處理,這個我們後面分析,下麵分析該方法的最後一步: applyPropertyValues()
applyPropertyValues
其實上面只是完成了所有註入屬性的獲取,將獲取的屬性封裝在 PropertyValues 的實體物件 pvs 中,並沒有應用到已經實體化的 bean 中,而 applyPropertyValues() 則是完成這一步驟的。
protected void applyPropertyValues(String beanName, BeanDefinition mbd, BeanWrapper bw, PropertyValues pvs) {if (pvs.isEmpty()) {return;}if (System.getSecurityManager() != null && bw instanceof BeanWrapperImpl) {((BeanWrapperImpl) bw).setSecurityContext(getAccessControlContext());}// MutablePropertyValues 型別屬性MutablePropertyValues mpvs = null;// 原始型別List<PropertyValue> original;if (pvs instanceof MutablePropertyValues) {mpvs = (MutablePropertyValues) pvs;if (mpvs.isConverted()) {try {// 設定到 BeanWrapper 中去bw.setPropertyValues(mpvs);return;}catch (BeansException ex) {throw new BeanCreationException(mbd.getResourceDescription(), beanName, "Error setting property values", ex);}}original = mpvs.getPropertyValueList();}else {// 如果 pvs 不是 MutablePropertyValues 型別,則直接使用原始型別original = Arrays.asList(pvs.getPropertyValues());}// 獲取 TypeConverterTypeConverter converter = getCustomTypeConverter();if (converter == null) {converter = bw;}// 獲取對應的解析器BeanDefinitionValueResolver valueResolver = new BeanDefinitionValueResolver(this, beanName, mbd, converter);// Create a deep copy, resolving any references for values.List<PropertyValue> deepCopy = new ArrayList<>(original.size());boolean resolveNecessary = false;// 遍歷屬性,將屬性轉換為對應類的對應屬性的型別for (PropertyValue pv : original) {if (pv.isConverted()) {deepCopy.add(pv);}else {String propertyName = pv.getName();Object originalValue = pv.getValue();Object resolvedValue = valueResolver.resolveValueIfNecessary(pv, originalValue);Object convertedValue = resolvedValue;boolean convertible = bw.isWritableProperty(propertyName) &&!PropertyAccessorUtils.isNestedOrIndexedProperty(propertyName);if (convertible) {convertedValue = convertForProperty(resolvedValue, propertyName, bw, converter);}// Possibly store converted value in merged bean definition,// in order to avoid re-conversion for every created bean instance.if (resolvedValue == originalValue) {if (convertible) {pv.setConvertedValue(convertedValue);}deepCopy.add(pv);}else if (convertible && originalValue instanceof TypedStringValue &&!((TypedStringValue) originalValue).isDynamic() &&!(convertedValue instanceof Collection || ObjectUtils.isArray(convertedValue))) {pv.setConvertedValue(convertedValue);deepCopy.add(pv);}else {resolveNecessary = true;deepCopy.add(new PropertyValue(pv, convertedValue));}}}if (mpvs != null && !resolveNecessary) {mpvs.setConverted();}// Set our (possibly massaged) deep copy.try {bw.setPropertyValues(new MutablePropertyValues(deepCopy));}catch (BeansException ex) {throw new BeanCreationException(mbd.getResourceDescription(), beanName, "Error setting property values", ex);}}
至此, doCreateBean() 第二個過程:屬性填充 已經分析完成了,下篇分析第三個過程:迴圈依賴的處理,其實迴圈依賴並不僅僅只是在 doCreateBean() 中處理,其實在整個載入 bean 的過程中都有涉及,所以下篇內容並不僅僅只侷限於 doCreateBean()。
【死磕 Spring】—– IOC 之開啟 bean 的實體化行程
【死磕 Spring】—– IOC 之 Factory 實體化 bean
【死磕 Spring】—– IOC 之建構式實體化 bean
【死磕 Spring】—– IOC 之分析各 scope 的 bean 建立
【死磕 Spring】—– IOC 之開啟 bean 的載入
【死磕 Spring】—– IOC 之從單例快取中獲取單例 bean
【死磕 Spring】—– IOC 之parentBeanFactory 與依賴處理
END

>>>>>> 加群交流技術 <<<<<<
知識星球