这篇文章,我们来谈一谈Spring中的属性注入


本系列文章:

读源码,我们可以从第一行读起

你知道Spring是怎么解析配置类的吗?

配置类为什么要添加@Configuration注解?

谈谈Spring中的对象跟Bean,你知道Spring怎么创建对象的吗?

推荐阅读:

Spring官网阅读 | 总结篇

Spring杂谈

本系列文章将会带你一行行的将Spring的源码吃透,推荐阅读的文章是阅读源码的基础!

前言

在前面的文章中已经知道了Spring是如何将一个对象创建出来的,那么紧接着,Spring就需要将这个对象变成一个真正的Bean了,这个过程主要分为两步

  1. 属性注入
  2. 初始化

在这两个过程中,Bean的后置处理器会穿插执行,其中有些后置处理器是为了帮助完成属性注入或者初始化的,而有些后置处理器是Spring提供给程序员进行扩展的,当然,这二者并不冲突。整个Spring创建对象并将对象变成Bean的过程就是我们经常提到了Spring中Bean的生命周期。当然,本系列源码分析的文章不会再对生命周期的概念做过多阐述了,如果大家有这方面的需求的话可以参考我之前的文章,或者关注我的公众号:程序员DMZ

Spring官网阅读(九)Spring中Bean的生命周期(上)

Spring官网阅读(十)Spring中Bean的生命周期(下)

源码分析

闲话不再多说,我们正式进入源码分析阶段,本文重点要分析的方法就是org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory#doCreateBean,其源码如下:

doCreateBean

	protected Object doCreateBean(final String beanName, final RootBeanDefinition mbd, final @Nullable Object[] args)
			throws BeanCreationException {

		// 创建对象的过程在上篇文章中我们已经介绍过了,这里不再赘述
		BeanWrapper instanceWrapper = null;
		if (mbd.isSingleton()) {
			instanceWrapper = this.factoryBeanInstanceCache.remove(beanName);
		}
		if (instanceWrapper == null) {
			instanceWrapper = createBeanInstance(beanName, mbd, args);
		}
        
        // 获取到创建的这个对象
		final Object bean = instanceWrapper.getWrappedInstance();
		Class<?> beanType = instanceWrapper.getWrappedClass();
		if (beanType != NullBean.class) {
			mbd.resolvedTargetType = beanType;
		}

		// Allow post-processors to modify the merged bean definition.
        // 按照官方的注释来说,这个地方是Spring提供的一个扩展点,对程序员而言,我们可以通过一个实现了MergedBeanDefinitionPostProcessor的后置处理器来修改bd中的属性,从而影响到后续的Bean的生命周期
        // 不过官方自己实现的后置处理器并没有去修改bd,而是调用了applyMergedBeanDefinitionPostProcessors方法
        // 这个方法名直译过来就是-应用合并后的bd,也就是说它这里只是对bd做了进一步的使用而没有真正的修改
		synchronized (mbd.postProcessingLock) {
           // bd只允许被处理一次
			if (!mbd.postProcessed) {
				try {
                    // 应用合并后的bd
					applyMergedBeanDefinitionPostProcessors(mbd, beanType, beanName);
				}
				catch (Throwable ex) {
					throw new BeanCreationException(mbd.getResourceDescription(), beanName,
							"Post-processing of merged bean definition failed", ex);
				}
                // 标注这个bd已经被MergedBeanDefinitionPostProcessor的后置处理器处理过
                // 那么在第二次创建Bean的时候,不会再次调用applyMergedBeanDefinitionPostProcessors
				mbd.postProcessed = true;
			}
		}

		// 这里是用来出来循环依赖的,关于循环以来,在介绍完正常的Bean的创建后,单独用一篇文章说明
        // 这里不做过多解释
		boolean earlySingletonExposure = (mbd.isSingleton() && this.allowCircularReferences &&
				isSingletonCurrentlyInCreation(beanName));
		if (earlySingletonExposure) {
			if (logger.isTraceEnabled()) {
				logger.trace("Eagerly caching bean '" + beanName +
						"' to allow for resolving potential circular references");
			}
			addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));
		}


		Object exposedObject = bean;
		try {
            // 我们这篇文章重点要分析的就是populateBean方法,在这个方法中完成了属性注入
			populateBean(beanName, mbd, instanceWrapper);
            // 初始化
			exposedObject = initializeBean(beanName, exposedObject, mbd);
		}
		catch (Throwable ex) {
			// 省略异常代码
		}

		// 后续代码不在本文探讨范围内了,暂不考虑

		return exposedObject;
	}

