Spring IOC 容器源码分析 - 填充属性到 bean 原始对象
1. 简介
本篇文章，咱们来一块儿了解一下 Spring 是如何将配置文件中的属性值填充到 bean 对象中的。我在前面几篇文章中介绍过 Spring 建立 bean 的流程，即 Spring 先经过反射建立一个原始的 bean 对象，而后再向这个原始的 bean 对象中填充属性。对于填充属性这个过程，简单点来讲，JavaBean 的每一个属性一般都有 getter/setter 方法，咱们能够直接调用 setter 方法将属性值设置进去。固然，这样作仍是太简单了，填充属性的过程当中还有许多事情要作。好比在 Spring 配置中，全部属性值都是以字符串的形式进行配置的，咱们在将这些属性值赋值给对象的成员变量时，要根据变量类型进行相应的类型转换。对于一些集合类的配置，好比 <list/>、<set/> 和 <map/>，还要将这些配置转换成相应的集合对象才能进行后续的操做。除此以外，若是用户配置了自动注入（autowire = byName/byType），Spring 还要去为自动注入的属性寻找合适的注入项。由此能够见，属性填充的整个过程仍是很复杂的，并不是是简单调用 setter 方法设置属性值便可。html
关于属性填充的一些知识，本章先介绍这里。接下来，咱们深刻到源码中，从源码中了解属性填充的整个过程。java
2. 源码分析
2.1 populateBean 源码一览
本节，咱们先来看一下填充属性的方法，即 populateBean。该方法并不复杂，但它所调用的一些方法比较复杂。不过好在咱们这里只须要知道这些方法都有什么用就好了，暂时不用纠结细节。好了，下面看源码吧。mysql
protected void populateBean(String beanName, RootBeanDefinition mbd, BeanWrapper bw) {
// 获取属性列表
PropertyValues pvs = mbd.getPropertyValues();
if (bw == null) {
if (!pvs.isEmpty()) {
throw new BeanCreationException(
mbd.getResourceDescription(), beanName, "Cannot apply property values to null instance");
}
else {
return;
}
}
boolean continueWithPropertyPopulation = true;
/*
* 在属性被填充前，给 InstantiationAwareBeanPostProcessor 类型的后置处理器一个修改
* bean 状态的机会。关于这段后置引用，官方的解释是：让用户能够自定义属性注入。好比用户实现一
* 个 InstantiationAwareBeanPostProcessor 类型的后置处理器，并经过
* postProcessAfterInstantiation 方法向 bean 的成员变量注入自定义的信息。固然，若是无
* 特殊需求，直接使用配置中的信息注入便可。另外，Spring 并不建议你们直接实现
* InstantiationAwareBeanPostProcessor 接口，若是想实现这种类型的后置处理器，更建议
* 经过继承 InstantiationAwareBeanPostProcessorAdapter 抽象类实现自定义后置处理器。
*/
if (!mbd.isSynthetic() && hasInstantiationAwareBeanPostProcessors()) {
for (BeanPostProcessor bp : getBeanPostProcessors()) {
if (bp instanceof InstantiationAwareBeanPostProcessor) {
InstantiationAwareBeanPostProcessor ibp = (InstantiationAwareBeanPostProcessor) bp;
if (!ibp.postProcessAfterInstantiation(bw.getWrappedInstance(), beanName)) {
continueWithPropertyPopulation = false;
break;
}
}
}
}
/*
* 若是上面设置 continueWithPropertyPopulation = false，代表用户可能已经本身填充了
* bean 的属性，不须要 Spring 帮忙填充了。此时直接返回便可
*/
if (!continueWithPropertyPopulation) {
return;
}
// 根据名称或类型注入依赖
if (mbd.getResolvedAutowireMode() == RootBeanDefinition.AUTOWIRE_BY_NAME ||
mbd.getResolvedAutowireMode() == RootBeanDefinition.AUTOWIRE_BY_TYPE) {
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;
}
boolean hasInstAwareBpps = hasInstantiationAwareBeanPostProcessors();
boolean needsDepCheck = (mbd.getDependencyCheck() != RootBeanDefinition.DEPENDENCY_CHECK_NONE);
/*
* 这里又是一种后置处理，用于在 Spring 填充属性到 bean 对象前，对属性的值进行相应的处理，
* 好比能够修改某些属性的值。这时注入到 bean 中的值就不是配置文件中的内容了，
* 而是通过后置处理器修改后的内容
*/
if (hasInstAwareBpps || needsDepCheck) {
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) {
checkDependencies(beanName, mbd, filteredPds, pvs);
}
}
// 应用属性值到 bean 对象中
applyPropertyValues(beanName, mbd, bw, pvs);
}
上面的源码注释的比较详细了，下面咱们来总结一下这个方法的执行流程。以下：spring
- 获取属性列表 pvs
- 在属性被填充到 bean 前，应用后置处理自定义属性填充
- 根据名称或类型解析相关依赖
- 再次应用后置处理，用于动态修改属性列表 pvs 的内容
- 将属性应用到 bean 对象中
注意第3步，也就是根据名称或类型解析相关依赖（autowire）。该逻辑只会解析依赖，并不会将解析出的依赖当即注入到 bean 对象中。全部的属性值是在 applyPropertyValues 方法中统一被注入到 bean 对象中的。sql
在下面的章节中，我将会对 populateBean 方法中比较重要的几个方法调用进行分析，也就是第3步和第5步中的三个方法。好了，本节先到这里。数组
2.2 autowireByName 方法分析
本节来分析一下 autowireByName 方法的代码，其实这个方法根据方法名，你们应该知道它有什么用了。因此我也就不啰嗦了，我们直奔主题，直接分析源码：app
protected void autowireByName(
String beanName, AbstractBeanDefinition mbd, BeanWrapper bw, MutablePropertyValues pvs) {
/*
* 获取非简单类型属性的名称，且该属性未被配置在配置文件中。这里从反面解释一下什么是"非简单类型"
* 属性，咱们先来看看 Spring 认为的"简单类型"属性有哪些，以下：
* 1. CharSequence 接口的实现类，好比 String
* 2. Enum
* 3. Date
* 4. URI/URL
* 5. Number 的继承类，好比 Integer/Long
* 6. byte/short/int... 等基本类型
* 7. Locale
* 8. 以上全部类型的数组形式，好比 String[]、Date[]、int[] 等等
*
* 除了要求非简单类型的属性外，还要求属性未在配置文件中配置过，也就是 pvs.contains(pd.getName()) = false。
*/
String[] propertyNames = unsatisfiedNonSimpleProperties(mbd, bw);
for (String propertyName : propertyNames) {
// 检测是否存在与 propertyName 相关的 bean 或 BeanDefinition。若存在，则调用 BeanFactory.getBean 方法获取 bean 实例
if (containsBean(propertyName)) {
// 从容器中获取相应的 bean 实例
Object bean = getBean(propertyName);
// 将解析出的 bean 存入到属性值列表（pvs）中
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");
}
}
}
}
autowireByName 方法的逻辑比较简单，该方法首先获取非简单类型属性的名称，而后再根据名称到容器中获取相应的 bean 实例，最后再将获取到的 bean 添加到属性列表中便可。既然这个方法比较简单，那我也就很少说了，继续下面的分析。框架
2.3 autowireByType 方法分析
本节咱们来分析一下 autowireByName 的孪生兄弟 autowireByType，相较于 autowireByName，autowireByType 则要复杂一些，复杂之处在于解析依赖的过程。不过也不要紧，若是咱们不过于纠结细节，咱们彻底能够把一些复杂的地方当作一个黑盒，咱们只须要要知道这个黑盒有什么用便可。这样能够在很大程度上下降源码分析的难度。好了，其余的就很少说了，我们来分析源码吧。ide
protected void autowireByType(
String beanName, AbstractBeanDefinition mbd, BeanWrapper bw, MutablePropertyValues pvs) {
TypeConverter converter = getCustomTypeConverter();
if (converter == null) {
converter = bw;
}
Set<String> autowiredBeanNames = new LinkedHashSet<String>(4);
// 获取非简单类型的属性
String[] propertyNames = unsatisfiedNonSimpleProperties(mbd, bw);
for (String propertyName : propertyNames) {
try {
PropertyDescriptor pd = bw.getPropertyDescriptor(propertyName);
// 若是属性类型为 Object，则忽略，不作解析
if (Object.class != pd.getPropertyType()) {
/*
* 获取 setter 方法（write method）的参数信息，好比参数在参数列表中的
* 位置，参数类型，以及该参数所归属的方法等信息
*/
MethodParameter methodParam = BeanUtils.getWriteMethodParameter(pd);
// Do not allow eager init for type matching in case of a prioritized post-processor.
boolean eager = !PriorityOrdered.class.isAssignableFrom(bw.getWrappedClass());
// 建立依赖描述对象
DependencyDescriptor desc = new AutowireByTypeDependencyDescriptor(methodParam, eager);
/*
* 下面的方法用于解析依赖。过程比较复杂，先把这里当作一个黑盒，咱们只要知道这
* 个方法能够帮咱们解析出合适的依赖便可。
*/
Object autowiredArgument = resolveDependency(desc, beanName, autowiredBeanNames, converter);
if (autowiredArgument != null) {
// 将解析出的 bean 存入到属性值列表（pvs）中
pvs.add(propertyName, autowiredArgument);
}
for (String autowiredBeanName : autowiredBeanNames) {
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);
}
}
}
如上所示，autowireByType 的代码自己并不复杂。和 autowireByName 同样，autowireByType 首先也是获取非简单类型属性的名称。而后再根据属性名获取属性描述符，并由属性描述符获取方法参数对象 MethodParameter，随后再根据 MethodParameter 对象获取依赖描述符对象，整个过程为 beanName → PropertyDescriptor → MethodParameter → DependencyDescriptor。在获取到依赖描述符对象后，再根据依赖描述符解析出合适的依赖。最后将解析出的结果存入属性列表 pvs 中便可。源码分析
关于 autowireByType 方法中出现的几种描述符对象，你们本身去看一下他们的实现吧，我就不分析了。接下来，咱们来分析一下解析依赖的方法 resolveDependency。以下：
public Object resolveDependency(DependencyDescriptor descriptor, String requestingBeanName,
Set<String> autowiredBeanNames, TypeConverter typeConverter) throws BeansException {
descriptor.initParameterNameDiscovery(getParameterNameDiscoverer());
if (javaUtilOptionalClass == descriptor.getDependencyType()) {
return new OptionalDependencyFactory().createOptionalDependency(descriptor, requestingBeanName);
}
else if (ObjectFactory.class == descriptor.getDependencyType() ||
ObjectProvider.class == descriptor.getDependencyType()) {
return new DependencyObjectProvider(descriptor, requestingBeanName);
}
else if (javaxInjectProviderClass == descriptor.getDependencyType()) {
return new Jsr330ProviderFactory().createDependencyProvider(descriptor, requestingBeanName);
}
else {
Object result = getAutowireCandidateResolver().getLazyResolutionProxyIfNecessary(
descriptor, requestingBeanName);
if (result == null) {
// 解析依赖
result = doResolveDependency(descriptor, requestingBeanName, autowiredBeanNames, typeConverter);
}
return result;
}
}
public Object doResolveDependency(DependencyDescriptor descriptor, String beanName,
Set<String> autowiredBeanNames, TypeConverter typeConverter) throws BeansException {
InjectionPoint previousInjectionPoint = ConstructorResolver.setCurrentInjectionPoint(descriptor);
try {
// 该方法最终调用了 beanFactory.getBean(String, Class)，从容器中获取依赖
Object shortcut = descriptor.resolveShortcut(this);
// 若是容器中存在所需依赖，这里进行断路操做，提早结束依赖解析逻辑
if (shortcut != null) {
return shortcut;
}
Class<?> type = descriptor.getDependencyType();
// 处理 @value 注解
Object 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()));
}
// 解析数组、list、map 等类型的依赖
Object multipleBeans = resolveMultipleBeans(descriptor, beanName, autowiredBeanNames, typeConverter);
if (multipleBeans != null) {
return multipleBeans;
}
/*
* 按类型查找候选列表，若是某个类型已经被实例化，则返回相应的实例。
* 好比下面的配置：
*
* <bean name="mongoDao" class="xyz.coolblog.autowire.MongoDao" primary="true"/>
* <bean name="service" class="xyz.coolblog.autowire.Service" autowire="byType"/>
* <bean name="mysqlDao" class="xyz.coolblog.autowire.MySqlDao"/>
*
* MongoDao 和 MySqlDao 均实现自 Dao 接口，Service 对象（不是接口）中有一个 Dao
* 类型的属性。如今根据类型自动注入 Dao 的实现类。这里有两个候选 bean，一个是
* mongoDao，另外一个是 mysqlDao，其中 mongoDao 在 service 以前实例化，
* mysqlDao 在 service 以后实例化。此时 findAutowireCandidates 方法会返回以下的结果：
*
* matchingBeans = [ <mongoDao, Object@MongoDao>, <mysqlDao, Class@MySqlDao> ]
*
* 注意 mysqlDao 还未实例化，因此返回的是 MySqlDao.class。
*
* findAutowireCandidates 这个方法逻辑比较复杂，我简单说一下它的工做流程吧，以下：
* 1. 从 BeanFactory 中获取某种类型 bean 的名称，好比上面的配置中
* mongoDao 和 mysqlDao 均实现了 Dao 接口，因此他们是同一种类型的 bean。
* 2. 遍历上一步获得的名称列表，并判断 bean 名称对应的 bean 是不是合适的候选项，
* 若合适则添加到候选列表中，并在最后返回候选列表
*
* findAutowireCandidates 比较复杂，我并未彻底搞懂，就不深刻分析了。见谅
*/
Map<String, Object> matchingBeans = findAutowireCandidates(beanName, type, descriptor);
if (matchingBeans.isEmpty()) {
if (isRequired(descriptor)) {
// 抛出 NoSuchBeanDefinitionException 异常
raiseNoMatchingBeanFound(type, descriptor.getResolvableType(), descriptor);
}
return null;
}
String autowiredBeanName;
Object instanceCandidate;
if (matchingBeans.size() > 1) {
/*
* matchingBeans.size() > 1，则代表存在多个可注入的候选项，这里判断使用哪个
* 候选项。好比下面的配置：
*
* <bean name="mongoDao" class="xyz.coolblog.autowire.MongoDao" primary="true"/>
* <bean name="mysqlDao" class="xyz.coolblog.autowire.MySqlDao"/>
*
* mongoDao 的配置中存在 primary 属性，因此 mongoDao 会被选为最终的候选项。如
* 果两个 bean 配置都没有 primary 属性，则须要根据优先级选择候选项。优先级这一块
* 的逻辑没细看，很少说了。
*/
autowiredBeanName = determineAutowireCandidate(matchingBeans, descriptor);
if (autowiredBeanName == null) {
if (isRequired(descriptor) || !indicatesMultipleBeans(type)) {
// 抛出 NoUniqueBeanDefinitionException 异常
return descriptor.resolveNotUnique(type, matchingBeans);
}
else {
return null;
}
}
// 根据解析出的 autowiredBeanName，获取相应的候选项
instanceCandidate = matchingBeans.get(autowiredBeanName);
}
else { // 只有一个候选项，直接取出来便可
Map.Entry<String, Object> entry = matchingBeans.entrySet().iterator().next();
autowiredBeanName = entry.getKey();
instanceCandidate = entry.getValue();
}
if (autowiredBeanNames != null) {
autowiredBeanNames.add(autowiredBeanName);
}
// 返回候选项实例，若是实例是 Class 类型，则调用 beanFactory.getBean(String, Class) 获取相应的 bean。不然直接返回便可
return (instanceCandidate instanceof Class ?
descriptor.resolveCandidate(autowiredBeanName, type, this) : instanceCandidate);
}
finally {
ConstructorResolver.setCurrentInjectionPoint(previousInjectionPoint);
}
}
由上面的代码能够看出，doResolveDependency 这个方法仍是挺复杂的。这里我就不继续分析 doResolveDependency 所调用的方法了，对于这些方法，我也是似懂非懂。好了，本节的最后咱们来总结一下 doResolveDependency 的执行流程吧，以下：
- 首先将 beanName 和 requiredType 做为参数，并尝试从 BeanFactory 中获取与此对于的 bean。若获取成功，就能够提早结束 doResolveDependency 的逻辑。
- 处理 @value 注解
- 解析数组、List、Map 等类型的依赖，若是解析结果不为空，则返回结果
- 根据类型查找合适的候选项
- 若是候选项的数量为0，则抛出异常。为1，直接从候选列表中取出便可。若候选项数量 > 1，则在多个候选项中肯定最优候选项，若没法肯定则抛出异常
- 若候选项是 Class 类型，代表候选项还没实例化，此时经过 BeanFactory.getBean 方法对其进行实例化。若候选项是非 Class 类型，则代表已经完成了实例化，此时直接返回便可。
好了，本节的内容先到这里。若是有分析错的地方，欢迎你们指出来。
2.4 applyPropertyValues 方法分析
通过了上面的流程，如今终于能够将属性值注入到 bean 对象中了。固然，这里还不能当即将属性值注入到对象中，由于在 Spring 配置文件中属性值都是以 String 类型进行配置的，因此 Spring 框架须要对 String 类型进行转换。除此以外，对于 ref 属性，这里还须要根据 ref 属性值解析依赖。还有一些其余操做，这里就很少说了，更多的信息咱们一块儿在源码探寻。
protected void applyPropertyValues(String beanName, BeanDefinition mbd, BeanWrapper bw, PropertyValues pvs) {
if (pvs == null || pvs.isEmpty()) {
return;
}
if (System.getSecurityManager() != null && bw instanceof BeanWrapperImpl) {
((BeanWrapperImpl) bw).setSecurityContext(getAccessControlContext());
}
MutablePropertyValues mpvs = null;
List<PropertyValue> original;
if (pvs instanceof MutablePropertyValues) {
mpvs = (MutablePropertyValues) pvs;
// 若是属性列表 pvs 被转换过，则直接返回便可
if (mpvs.isConverted()) {
try {
bw.setPropertyValues(mpvs);
return;
}
catch (BeansException ex) {
throw new BeanCreationException(
mbd.getResourceDescription(), beanName, "Error setting property values", ex);
}
}
original = mpvs.getPropertyValueList();
}
else {
original = Arrays.asList(pvs.getPropertyValues());
}
TypeConverter converter = getCustomTypeConverter();
if (converter == null) {
converter = bw;
}
BeanDefinitionValueResolver valueResolver = new BeanDefinitionValueResolver(this, beanName, mbd, converter);
List<PropertyValue> deepCopy = new ArrayList<PropertyValue>(original.size());
boolean resolveNecessary = false;
// 遍历属性列表
for (PropertyValue pv : original) {
// 若是属性值被转换过，则就不须要再次转换
if (pv.isConverted()) {
deepCopy.add(pv);
}
else {
String propertyName = pv.getName();
Object originalValue = pv.getValue();
/*
* 解析属性值。举例说明，先看下面的配置：
*
* <bean id="macbook" class="MacBookPro">
* <property name="manufacturer" value="Apple"/>
* <property name="width" value="280"/>
* <property name="cpu" ref="cpu"/>
* <property name="interface">
* <list>
* <value>USB</value>
* <value>HDMI</value>
* <value>Thunderbolt</value>
* </list>
* </property>
* </bean>
*
* 上面是一款电脑的配置信息，每一个 property 配置通过下面的方法解析后，返回以下结果：
* propertyName = "manufacturer", resolvedValue = "Apple"
* propertyName = "width", resolvedValue = "280"
* propertyName = "cpu", resolvedValue = "CPU@1234" 注：resolvedValue 是一个对象
* propertyName = "interface", resolvedValue = ["USB", "HDMI", "Thunderbolt"]
*
* 如上所示，resolveValueIfNecessary 会将 ref 解析为具体的对象，将 <list>
* 标签转换为 List 对象等。对于 int 类型的配置，这里并未作转换，因此
* width = "280"，仍是字符串。除了解析上面几种类型，该方法还会解析 <set/>、
* <map/>、<array/> 等集合配置
*/
Object resolvedValue = valueResolver.resolveValueIfNecessary(pv, originalValue);
Object convertedValue = resolvedValue;
/*
* convertible 表示属性值是否可转换，由两个条件合成而来。第一个条件不难理解，解释
* 一下第二个条件。第二个条件用于检测 propertyName 是不是 nested 或者 indexed，
* 直接举例说明吧：
*
* public class Room {
* private Door door = new Door();
* }
*
* room 对象里面包含了 door 对象，若是咱们想向 door 对象中注入属性值，则能够这样配置：
*
* <bean id="room" class="xyz.coolblog.Room">
* <property name="door.width" value="123"/>
* </bean>
*
* isNestedOrIndexedProperty 会根据 propertyName 中是否包含 . 或 [ 返回
* true 和 false。包含则返回 true，不然返回 false。关于 nested 类型的属性，我
* 没在实践中用过，因此不知道上面举的例子是否是合理。若不合理，欢迎指正，也请多多指教。
* 关于 nested 类型的属性，你们还能够参考 Spring 的官方文档：
* https://docs.spring.io/spring/docs/4.3.17.RELEASE/spring-framework-reference/htmlsingle/#beans-beans-conventions
*/
boolean convertible = bw.isWritableProperty(propertyName) &&
!PropertyAccessorUtils.isNestedOrIndexedProperty(propertyName);
// 对于通常的属性，convertible 一般为 true
if (convertible) {
// 对属性值的类型进行转换，好比将 String 类型的属性值 "123" 转为 Integer 类型的 123
convertedValue = convertForProperty(resolvedValue, propertyName, bw, converter);
}
/*
* 若是 originalValue 是经过 autowireByType 或 autowireByName 解析而来，
* 那么此处条件成立，即 (resolvedValue == originalValue) = true
*/
if (resolvedValue == originalValue) {
if (convertible) {
// 将 convertedValue 设置到 pv 中，后续再次建立同一个 bean 时，就无需再次进行转换了
pv.setConvertedValue(convertedValue);
}
deepCopy.add(pv);
}
/*
* 若是原始值 originalValue 是 TypedStringValue，且转换后的值
* convertedValue 不是 Collection 或数组类型，则将转换后的值存入到 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();
}
try {
// 将全部的属性值设置到 bean 实例中
bw.setPropertyValues(new MutablePropertyValues(deepCopy));
}
catch (BeansException ex) {
throw new BeanCreationException(
mbd.getResourceDescription(), beanName, "Error setting property values", ex);
}
}
以上就是 applyPropertyValues 方法的源码，配合着我写的注释，应该能够理解这个方法的流程。这个方法也调用了不少其余的方法，若是你们跟下去的话，会发现这些方法的调用栈也是很深的，比较复杂。这里说一下 bw.setPropertyValues 这个方法，若是你们跟到这个方法的调用栈的最底部，会发现这个方法是经过调用对象的 setter 方法进行属性设置的。这里贴一下简化后的代码：
public class BeanWrapperImpl extends AbstractNestablePropertyAccessor implements BeanWrapper {
// 省略部分代码
private class BeanPropertyHandler extends PropertyHandler {
@Override
public void setValue(final Object object, Object valueToApply) throws Exception {
// 获取 writeMethod，也就是 setter 方法
final Method writeMethod = this.pd.getWriteMethod();
if (!Modifier.isPublic(writeMethod.getDeclaringClass().getModifiers()) && !writeMethod.isAccessible()) {
writeMethod.setAccessible(true);
}
final Object value = valueToApply;
// 调用 setter 方法，getWrappedInstance() 返回的是 bean 对象
writeMethod.invoke(getWrappedInstance(), value);
}
}
}
好了，本节的最后来总结一下 applyPropertyValues 方法的执行流程吧，以下：
- 检测属性值列表是否已转换过的，若转换过，则直接填充属性，无需再次转换
- 遍历属性值列表 pvs，解析原始值 originalValue，获得解析值 resolvedValue
- 对解析后的属性值 resolvedValue 进行类型转换
- 将类型转换后的属性值设置到 PropertyValue 对象中，并将 PropertyValue 对象存入 deepCopy 集合中
- 将 deepCopy 中的属性信息注入到 bean 对象中
3. 总结
本文对 populateBean 方法及其所调用的 autowireByName、autowireByType 和 applyPropertyValues 作了较为详细的分析，不知道你们看完后感受如何。我说一下个人感觉吧，从我看 Spring IOC 部分的源码到如今写了5篇关于 IOC 部分的源码分析文章，整体感受 Spring 的源码仍是很复杂的，调用层次很深。若是想对源码有一个比较好的理解，须要很多的时间去分析，调试源码。总的来讲，不容易。固然，个人水平有限。若是你们本身去阅读源码，可能会以为也没这么难啊。
好了，其余的就很少说了。若是本文中有分析错的地方，欢迎你们指正。最后感谢你们的阅读。
本文在知识共享许可协议 4.0 下发布，转载需在明显位置处注明出处
做者：coolblog.xyz
本文同步发布在个人我的博客： http://www.coolblog.xyz
附录：Spring 源码分析文章列表
Ⅰ. IOC
| 更新时间 | 标题 |
|---|---|
| 2018-05-30 | Spring IOC 容器源码分析系列文章导读 |
| 2018-06-01 | Spring IOC 容器源码分析 - 获取单例 bean |
| 2018-06-04 | Spring IOC 容器源码分析 - 建立单例 bean 的过程 |
| 2018-06-06 | Spring IOC 容器源码分析 - 建立原始 bean 对象 |
| 2018-06-08 | Spring IOC 容器源码分析 - 循环依赖的解决办法 |
| 2018-06-11 | Spring IOC 容器源码分析 - 填充属性到 bean 原始对象 |
| 2018-06-11 | Spring IOC 容器源码分析 - 余下的初始化工做 |
Ⅱ. AOP
| 更新时间 | 标题 |
|---|---|
| 2018-06-17 | Spring AOP 源码分析系列文章导读 |
| 2018-06-20 | Spring AOP 源码分析 - 筛选合适的通知器 |
| 2018-06-20 | Spring AOP 源码分析 - 建立代理对象 |
| 2018-06-22 | Spring AOP 源码分析 - 拦截器链的执行过程 |
Ⅲ. MVC
| 更新时间 | 标题 |
|---|---|
| 2018-06-29 | Spring MVC 原理探秘 - 一个请求的旅行过程 |
| 2018-06-30 | Spring MVC 原理探秘 - 容器的建立过程 |
本做品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。
相关文章
- 1. Spring IOC 容器源码分析 - 填充属性到 bean 原始对象
- 2. spring-IOC容器源码分析（一）bean初始化流程
- 3. 死磕Spring之IoC篇 - Bean 的属性填充阶段
- 4. Spring 源码九（属性填充）
- 5. 最简 Spring IOC 容器源码分析
- 6. Spring 源码分析（二）之 Spring IOC 容器源码分析
- 7. 转载-Spring IOC 容器源码分析
- 8. Spring IOC 容器源码分析
- 9. 一 spring源码分析--- IOC容器
- 10. 【spring源码分析】IOC容器初始化（十一）
- 更多相关文章...
- • Spring IoC容器：BeanFactory和ApplicationContext - Spring教程
- • Spring Bean的配置及常用属性 - Spring教程
- • 互联网组织的未来：剖析GitHub员工的任性之源
- • Docker容器实战(六) - 容器的隔离与限制
相关标签/搜索
每日一句
-
每一个你不满意的现在，都有一个你没有努力的曾经。
欢迎关注本站公众号,获取更多信息
