@Autowired注解的实现原理

时间  2019-11-06
标签 autowired 注解 实现 原理 繁體版
原文   原文链接

扫描下方二维码或者微信搜索公众号菜鸟飞呀飞，便可关注微信公众号，阅读更多Spring源码分析和Java并发编程文章。java

微信公众号

1. 问题

在平时工做中，只要是作Java开发，基本都离不开Spring框架，Spring的一大核心功能就是IOC，它能帮助咱们实现自动装配，基本上天天咱们都会使用到@Autowired注解来为咱们自动装配属性，那么你知道Autowired注解的原理吗？在阅读本文以前，能够先思考一下如下几个问题。spring

  • @Autowired注解是如何实现自动装配的？
  • 当为类型为A的Bean装配类型为B的属性时，若是此时Spring容器中存在多个类型为B的bean，此时Spring是如何处理的？
  • 自动装配的模型是什么？有哪几种？和Autowired注解有什么关联？

2. Demo

先按照以下示例搭建一下本文的demo工程sql

  • pom依赖
<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-context</artifactId>
    <version>5.1.8.RELEASE</version>
</dependency>
复制代码
  • 配置类，在配置类中指定扫描哪些包下的文件
@Configuration
@ComponentScan("com.tiantang.study")
public class AppConfig {
}
复制代码
  • 定义两个service接口以及实现类，而后在OrderServiceImpl中为其注入UserService的实现类
public interface UserService {
}
复制代码
@Service
public class UserServiceImpl implements UserService {
}
复制代码
public interface OrderService {

	void query();

}
复制代码
@Service
public class OrderServiceImpl implements OrderService {

	@Autowired
	private UserService userService;

	public void query(){
		System.out.println(userService);
	}
}
复制代码
  • 启动类，在启动类中经过调用getBean()方法获取到OrderService类，而后调用query()方法，在query()方法中会打印注入的UserService对象
public class MainApplication {

	public static void main(String[] args) {
		AnnotationConfigApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class);
		OrderService orderService = applicationContext.getBean(OrderService.class);
		orderService.query();
	}
}
复制代码
  • 运行main()方法，最终会在query()方法中打印出UserService对象。

3. 实现原理：AutowiredAnnotationBeanPostProcessor

经过上面的demo咱们完成了对OrderServiceImpl的自动装配，为其属性userService完成了赋值操做，那么Spring是如何经过@Autowired来实现赋值的呢？咱们知道，Spring在容器启动阶段，会先实例化bean，而后再对bean进行初始化操做。在初始化阶段，会经过调用Bean后置处理来完成对属性的赋值等操做，那么同理，要想实现@Autowired的功能，确定也是经过后置处理器来完成的。这个后置处理器就是AutowiredAnnotationBeanPostProcessor。接下来咱们就来看看这个类的源码。编程

3.1 什么时候被加入

  • 在分析AutowiredAnnotationBeanPostProcessor的工做原理以前，咱们须要先知道它是什么时候被加入到Spring容器当中的。毕竟只有先将它放入到容器中了，才能让它工做。
  • 当咱们调用AnnotationConfigApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class)启动容器的时候，在构造方法中会调用到this()方法，在this()方法中最终会调用到registerAnnotationConfigProcessors()方法，在该方法中，Spring会向容器注册7个Spring内置的Bean，其中就包括AutowiredAnnotationBeanPostProcessor。若是想详细了解Spring容器的启动过程，能够参考笔者的另外一篇文章：Spring源码系列之容器启动流程