applyMergedBeanDefinitionPostProcessors

源码如下:

// 可以看到这个方法的代码还是很简单的,就是调用了MergedBeanDefinitionPostProcessor的postProcessMergedBeanDefinition方法
protected void applyMergedBeanDefinitionPostProcessors(RootBeanDefinition mbd, Class<?> beanType, String beanName) {
    for (BeanPostProcessor bp : getBeanPostProcessors()) {
        if (bp instanceof MergedBeanDefinitionPostProcessor) {
            MergedBeanDefinitionPostProcessor bdp = (MergedBeanDefinitionPostProcessor) bp;
            bdp.postProcessMergedBeanDefinition(mbd, beanType, beanName);
        }
    }
}

这个时候我们就要思考一个问题,容器中现在有哪些后置处理器是MergedBeanDefinitionPostProcessor呢?

image-20200613200058693

查看这个方法的实现类我们会发现总共就这么几个类实现了MergedBeanDefinitionPostProcessor接口。实际上除了ApplicationListenerDetector之外,其余的后置处理器的逻辑都差不多。我们在这里我们主要就分析两个后置处理

  1. ApplicationListenerDetector
  2. AutowiredAnnotationBeanPostProcessor

ApplicationListenerDetector

首先,我们来ApplicationListenerDetector,这个类在之前的文章中也多次提到过了,它的作用是用来处理嵌套Bean的情况,主要是保证能将嵌套在Bean标签中的ApplicationListener也能添加到容器的监听器集合中去。我们先通过一个例子来感受下这个后置处理器的作用吧

配置文件:


<beans xmlns="http://www.springframework.org/schema/beans"
	   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	   xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">

	<bean class="com.dmz.source.populate.service.DmzService" id="dmzService">
		<constructor-arg name="orderService">
			<bean class="com.dmz.source.populate.service.OrderService"/>
		constructor-arg>
	bean>
beans>

示例代码:

// 事件
public class DmzEvent extends ApplicationEvent {
	public DmzEvent(Object source) {
		super(source);
	}
}

public class DmzService {

	OrderService orderService;

	public DmzService(OrderService orderService) {
		this.orderService = orderService;
	}
}
// 实现ApplicationListener接口
public class OrderService implements ApplicationListener<DmzEvent> {
	@Override
	public void onApplicationEvent(DmzEvent event) {
		System.out.println(event.getSource());
	}
}

public class Main {
	public static void main(String[] args) {
		ClassPathXmlApplicationContext cc = new ClassPathXmlApplicationContext("application-populate.xml");
		cc.publishEvent(new DmzEvent("my name is dmz"));
	}
}

// 程序运行结果,控制台打印:my name is dmz

说明OrderService已经被添加到了容器的监听器集合中。但是请注意,在这种情况下,如果要使OrderService能够执行监听的逻辑,必须要满足下面这两个条件

  • 外部的Bean要是单例的,对于我们的例子而言就是dmzService
  • 内嵌的Bean也必须是单例的,在上面的例子中也就是orderService必须是单例

另外需要注意的是,这种嵌套的Bean比较特殊,它虽然由Spring创建,但是确不存在于容器中,就是说我们不能将其作为依赖注入到别的Bean中。

AutowiredAnnotationBeanPostProcessor

对应源码如下:

public void postProcessMergedBeanDefinition(RootBeanDefinition beanDefinition, Class<?> beanType, String beanName) {
    // 找到注入的元数据,第一次是构建,后续可以直接从缓存中拿
    // 注解元数据其实就是当前这个类中的所有需要进行注入的“点”的集合,
    // 注入点(InjectedElement)包含两种,字段/方法
    // 对应的就是AutowiredFieldElement/AutowiredMethodElement
    InjectionMetadata metadata = findAutowiringMetadata(beanName, beanType, null);
    // 排除掉被外部管理的注入点
    metadata.checkConfigMembers(beanDefinition);
}

上面代码的核心逻辑就是

  • 找到所有的注入点,其实就是被@Autowired注解修饰的方法以及字段,同时静态的方法以及字段也会被排除
  • 排除掉被外部管理的注入点,在后续的源码分析中我们再细说

findAutowiringMetadata

// 这个方法的核心逻辑就是先从缓存中获取已经解析好的注入点信息,很明显,在原型情况下才会使用缓存
// 创建注入点的核心逻辑在buildAutowiringMetadata方法中
private InjectionMetadata findAutowiringMetadata(String beanName, Class<?> clazz, @Nullable PropertyValues pvs) {
    String cacheKey = (StringUtils.hasLength(beanName) ? beanName : clazz.getName());
    InjectionMetadata metadata = this.injectionMetadataCache.get(cacheKey);
    // 可能我们会修改bd中的class属性,那么InjectionMetadata中的注入点信息也需要刷新
    if (InjectionMetadata.needsRefresh(metadata, clazz)) {
        synchronized (this.injectionMetadataCache) {
            metadata = this.injectionMetadataCache.get(cacheKey);
            if (InjectionMetadata.needsRefresh(metadata, clazz)) {
                if (metadata != null) {
                    metadata.clear(pvs);
                }
                // 这里真正创建注入点
                metadata = buildAutowiringMetadata(clazz);
                this.injectionMetadataCache.put(cacheKey, metadata);
            }
        }
    }
    return metadata;
}

buildAutowiringMetadata

// 我们应用中使用@Autowired注解标注在字段上或者setter方法能够完成属性注入
// 就是因为这个方法将@Autowired注解标注的方法以及字段封装成InjectionMetadata
// 在后续阶段会调用InjectionMetadata的inject方法进行注入
private InjectionMetadata buildAutowiringMetadata(final Class<?> clazz) {
    List<InjectionMetadata.InjectedElement> elements = new ArrayList<>();
    Class<?> targetClass = clazz;

    do {
        final List<InjectionMetadata.InjectedElement> currElements = new ArrayList<>();
		// 处理所有的被@AutoWired/@Value注解标注的字段
        ReflectionUtils.doWithLocalFields(targetClass, field -> {
            AnnotationAttributes ann = findAutowiredAnnotation(field);
            if (ann != null) {
                // 静态字段会直接跳过
                if (Modifier.isStatic(field.getModifiers())) {
                    // 省略日志打印
                    return;
                }
                // 得到@AutoWired注解中的required属性
                boolean required = determineRequiredStatus(ann);
                currElements.add(new AutowiredFieldElement(field, required));
            }
        });
		// 处理所有的被@AutoWired注解标注的方法,相对于字段而言,这里需要对桥接方法进行特殊处理
        ReflectionUtils.doWithLocalMethods(targetClass, method -> {
            // 只处理一种特殊的桥接场景,其余的桥接方法都会被忽略
            Method bridgedMethod = BridgeMethodResolver.findBridgedMethod(method);
            if (!BridgeMethodResolver.isVisibilityBridgeMethodPair(method, bridgedMethod)) {
                return;
            }
            AnnotationAttributes ann = findAutowiredAnnotation(bridgedMethod);
            // 处理方法时需要注意,当父类中的方法被子类重写时,如果子父类中的方法都加了@Autowired
            // 那么此时父类方法不能被处理,即不能被封装成一个AutowiredMethodElement
            if (ann != null && method.equals(ClassUtils.getMostSpecificMethod(method, clazz))) {
                if (Modifier.isStatic(method.getModifiers())) {
                    // 省略日志打印
                    return;
                }
                if (method.getParameterCount() == 0) {
                    // 当方法的参数数量为0时,虽然不需要进行注入,但是还是会把这个方法作为注入点使用
                    // 这个方法最终还是会被调用
                    if (logger.isInfoEnabled()) {
                        logger.info("Autowired annotation should only be used on methods with parameters: " +
                                    method);
                    }
                }
                boolean required = determineRequiredStatus(ann);
                // PropertyDescriptor: 属性描述符
                // 就是通过解析getter/setter方法,例如void getA()会解析得到一个属性名称为a
                // readMethod为getA的PropertyDescriptor,
                // 在《Spring官网阅读(十四)Spring中的BeanWrapper及类型转换》文中已经做过解释
                // 这里不再赘述,这里之所以来这么一次查找是因为当XML中对这个属性进行了配置后,
                // 那么就不会进行自动注入了,XML中显示指定的属性优先级高于注解
                PropertyDescriptor pd = BeanUtils.findPropertyForMethod(bridgedMethod, clazz);		   // 构造一个对应的AutowiredMethodElement,后续这个方法会被执行
                // 方法的参数会被自动注入,这里不限于setter方法
                currElements.add(new AutowiredMethodElement(method, required, pd));
            }
        });
		// 会处理父类中字段上及方法上的@AutoWired注解,并且父类的优先级比子类高
        elements.addAll(0, currElements);
        targetClass = targetClass.getSuperclass();
    }
    while (targetClass != null && targetClass != Object.class);

    return new InjectionMetadata(clazz, elements);
}
难点代码分析