public static Set<BeanDefinitionHolder> registerAnnotationConfigProcessors( BeanDefinitionRegistry registry, @Nullable Object source) {

	// 省略部分代码...
	
	Set<BeanDefinitionHolder> beanDefs = new LinkedHashSet<>(8);
	// 注册AutowiredAnnotationBeanPostProcessor,这个bean的后置处理器用来处理@Autowired的注入
	if (!registry.containsBeanDefinition(AUTOWIRED_ANNOTATION_PROCESSOR_BEAN_NAME)) {
		RootBeanDefinition def = new RootBeanDefinition(AutowiredAnnotationBeanPostProcessor.class);
		def.setSource(source);
		beanDefs.add(registerPostProcessor(registry, def, AUTOWIRED_ANNOTATION_PROCESSOR_BEAN_NAME));
	}

	// 注册CommonAnnotationBeanPostProcessor，用来处理如@Resource等符合JSR-250规范的注解
	if (jsr250Present && !registry.containsBeanDefinition(COMMON_ANNOTATION_PROCESSOR_BEAN_NAME)) {
		RootBeanDefinition def = new RootBeanDefinition(CommonAnnotationBeanPostProcessor.class);
		def.setSource(source);
		beanDefs.add(registerPostProcessor(registry, def, COMMON_ANNOTATION_PROCESSOR_BEAN_NAME));
	}
	return beanDefs;
}
复制代码

3.2 什么时候被调用

AutowiredAnnotationBeanPostProcessor是什么时候被调用的呢？数组

  • Spring在建立bean的过程当中，最终会调用到doCreateBean()方法，在doCreateBean()方法中会调用populateBean()方法，来为bean进行属性填充，完成自动装配等工做。populateBean()方法的部分源码以下。
protected void populateBean(String beanName, RootBeanDefinition mbd, @Nullable BeanWrapper bw) {
	if (hasInstAwareBpps || needsDepCheck) {
		if (pvs == null) {
			pvs = mbd.getPropertyValues();
		}
		PropertyDescriptor[] filteredPds = filterPropertyDescriptorsForDependencyCheck(bw, mbd.allowCaching);
		if (hasInstAwareBpps) {
			for (BeanPostProcessor bp : getBeanPostProcessors()) {
				if (bp instanceof InstantiationAwareBeanPostProcessor) {
					InstantiationAwareBeanPostProcessor ibp = (InstantiationAwareBeanPostProcessor) bp;
					// 执行后置处理器，填充属性，完成自动装配
					// 在这里会调用到AutowiredAnnotationBeanPostProcessor
					pvs = ibp.postProcessPropertyValues(pvs, filteredPds, bw.getWrappedInstance(), beanName);
					if (pvs == null) {
						return;
					}
				}
			}
		}
	}
}
复制代码
  • 在populateBean()方法中一共调用了两次后置处理器，第一次是为了判断是否须要属性填充，若是不须要进行属性填充，那么就会直接进行return，若是须要进行属性填充，那么方法就会继续向下执行，后面会进行第二次后置处理器的调用，这个时候，就会调用到AutowiredAnnotationBeanPostProcessor的postProcessPropertyValues()方法，在该方法中就会进行@Autowired注解的解析，而后实现自动装配。（注意：上面的源码中，只贴出了执行一次后置处理器的代码，另一次被省略了）。
  • postProcessorPropertyValues()方法的源码以下，在该方法中，会先调用findAutowiringMetadata()方法解析出bean中带有@Autowired注解、@Inject和@Value注解的属性和方法。而后调用metadata.inject()方法，进行属性填充。
public PropertyValues postProcessPropertyValues( PropertyValues pvs, PropertyDescriptor[] pds, Object bean, String beanName) throws BeanCreationException {
	// 解析出bean中带有@Autowired注解、@Inject和@Value注解的属性和方法
	// 对于本文的demo而言，在此处就会解析出OrderServiceImpl类上的userService属性
	// 至于如何解析的，findAutowiringMetadata()方法比较复杂，这里就不展开了，Spring中提供了不少对注解等元数据信息读取的方法，进行了大量的封装。
	// 若是不是本身亲自参与开发Spring的话，很难摸透它封装的那些数据结构。
	InjectionMetadata metadata = findAutowiringMetadata(beanName, bean.getClass(), pvs);
	try {
		// 自动装配，实现依赖注入
		metadata.inject(bean, beanName, pvs);
	}
	catch (BeanCreationException ex) {
		throw ex;
	}
	catch (Throwable ex) {
		throw new BeanCreationException(beanName, "Injection of autowired dependencies failed", ex);
	}
	return pvs;
}
复制代码

3.2.1 findAutowiringMetadata()

  • 为何上面分析时，只说了findAutowiringMetadata()方法会解析出Autowired注解、@Inject和@Value注解呢？这是由于在AutowiredAnnotationBeanPostProcessor中定义了这样一个全局变量：
private final Set<Class<? extends Annotation>> autowiredAnnotationTypes = new LinkedHashSet<>(4);
复制代码
  • 这个全局变量在AutowiredAnnotationBeanPostProcessor的构造方法中进行了初始化。初始化时，只向这个set集合中添加了三个元素：@Autowired、@Inject、@Value。其中@Inject注解是JSR-330规范中的注解。当调用findAutowiringMetadata()方法时，会根据autowiredAnnotationTypes这个全局变量中的元素类型来进行注解的解析，所以上面只说了findAutowiringMetadata()方法会解析出Autowired注解、@Inject和@Value注解这三个注解。
public AutowiredAnnotationBeanPostProcessor() {
	// 添加@Autowired
	this.autowiredAnnotationTypes.add(Autowired.class);
	// 添加@Value
	this.autowiredAnnotationTypes.add(Value.class);
	try {
		// 若是项目中引入了JSR-330相关的jar包，那么就会添加@Inject
		this.autowiredAnnotationTypes.add((Class<? extends Annotation>)
				ClassUtils.forName("javax.inject.Inject", AutowiredAnnotationBeanPostProcessor.class.getClassLoader()));
	}
	catch (ClassNotFoundException ex) {
		
	}
}
复制代码

3.2.2 metadata.inject()

  • 对于属性上加了Autowired注解的，通过上一步解析后，会将字段解析为AutowiredFieldElement类型；若是是方法上加了Autowired注解，则会解析为AutowiredMethodElement类型。它们均是InjectedElement类的子类，里面封装了属性名，属性类型等信息。对于@Resource,@LookUp等注解被解析后，也会解析成对应的InjectedElement的子类：ResourceElement、LookUpElement，可是这两个注解是在其余后置处理器中被解析出来的，并非在AutowiredAnnotationBeanPostProcessor中解析的。
  • metadata.inject()方法最终会调用InjectedElement类的inject()方法。对于本文中的demo，此时userService属性被解析后对应的InjectedElement是AutowiredFieldElement类，因此在此时会调用AutowiredFieldElement.inject()方法。
  • 下面是AutowiredFieldElement.inject()方法的源码。在源码中加了部分注释，从源码中能够发现，核心代码是beanFactory.resolveDependency()。
protected void inject(Object bean, @Nullable String beanName, @Nullable PropertyValues pvs) throws Throwable {
		Field field = (Field) this.member;
		Object value;
		// 判断缓存（第一次注入userService的时候，确定没有缓存，因此会进入到else里面）
		// 当第一次注入完成后，会将userService缓存到cachedFieldValue这个属性中，
		// 这样当其余的类一样须要注入userService时，就会从这儿的缓存当中读取了。
		if (this.cached) {
			value = resolvedCachedArgument(beanName, this.cachedFieldValue);
		}
		else {
			DependencyDescriptor desc = new DependencyDescriptor(field, this.required);
			desc.setContainingClass(bean.getClass());
			Set<String> autowiredBeanNames = new LinkedHashSet<>(1);
			TypeConverter typeConverter = beanFactory.getTypeConverter();
			try {
				// 经过beanFactory.resolveDependency()方法，来从容器中找到userService属性对应的值。
				value = beanFactory.resolveDependency(desc, beanName, autowiredBeanNames, typeConverter);
			}
			catch (BeansException ex) {
				throw new UnsatisfiedDependencyException(null, beanName, new InjectionPoint(field), ex);
			}
			// 省略部分代码...
			// 省略的这部分代码就是将value进行缓存，缓存到cachedFieldValue属性中
		}
		if (value != null) {
			// 经过Java的反射，为属性进行复制
			ReflectionUtils.makeAccessible(field);
			field.set(bean, value);
		}
	}
}
复制代码
  • 在beanFactory.resolveDependency()方法中主要调用了doResolveDependency()方法，下面咱们重点分析一下doResolveDependency()这个方法，这个方法的代码很长。源码以下：