上面的代码整体来说应该很简单,就如我们之前所说的,处理带有@Autowired注解的字段及方法,同时会过滤掉所有的静态字段及方法。上面复杂的地方在于对桥接方法的处理,可能大部分人都没办法理解这几行代码:

// 第一行
Method bridgedMethod = BridgeMethodResolver.findBridgedMethod(method);

// 第二行
if (!BridgeMethodResolver.isVisibilityBridgeMethodPair(method, bridgedMethod)) {
    return;
}

// 第三行
if (ann != null && method.equals(ClassUtils.getMostSpecificMethod(method, clazz))) {

}

要理解这些代码,首先你得知道什么是桥接,为此我已经写好了一篇文章:

Spring杂谈 | 从桥接方法到JVM方法调用

除了在上面的文章中提到的桥接方法外,还有一种特殊的情况

// A类跟B类在同一个包下,A不是public的
class A {
	public void test(){

	}
}

// 在B中会生成一个跟A中的方法描述符(参数+返回值)一模一样的桥接方法
// 这个桥接方法实际上就是调用父类中的方法
// 具体可以参考:https://bugs.java.com/bugdatabase/view_bug.do?bug_id=63424113
public class B extends A {
}

在理解了什么是桥接之后,那么上边的第一行代码你应该就能看懂了,就以上面的代码为例,B中会生成一个桥接方法,对应的被桥接的方法就是A中的test方法。

接着,我们看看第二行代码

public static boolean isVisibilityBridgeMethodPair(Method bridgeMethod, Method bridgedMethod) {
    // 说明这个方法本身就不是桥接方法,直接返回true
    if (bridgeMethod == bridgedMethod) {
        return true;
    }
    // 说明是桥接方法,并且方法描述符一致
    // 当且仅当是上面例子中描述的这种桥接的时候这个判断才会满足
    // 正常来说桥接方法跟被桥接方法的返回值+参数类型肯定不一致
    // 所以这个判断会过滤掉其余的所有类型的桥接方法
    // 只会保留本文提及这种特殊情况下产生的桥接方法
    return (bridgeMethod.getReturnType().equals(bridgedMethod.getReturnType()) &&
            Arrays.equals(bridgeMethod.getParameterTypes(), bridgedMethod.getParameterTypes()));
}