public Object doResolveDependency(DependencyDescriptor descriptor, @Nullable String beanName, @Nullable Set<String> autowiredBeanNames, @Nullable TypeConverter typeConverter) throws BeansException {

	InjectionPoint previousInjectionPoint = ConstructorResolver.setCurrentInjectionPoint(descriptor);
	try {
		Object shortcut = descriptor.resolveShortcut(this);
		if (shortcut != null) {
			return shortcut;
		}
		// 省略部分不重要的代码...
		
		// 属性的类型多是数组、集合、Map类型，因此这一步是处理数组类型、Collection、Map类型的属性
		Object multipleBeans = resolveMultipleBeans(descriptor, beanName, autowiredBeanNames, typeConverter);
		if (multipleBeans != null) {
			return multipleBeans;
		}
		// 根据须要注入的类型type，从容器中找到有哪些匹配的Bean。
		Map<String, Object> matchingBeans = findAutowireCandidates(beanName, type, descriptor);
		// 若是从容器中没有找到，且@Autowired的required属性为true，那么则会抛出异常
		if (matchingBeans.isEmpty()) {
			if (isRequired(descriptor)) {
				raiseNoMatchingBeanFound(type, descriptor.getResolvableType(), descriptor);
			}
			return null;
		}

		String autowiredBeanName;
		Object instanceCandidate;

		// 先根据类型匹配出能够依赖注入的bean的Class，若是匹配出多个，则再根据属性名匹配
		if (matchingBeans.size() > 1) {
			autowiredBeanName = determineAutowireCandidate(matchingBeans, descriptor);
			if (autowiredBeanName == null) {
				if (isRequired(descriptor) || !indicatesMultipleBeans(type)) {
					// 当匹配到多个bean的Class，可是殊不知道要选择哪个注入时，就会抛出异常
					return descriptor.resolveNotUnique(type, matchingBeans);
				}
				else {
					// In case of an optional Collection/Map, silently ignore a non-unique case:
					// possibly it was meant to be an empty collection of multiple regular beans
					// (before 4.3 in particular when we didn't even look for collection beans).
					return null;
				}
			}
			instanceCandidate = matchingBeans.get(autowiredBeanName);
		}
		else {
			// We have exactly one match.
			// 只匹配到一个，则就使用匹配到这个类型
			Map.Entry<String, Object> entry = matchingBeans.entrySet().iterator().next();
			autowiredBeanName = entry.getKey();
			instanceCandidate = entry.getValue();
		}

		if (autowiredBeanNames != null) {
			autowiredBeanNames.add(autowiredBeanName);
		}
		// 此处instanceCandidate = UserServiceImpl.class
		if (instanceCandidate instanceof Class) {
			// instanceCandidate是注入属性的类型，这个须要根据Class，经过FactoryBean的getBean()方法，建立该类型的单例bean
			instanceCandidate = descriptor.resolveCandidate(autowiredBeanName, type, this);
		}
		Object result = instanceCandidate;
		if (result instanceof NullBean) {
			// 若是没从容器中找到对应的bean，则须要判断属性值是不是必须注入的，
			// 即@Autowired(required=false/true),若是为true,则抛异常，这就是常常项目启动时，咱们看到的异常
			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);
	}
}
复制代码
  • 在上面的源码中，咱们看到调用了resolveMultipleBeans()，这个方法是为了处理属性时数组、集合、Map的状况的，例如咱们在OrderServiceImpl中进行以下注入：
@Autowired
private UserService[] userServiceArray;

@Autowired
private List<UserService> userServiceList;

@Autowired
private Map<String,UserService> userServiceMap;
复制代码
  • 这个时候，resolveMultipleBeans()方法就会从容器中找到全部的UserService类型的Bean。resolveMultipleBeans()方法中会调用findAutowireCandidate()方法，从容器中找到对应类型的bean，实际上最终会调用getBean()方法，这样当UserService类型的对象还没被建立时，就会去建立。（Spring中不管是建立Bean仍是获取Bean，入口都是getBean()方法，若是须要详细了解该方法，能够阅读比这的另外一篇文章：经过源码看Bean的建立过程）。
  • resolveMultipleBeans()方法的部分源码
private Object resolveMultipleBeans(DependencyDescriptor descriptor, @Nullable String beanName, @Nullable Set<String> autowiredBeanNames, @Nullable TypeConverter typeConverter) {
	Class<?> type = descriptor.getDependencyType();
    // 处理数组类型
	if (type.isArray()) {
        // findAutowireCandidates最终会调用getBean()方法
		Map<String, Object> matchingBeans = findAutowireCandidates(beanName, componentType,
				new MultiElementDescriptor(descriptor));
		return result;
	}
    // 处理集合类型
	else if (Collection.class.isAssignableFrom(type) && type.isInterface()) {
        // findAutowireCandidates最终会调用getBean()方法
		Map<String, Object> matchingBeans = findAutowireCandidates(beanName, elementType,
				new MultiElementDescriptor(descriptor));
		return result;
	}
    // 处理Map类型
	else if (Map.class == type) {
        // findAutowireCandidates最终会调用getBean()方法
		Map<String, Object> matchingBeans = findAutowireCandidates(beanName, valueType,
				new MultiElementDescriptor(descriptor));
		return matchingBeans;
	}
	else {
		return null;
	}
}
复制代码
  • 若是须要注入的属性是普通类型(非数组、集合、Map)，那么方法会继续向下执行，会调用下面一行代码，根据属性的类型来查找bean。
Map<String, Object> matchingBeans = findAutowireCandidates(beanName, type, descriptor);
复制代码
  • 能够看到又是调用findAutowireCandidates()方法，该方法最终会调用getBean()方法，因此它会从容器中找到对应类型的bean，即UserService类型的Bean。若是容器没有找到对应类型的Bean，且属性是必须注入的，即Autowired注解的required属性为true，那么就会抛出异常，这个异常就是咱们常常看见的：NoSuchBeanDefinitionException。
// 若是容器汇总没有找到指定类型的bean，那么matchingBeans属性就是空的
if (matchingBeans.isEmpty()) {
	if (isRequired(descriptor)) {
        // 抛出异常
		raiseNoMatchingBeanFound(type, descriptor.getResolvableType(), descriptor);
	}
	return null;
}
复制代码
  • matchingBeans这个map的大小可能大于1，由于从容器中找到了多个知足类型的Bean，便可能找到多个UserService类型的bean，那么这个时候就须要判断这多个bean中，究竟应该注入哪个。
if (matchingBeans.size() > 1) {
    // 判断应该使用哪个bean
	autowiredBeanName = determineAutowireCandidate(matchingBeans, descriptor);
	if (autowiredBeanName == null) {
		if (isRequired(descriptor) || !indicatesMultipleBeans(type)) {
			// 当匹配到多个bean的Class，可是殊不知道要选择哪个注入时，就会抛出异常
			return descriptor.resolveNotUnique(type, matchingBeans);
		}
		else {
			return null;
		}
	}
	instanceCandidate = matchingBeans.get(autowiredBeanName);
}
复制代码
  • 在上面的代码中，会调用determineAutowireCandidate()方法，判断应该使用哪个bean。若是determineAutowireCandidate()方法也没法决定使用哪个，determineAutowireCandidate()就会返回null。这个时候若是属性又是必须注入的，即@Autowired的required=true，那么就会抛出异常（由于required=true表示这个属性是必须注入的，可是程序又不知道须要注入哪个，因此就会出错），这个异常也是咱们常常见到的：NoUniqueBeanDefinitionException。
"expected single matching bean but found " + beanNamesFound.size() + ": " + StringUtils.collectionToCommaDelimitedString(beanNamesFound)
复制代码
  • 那么determineAutowireCandidate()又是如何判断应该决定使用哪个bean的呢？Spring会先找到加了@Primary注解的bean，好比Spring找到了两个UserService类型的Bean，分别为UserServiceImpl1和UserServiceImpl2，若是UserServiceImpl1的类上加了@Primary注解，那么就会优先使用userServiceImpl1类型的Bean进行注入。若是都没有加@Primary注解，那么就会找加了@Priority注解的bean，优先级最高的会被优先选中。若是都没有加@Priority，那么就会根据属性的名称和Spring中beanName来判断，例如：UserServiceImpl1和UserServiceImpl2在Spring容器中beanName分别是userServiceImpl1和userServiceImpl2。若是此时OrderServiceImpl中须要注入的UserService类型的属性名是userServiceImpl1，那么Spring就会为其注入UserServiceImpl1类型的单例对象；若是属性名是userServiceImpl2，那么Spring就会为其注入UserServiceImpl2。若是属性名与userServiceImpl1不相等，也与userServiceImpl2不相等，那么就会返回null，那么在方法的调用处，就会抛出NoUniqueBeanDefinitionException异常。
  • 这就是咱们日常所说的@Autowired注解是先根据类型注入，当碰到多个相同类型时，就会根据属性名注入。它的实现原理就是在以下代码中实现的。