最后,再来看看第三行代码,核心就是这句method.equals(ClassUtils.getMostSpecificMethod(method, clazz)。这句代码的主要目的就是为了处理下面这种情况

@Component
public class D extends C {

	@Autowired
	@Override
	public void setDmzService(DmzService dmzService) {
		dmzService.init();
		this.dmzService = dmzService;
	}
}

// C不是Spring中的组件
public class C {
	DmzService dmzService;
    @Autowired
	public void setDmzService(DmzService dmzService) {
		this.dmzService = dmzService;
	}
}

这种情况下,在处理D中的@Autowired注解时,虽然我们要处理父类中的@Autowired注解,但是因为子类中的方法已经复写了父类中的方法,所以此时应该要跳过父类中的这个被复写的方法,这就是第三行代码的作用。

小结

到这里我们主要分析了applyMergedBeanDefinitionPostProcessors这段代码的作用,它的执行时机是在创建对象之后,属性注入之前。按照官方的定义来说,到这里我们仍然可以使用这个方法来修改bd的定义,那么相对于通过BeanFactoryPostProcessor的方式修改bd,applyMergedBeanDefinitionPostProcessors这个方法影响的范围更小,BeanFactoryPostProcessor影响的是整个Bean的生命周期,而applyMergedBeanDefinitionPostProcessors只会影响属性注入之后的生命周期。

其次,我们分析了Spring中内置的MergedBeanDefinitionPostProcessor,选取了其中两个特殊的后置处理器进行分析,其中ApplicationListenerDetector主要处理内嵌的事件监听器,而AutowiredAnnotationBeanPostProcessor主要用于处理@Autowired注解,实际上我们会发现,到这里还只是完成了@Autowired注解的解析,还没有真正开始进行注入,真正注入的逻辑在后面我们要分析的populateBean方法中,在这个方法中会使用解析好的注入元信息完成真正的属性注入,那么接下来我们就开始分析populateBean这个方法的源码。

populateBean

循环依赖的代码我们暂且跳过,后续出一篇专门文章解读循环依赖,我们直接看看populateBean到底做了什么。

protected void populateBean(String beanName, RootBeanDefinition mbd, @Nullable BeanWrapper bw) {

    // 处理空实例
    if (bw == null) {
        // 如果创建的对象为空,但是在XML中又配置了需要注入的属性的话,那么直接报错
        if (mbd.hasPropertyValues()) {
            throw new BeanCreationException(
                mbd.getResourceDescription(), beanName, "Cannot apply property values to null instance");
        }
        else {
            // 空对象,不进行属性注入
            return;
        }
    }

    // 满足两个条件,不是合成类 && 存在InstantiationAwareBeanPostProcessor
    // 其中InstantiationAwareBeanPostProcessor主要作用就是作为Bean的实例化前后的钩子
    // 外加完成属性注入,对于三个方法就是
    // postProcessBeforeInstantiation  创建对象前调用
    // postProcessAfterInstantiation   对象创建完成,@AutoWired注解解析后调用   
    // postProcessPropertyValues(已过期,被postProcessProperties替代) 进行属性注入
    // 下面这段代码的主要作用就是我们可以提供一个InstantiationAwareBeanPostProcessor
    // 提供的这个后置处理如果实现了postProcessAfterInstantiation方法并且返回false
    // 那么可以跳过Spring默认的属性注入,但是这也意味着我们要自己去实现属性注入的逻辑
    // 所以一般情况下,我们也不会这么去扩展
    if (!mbd.isSynthetic() && hasInstantiationAwareBeanPostProcessors()) {
        for (BeanPostProcessor bp : getBeanPostProcessors()) {
            if (bp instanceof InstantiationAwareBeanPostProcessor) {
                InstantiationAwareBeanPostProcessor ibp = (InstantiationAwareBeanPostProcessor) bp;
                if (!ibp