protected String determineAutowireCandidate(Map<String, Object> candidates, DependencyDescriptor descriptor) {
	Class<?> requiredType = descriptor.getDependencyType();
	// 根据Primary注解来决定优先注入哪一个bean
	String primaryCandidate = determinePrimaryCandidate(candidates, requiredType);
	if (primaryCandidate != null) {
		return primaryCandidate;
	}
	// 根据@Priority注解的优先级来决定注入哪一个bean
	String priorityCandidate = determineHighestPriorityCandidate(candidates, requiredType);
	if (priorityCandidate != null) {
		return priorityCandidate;
	}
	// 若是既没有指定@Primary，也没有指定@Priority，那么就会根据属性的名称来决定注入哪一个bean
	// 若是要注入的属性的名称与Bean的beanName相同或者别名相同，那么会就会优先注入这个Bean
	for (Map.Entry<String, Object> entry : candidates.entrySet()) {
		String candidateName = entry.getKey();
		Object beanInstance = entry.getValue();
		if ((beanInstance != null && this.resolvableDependencies.containsValue(beanInstance)) ||
				matchesBeanName(candidateName, descriptor.getDependencyName())) {
			return candidateName;
		}
	}
	// 前面三种状况都没有肯定要注入哪一个bean，那么就返回null。当返回null时，那么就会再调用该方法出抛出异常。
	return null;
}
复制代码
  • 当matchingBeans大于1，且经过determineAutowireCandidate()方法确认了使用哪一个bean注入时，或者当matchingBeans=1时，后面就会根据肯定的beanName，来从容器中找到对应的Bean，而后将Bean返回，最后在AutowiredFeildElement.inject()方法中，经过反射进行注入，完成自动装配。
  • 至此，AutowiredAnnotationBeanPostProcessor就经过postProcessPropertyValues()方法完成了自动装配。以上就是@Autowired注解的实现原理。

4. 自动装配的模型

在文章的开头，我问了一个问题：自动装配的模型是什么？有哪几种？和Autowired注解有什么关联？实际上这个问题，和今天的主角AutowiredAnnotationBeanPostProcessor没有任何关系。可是为何又把它放在这篇文章中提出来呢？这是由于@Autowired注解的实现原理和自动装配模型极为容易混淆。缓存

  • 在@Autowired的实现原理中，咱们提到了它会现根据类型来匹配，即byType，当类型匹配到多个时，会根据属性名匹配，即byName。而自动装配的模型有3种，即对应Autowire枚举类中的枚举类型值，枚举类中的名字也是ByName，ByType，那么这两个地方的byName和byType的含义是同样的吗。(这里说3种，实际上不是特别准确，由于从下面源码中能够看到，Autowire枚举的值实际上对应AutowireCapableBeanFactory类中的常量值，而在AutowireCapableBeanFactory中常量值有5个：AUTOWIRE_NO、AUTOWIRE_BY_NAME、AUTOWIRE_BY_TYPE、AUTOWIRE_CONSTRUCTOR、AUTOWIRE_AUTODETECT，其中AUTOWIRE_AUTODETECT目前已经被舍弃了)。
public enum Autowire {

	NO(AutowireCapableBeanFactory.AUTOWIRE_NO),

	BY_NAME(AutowireCapableBeanFactory.AUTOWIRE_BY_NAME),

	BY_TYPE(AutowireCapableBeanFactory.AUTOWIRE_BY_TYPE);
}
复制代码
  • 首先能够很明确的说，这二者的含义是彻底不同的。@Autowired注解中byName和byType能够理解为实现自动装配的技术，是一种实现手段，是咱们开发本身理解定义的，在Spring中，Spring并无为这种实现手段来命名。而Autowire枚举中的值，则是Spring定义的，它是用来描述Bean的装配模型的，是用来给BeanDefinition的autowireMode属性来赋值的。Spring中默认BeanDefinition的autowireMode的值为Autowire.NO。
  • 第二，Bean的注入模型能够手动指定，而@Autowired的实现原理我的是无法作出修改的。例如经过XML配置bean时进行指定，以下示例：
<bean id="orderService" class="com.tiantang.study.service.impl.OrderServiceImpl" autowire="byName">
</bean>
复制代码
  • 或者经过@Bean注解的属性值指定
@Bean(autowire = Autowire.BY_NAME)
public OrderService orderService(){
	return new OrderServiceImpl();
}
复制代码
  • 当咱们为Bean指定了具体的装配模型时，那么这个Bean对应的BeanDefinition的autowiredMode属性值将会是咱们指定的值，而再也不是Spring默认的Autowire.NO。
  • 那么指定装配模型有什么用处呢？它会在populateBean()方法中发挥用处。前面咱们贴出的populateBean()方法的代码中，省略了一部分很重要的代码，如今咱们再贴出populateBean()相对完整的代码：
protected void populateBean(String beanName, RootBeanDefinition mbd, @Nullable BeanWrapper bw) {
	
	PropertyValues pvs = (mbd.hasPropertyValues() ? mbd.getPropertyValues() : null);

	// 判断bean的注入模型是byName，仍是byType。
	if (mbd.getResolvedAutowireMode() == AUTOWIRE_BY_NAME || mbd.getResolvedAutowireMode() == AUTOWIRE_BY_TYPE) {
		MutablePropertyValues newPvs = new MutablePropertyValues(pvs);
		if (mbd.getResolvedAutowireMode() == AUTOWIRE_BY_NAME) {
			autowireByName(beanName, mbd, bw, newPvs);
		}
		// 对于MyBatis而言，Mapper在实例化以后，会填充属性，这个时候，须要找到MapperFactoryBean有哪些属性须要填充
		// 在Mapper的BeanDefinition初始化时，默认添加了一个属性，addToConfig
		// 在下面的if逻辑中，执行完autowireByType()方法后，会找出另外另个须要填充的属性，分别是sqlSessionFactory和sqlSessionTemplate
		if (mbd.getResolvedAutowireMode() == AUTOWIRE_BY_TYPE) {
			autowireByType(beanName, mbd, bw, newPvs);
		}
		pvs = newPvs;
	}

	boolean hasInstAwareBpps = hasInstantiationAwareBeanPostProcessors();
	boolean needsDepCheck = (mbd.getDependencyCheck() != AbstractBeanDefinition.DEPENDENCY_CHECK_NONE);

	if (hasInstAwareBpps || needsDepCheck) {
		if (pvs == null) {
			pvs = mbd.getPropertyValues();
		}
		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);
		}
	}

	if (pvs != null) {
		// 实现经过byName或者byType类型的属性注入
		applyPropertyValues(beanName, mbd, bw, pvs);
	}
}
复制代码
  • 在上面的源码中，咱们发现，在调用后置处理器自动装配属性以前，会先进行判断bean的装配模型是哪种，若是是AUTOWIRE_BY_NAME，那么就会调用autowireByName()方法，在autowireByName()方法中，会先经过setter方法找到属性，而后根据属性名从容器中查找Bean，为其属性赋值；若是是AUTOWIRE_BY_TYPE，那么就会调用autowireByType()方法，autowireByType()这个方法也是先根据setter方法查找属性，而后再根据属性的类型从容器中查找bean，为其属性赋值。
  • 注意上面提到了经过setter方法查找属性，在查找时Spring会忽略调不少setter方法，例如属性的类型是基本数据类型，包装类型，Date，String,Class，Local等等，这些都会被Spring忽略。
// 判断bean的注入模型是byName，仍是byType。
if (mbd.getResolvedAutowireMode() == AUTOWIRE_BY_NAME || mbd.getResolvedAutowireMode() == AUTOWIRE_BY_TYPE) {
	MutablePropertyValues newPvs = new MutablePropertyValues(pvs);
	if (mbd.getResolvedAutowireMode() == AUTOWIRE_BY_NAME) {
		autowireByName(beanName, mbd, bw, newPvs);
	}
	// 对于MyBatis而言，Mapper在实例化以后，会填充属性，这个时候，须要找到MapperFactoryBean有哪些属性须要填充
	// 在Mapper的BeanDefinition初始化时，默认添加了一个属性，addToConfig
	// 在下面的if逻辑中，执行完autowireByType()方法后，会找出另外另个须要填充的属性，分别是sqlSessionFactory和sqlSessionTemplate
	if (mbd.getResolvedAutowireMode() == AUTOWIRE_BY_TYPE) {
		autowireByType(beanName, mbd, bw, newPvs);
	}
	pvs = newPvs;
}
复制代码
  • Spring经过autowireByName()或者autowireByType()查到属性和属性对应的Bean值之后，会将属性和属性值放到pvs这个局部变量中，而后在populateBean()方法的最后一行，调用了applyPropertyValues()方法，而后将其填充到Bean当中。
  • 从这儿也能够发现，注入模型和Autowired注解的自动装配技术没有任何关联关系。@Autowired须要借助AutowiredAnnotationBeanPostProcessor类来实现装配，而自动装配模型则是定义bean的装配类型是什么，而后根据装配类型来执行不一样的方法，并不依赖于AutowiredAnnotationBeanPostProcessor类。
  • 对于自动装配模型Autowire.BY_TYPE有一个经典的应用场景，那就是Spring和MyBatis的整合。在Spring和MyBatis整合时，每个Mapper最后对应一个MapperFactroyBean，而MapperFactroyBean的自动装配模型就是AUTOWIRE_BY_TYPE。MapperFactroyBean在装配时，会执行到autowireByType()方法，会根据setter方法找到符合条件的两个属性sqlSessionFactory、sqlSessionTemplate，而后为这两个属性赋值。
  • Spring整合MyBatis时，建立MapperFactoryBean的BeanDefinition的部分源代码以下：
private void processBeanDefinitions(Set<BeanDefinitionHolder> beanDefinitions) {
	GenericBeanDefinition definition;
	for (BeanDefinitionHolder holder : beanDefinitions) {
		definition = (GenericBeanDefinition) holder.getBeanDefinition();
        // 指定MapperFactoryBean的自动装配模型为AUTOWIRE_BY_TYPE 
        definition.setAutowireMode(AbstractBeanDefinition.AUTOWIRE_BY_TYPE);
	}
}
复制代码
  • 综上，自动装配的模型中的ByName、ByType与@Autowired装配的ByName、ByType不是同一个含义，二者彻底没有关系。

5. 总结

总结以前，先回答一下文章开头的三个问题。1）@Autowired注解的实现是经过后置处理器AutowiredAnnotationBeanPostProcessor类的postProcessPropertyValues()方法实现的。2）当自动装配时，从容器中若是发现有多个同类型的属性时，@Autowired注解会先根据类型判断，而后根据@Primary、@Priority注解判断，最后根据属性名与beanName是否相等来判断，若是仍是不能决定注入哪个bean时，就会抛出NoUniqueBeanDefinitionException异常。3）@Autowired自动装配中byName、byType与自动装配的模型中的byName、byTYpe没有任何关系，二者含义彻底不同，前者是实现技术的手段，后者是用来定义BeanDefiniton中autowireMode属性的值的类型。微信

  • 本文经过源码主要分析了@Autowired注解的实现原理是经过AutowiredAnnotationBeanPostProcessor这个后置处理器来实现的，而后针对@Autowired注入过程当中若是碰到多个同类型的bean时该如何处理的实现细节作了具体的分析。
  • 经过本文咱们不只知道了@Autowired注解的实现原理，还知道了@Autowired注解还能为咱们注入Map、数组、Collection类型的属性。
  • 接着本文经过Spring中自动装配的模型，比较了自动装配模型与@Autowired的关联关系，并经过举例Spring与MyBatis整合的例子，介绍了自动装配模型BY_TYPE的使用场景，并作了简单分析。
  • 最后，看完本文，你能猜到@Resource注解的实现原理吗？若是还不清楚的话，能够看下CommonAnnotationBeanPostProcessor类的源码。

相关推荐数据结构

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程