转自:http://my.oschina.net/HeliosFly/blog/203902
Spring MVC 解读——@Autowired
一、@Autowired
作为一个Spring开发者对@Autowired注解必定是非常了解了, 顾名思义自动装配,应该是Spring会自动将我们标记为@Autowired的元素装配好,与其猜测不如看看它的定义:
1
2
3
4
5
6
7
|
@Target ({ElementType.CONSTRUCTOR, ElementType.FIELD, ElementType.METHOD,
ElementType.ANNOTATION_TYPE})
@Retention (RetentionPolicy.RUNTIME)
@Documented public @interface Autowired {
boolean required() default true ;
} |
很明显这个注解可以用到构造器,变量域,方法,注解类型上。文档上这样描述:将一个构造器,变量域,setter方法,config方法标记为被Spring DI 工具自动装配。换句话说,我们视图从bean 工厂中获取一个bean时,Spring会自动为我们装配该bean中标记为@Autowired的元素,而无需我们手动完成。这些相信大家都明白,但问题是,Spring是怎样做到的?在Spring MVC中怎样做到的?什么时候进行的自动装配?下面我们就来探究下这些问题。
二、BeanPostProcessor
在@Autowired的定义中有下面一段话:
1
2
3
4
5
|
Note that actual injection is performed through a BeanPostProcessor which in turn means that you cannot use @Autowired to inject references into BeanPostProcessor
or BeanFactoryPostProcessor types. Please consult the javadoc for the AutowiredAnnotationBeanPostProcessor class (which, by default , checks for the presence of this annotation).
|
意思是:实际的注入装配动作是由BeanPostProcessor执行的,翻过来说你不能将@Autowired注解用于BeanPostProcessor或BeanFactoryPostProcessor类型上。请查看AutowiredAnnotationBeanPostProcessor文档(默认情况下,被用来检查@Autowired注解)。
文档说的很清楚了,BeanPostProcessor来执行自动装配,并且默认情况下使用AutowiredAnnotationBeanPostProcessor实现类完成。那我们不妨看一下他们的定义:
1
2
3
4
|
public interface BeanPostProcessor {
Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException;
Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException;
} |
BeanPostProcessor就一个回调接口,定义了两个方法声明,一个是实例化前被调用,一个是实例化后被调用,没啥好看的,我们直接看看它的实现类AutowiredAnnotationBeanPostProcessor:
1
2
3
4
5
6
7
8
9
10
11
|
BeanPostProcessor implementation that autowires annotated fields, setter methods and arbitrary config methods. Such members to be injected are detected through a Java 5 annotation:
by default , Spring 's @Autowired and @Value annotations.Also supports JSR-330' s @Inject annotation, if available, as a direct alternative to Spring's own @Autowired .
Note: A default AutowiredAnnotationBeanPostProcessor will be registered by
the "context:annotation-config" and "context:component-scan" XML tags.
NOTE: Annotation injection will be performed before XML injection; thus the latter configuration will override the former for properties
wired through both approaches. |
上面是AutowiredAnnotationBeanPostProcessor类的描述文档摘要,大致意思是:这是BeanPostProcessor接口的一个实现,用来自动装配注解的变量域,setter方法和任意的config方法。这些被注入的元素是通过检测Java 5的注解完成的:默认情况下是@Autowired和@Value注解。同样也支持JSR-330的@Inject注解。并且,<context:annotation-config/>和<context:component-scan/>XML标签可以默认注册AutowiredAnnotationBeanPostProcessor到bean工厂中。最后,注解注入会在XML注入之前执行;因此后面的配置会覆盖前面已经装配好的元素。
是不是很清楚了?Spring的文档总是这么详细,要么说是教科书呢,废话不多说,我们才刚进正题呢,既然我们清楚了是AutowiredAnnotationBeanPostProcessor实例执行了自动装配,那么它做了什么呢?
三、磨刀砍柴
在正式查看源码前,我先大致的讲一下整个装配的过程,以便后面理解起来轻松些。其实整体思路还是很简单的,我们举个简单的例子:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
//==================================Controller @Controller public class SimpleController {
@Autowired
private SimpleService simpleService;
} //==================================Service @Service ( "simpleService" )
public class SimpleServiceImpl implements SimpleService {
@Autowired
private SimpleDao simpleDao;
} //===================================Repository @Repository ( "simpleDao" )
public class SimpleDaoImpl implements SimpleDao {
} |
1)在某一时刻Spring调用了 Bean工厂 的 getBean(beanName) 方法。beanName可能是simpleController,或者simpleService,simpleDao,顺序没关系(因为后面会有依赖关系的处理)。我们假设simpleController吧。
2)getBean方法首先会调用Bean工厂中定义的getSingleton(beanName)方法,来判断是否存在该名字的bean单例,若果存在则返回,方法调用结束。
3)否则,Spring会检查是否存在父工厂,如果有则返回,方法调用结束。
4)否则,Spring 会检查该bean 定义(BeanDefinition实例,用来描述Bean结构,上篇文章讲到过,component-scan 扫描后,就是将beanDefinition实例放入Bean工厂,此时Bean还没有被实例化。)是否有依赖关系,如果有,执行1)步,获取依赖的bean实例。
5)否则,Spring会尝试创建这个bean实例,创建实例前,Spring会检查确定调用的构造器,并实例化该Bean。
6)实例化完成后,Spring会调用Bean工厂的populateBean方法来填充bean实例的属性,也就是我们前面提到的自动转配了。populateBean方法便是调用了BeanPostProcessor实例来完成属性元素的自动装配工作。
7)在元素装配过程中,Spring会检查被装配的属性是否存在自动装配的其他属性,然后递归调用getBean方法,直到所有@Autowired的元素都被装配完成。如在装配simpleController中的simpleService属性时,发现SimpleServiceImpl实例中存在@Autowired属性simpleDao,然后调用getBean(simpleDao)方法,同样会执行1)-7)整个过程。所以可以看成一个递归过程。
8)装配完成后,Bean工厂会将所有的bean实例都添加到工厂中来。
注:我们知道Spring MVC是多线程单实例的MVC框架,就是说,对于同一个Controller,只会生成一个实例来处理所有的请求,因此bean实例只会实例化一次,并被存放在工厂中,以供其他请求使用。
好了,大致了解整个流程后我们看一下Spring的具体行为吧。
四、Bean 工厂
前面多次提到了Bean工厂,但一直没有说它到底是个什么,这里我们就彻底弄清楚吧,省的云里雾里,这样我们后面讲到Bean工厂就不会晕了。看过上一篇博客(<context:component-scan/>)的朋友可能记得DefaultListableBeanFactory这个类,当时是它保存了扫描到的组件--Bean Definition实例。那他是否是我们所说的Bean工厂呢?是否保存了Bean实例呢?答案是:对。
我们可以看到DefaultLiableBeanFactory继承自DefaultSingletonBeanRegistry,AbstractBeanFactory,AbstractAutowireCapableBeanFactory。下面就列出了一下相关的Bean工厂中的属性和方法:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
|
//========================================================================================== //==============================DefaultListableBeanFactory================================ //========================================================================================== //beanName-beanDefinition 的映射表 private final Map<String, BeanDefinition> beanDefinitionMap =
new ConcurrentHashMap<String, BeanDefinition>( 64 );
//beanName 列表 private final List<String> beanDefinitionNames = new ArrayList<String>();
//========================================================================================== //=============================AbstractBeanFactory================================= //========================================================================================== //注册了所有的BeanPostProcessor实例,包括前面提到的用来处理@Autowired注解的 //AutowiredAnnotationBeanPostProcessor private final List<BeanPostProcessor> beanPostProcessors = new ArrayList<BeanPostProcessor>();
//可能存在的父亲Bean工厂 private BeanFactory parentBeanFactory;
//========================================================================================== //==============================DefaultSingletonBeanRegistry================================ //========================================================================================== //beanName--bean单例的映射表 private final Map<String, Object> singletonObjects = new ConcurrentHashMap<String, Object>( 64 );
//注册过的beanName集合 private final Set<String> registeredSingletons = new LinkedHashSet<String>( 64 );
//beanName与该bean所依赖的Beans集合的映射表,如simpleDao依赖与simpleService,如果还有其他 service使用该Dao,如simpleService2那么是simpleDao->[simpleService,simpleService2] private final Map<String, Set<String>> dependentBeanMap
= new ConcurrentHashMap<String, Set<String>>( 64 );
//恰好与上面相反,beanName与该bean所包含的beans的集合映射表,如simpleController->[simpleService] private final Map<String, Set<String>> dependenciesForBeanMap
= new ConcurrentHashMap<String, Set<String>>( 64 );
|
可以看到Bean工厂中即存有bean definition的映射表,也存有bean name的别表,以及bean实例的映射表,还有依赖关系图。理解了这个对下面的实例化以及装配过程会有很大帮助。
五,实例化与装配
下面我们就从头到尾看一下整个的实例化和装配过程:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
|
public Object getBean(String name) throws BeansException {
return doGetBean(name, null , null , false );
} @SuppressWarnings ( "unchecked" )
protected <T> T doGetBean( final String name, final Class<T> requiredType,
final Object[] args, boolean typeCheckOnly) throws BeansException {
//去掉工厂bean的前缀或者将别名转化为规范名
final String beanName = transformedBeanName(name);
Object bean;
// 检查是否有已经注册的bean实例
Object sharedInstance = getSingleton(beanName);
if (sharedInstance != null && args == null ) {
//如果是工厂bean,获取工厂bean创建的bean
bean = getObjectForBeanInstance(sharedInstance, name, beanName, null );
}
else {
//判断是否有父工厂,并且其中是否存在该bean实例?
BeanFactory parentBeanFactory = getParentBeanFactory();
if (parentBeanFactory != null && !containsBeanDefinition(beanName)) {
String nameToLookup = originalBeanName(name);
if (args != null ) {
return (T) parentBeanFactory.getBean(nameToLookup, args);
}
else {
return parentBeanFactory.getBean(nameToLookup, requiredType);
}
}
if (!typeCheckOnly) {
markBeanAsCreated(beanName); //将该beanName标记为已经实例化
}
//获取该beanName对应的BeanDefinition实例,从上面说到的beanDefinitionMap表中查找
final RootBeanDefinition mbd = getMergedLocalBeanDefinition(beanName);
checkMergedBeanDefinition(mbd, beanName, args);
//判断是否有依赖bean
String[] dependsOn = mbd.getDependsOn();
if (dependsOn != null ) {
for (String dependsOnBean : dependsOn) {
getBean(dependsOnBean); //如果有依赖bean,递归调用getBean方法
registerDependentBean(dependsOnBean, beanName); //将依赖关系保存到 上面提到的
//dependBeanMap和dependencyForBeanMap中。
}
}
// 真正的开始床架bean实例了。激动吧
if (mbd.isSingleton()) { //beanDefinition中指定该实例为单例
//去工厂中获取单例,如果没有创建一个,然后添加到工厂中,否则直接返回
sharedInstance = getSingleton(beanName, new ObjectFactory<Object>() {
public Object getObject() throws BeansException {
try {
return createBean(beanName, mbd, args);
}
}
});
bean = getObjectForBeanInstance(sharedInstance, name, beanName, mbd);
}
else if (mbd.isPrototype()) { //原型方式,每次都创建一个新的实例
Object prototypeInstance = null ;
try {
beforePrototypeCreation(beanName);
prototypeInstance = createBean(beanName, mbd, args);
}
finally {
afterPrototypeCreation(beanName);
}
bean = getObjectForBeanInstance(prototypeInstance, name, beanName, mbd);
}
else { //其他方式,如目前主体无关,不赘述
}
}
return (T) bean;
}
|
这个方法好长,真的好长,我还删除了一些与当前主体无关的代码呢,好吧,不要被吓住,如果是自己写的代码,再长都很容易弄懂,类的继承关系再复杂都能轻车熟路,那是因为我们都清楚的知道每一行的用意,看别人的代码一样,多看几遍就明白了,再复杂都一样。
首先Spring会检查beanName,获取规范的beanName,然后它会检查是否存在已经注册的单例(查询上面提到的singletonObjects映射表),如果有的话就直接返回了,一切就结束了,否则的话,会查看是否存在父工厂,如果有调用父工厂的getBean方法,如果没有呢?
好吧那就要着手创建实例了,首先查看beanDefinitionMap查找该beanName对应的beanDefinition实例,然后根据该实例判断是否存在依赖关系,如果存在在递归的调用getBean方法,直到所有的依赖关系都正确的实例化和装配完成,并且将这些依赖关系保存到上面提到的dependencyForBeanMap 和dependentBeanMap中。
接下来,Spring查看BeanDefinition来确定该Bean应该是单例方式创建还是原型方式创建?如果是单例的话,Spring会调用getSingleton方法查找或创建一个单例(下面会详聊),如果是原型的话,每次调用getBean方法都会创建一个新的实例,看上面代码便会一清二楚了。
那下面我们就看看这个getSingleton方法做了什么?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
public Object getSingleton(String beanName, ObjectFactory singletonFactory) {
//这不就是上面说的bean实例映射表吗?哈,被同步了,保证线程安全啊
synchronized ( this .singletonObjects) {
Object singletonObject = this .singletonObjects.get(beanName);
if (singletonObject == null ) { //第一次创建当然是空
beforeSingletonCreation(beanName); //这个是看看当前的beanName是否在排除列表中,如果是
//则抛出异常
boolean recordSuppressedExceptions = ( this .suppressedExceptions == null );
try { //这里调用了上面的匿名内部类的getObject方法了,实则调用了createBean方法
singletonObject = singletonFactory.getObject();
} //这不,添加到了singleObjects映射表中了,以备下次使用
addSingleton(beanName, singletonObject);
}
return (singletonObject != NULL_OBJECT ? singletonObject : null );
}
}
|
这里稍微清晰了,查看singletonObjects映射表,看是否存在已经注册的单例,如果没有调用createBean方法创建一个,并且注册到singletonObjects映射表中,否则直接返回就Ok了。
下面就是createBean了, we are close。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
|
protected Object doCreateBean( final String beanName, final RootBeanDefinition mbd,
final Object[] args) {
// Instantiate the bean.
BeanWrapper instanceWrapper = null ;
if (mbd.isSingleton()) {
instanceWrapper = this .factoryBeanInstanceCache.remove(beanName);
}
if (instanceWrapper == null ) { //实例化动作
instanceWrapper = createBeanInstance(beanName, mbd, args);
}
//.....some codes we don't care.
//......
// Initialize the bean instance.
Object exposedObject = bean;
try { /////装配动作
populateBean(beanName, mbd, instanceWrapper);
if (exposedObject != null ) { //后面会讲到,暂时不关心
exposedObject = initializeBean(beanName, exposedObject, mbd);
}
}
//........some codes we don't care.
return exposedObject;
}
|
比较清晰(同样去除了一些我们不关心的代码),上面的方法分了我们期望的两部执行,第一实例化Bean,第二装配Bean。
第一步实例化主要是通过确定调用的构造器来最终调用Class.newInstance(args)方法来实例化Bean。不做细究,有兴趣可以自己看看,比较简单,主要是第二部装配,也就是处理我们的@Autowired注解(终于找到正题了)。
六、执行装配
方法populateBean执行了最终的Autowired动作,我们看一下它做了什么?话说这块有点麻烦了,开始之前想讲几个比较重要的类和接口吧:
A) PropertyValue:这是一个用来表示Bean属性的对象,其中定义了属性的名字和值等信息,如simpleService,和simpleDao属性。
B) PropertyDescriptor:这个事Bean属性的描述符,其中定义了该属性可能存在的setter和getter方法,以及所有Bean的Class对象。
C) InjectionMetadata:这个是注入元数据,包含了目标Bean的Class对象,和注入元素(InjectionElement)集合.
D) InjectionElement:这个是注入元素,包含了注入元素的java.lang.reflect.Member 的对象,以及一个PropertyDescriptor对象。就是对java.lang.reflect.Member的一个封装,用来执行最终的注入动作,它有两个子类,分别是:AutowiredFieldElement表示字段属性,AutowiredMethodElement表示方法。
其实最终的目标就是将PropertyValue中的value值赋给InjectionElement中的Member对象。那它是怎么做的呢?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
|
protected void populateBean(String beanName, RootBeanDefinition mbd, BeanWrapper bw) {
//尝试从BeanDefinition中获取PropertyValue的属性集合,很明显没有值呢还。
PropertyValues pvs = mbd.getPropertyValues();
//.....其中执行了一些BeanPostProcessor的postProcessAfterInstantiation动作,我们不关心。
//.....移除了
//这里比较重要,这里会设置上面的PropertyValues的值,默认情况下是getResolvedAutowiredMode方法返回
//0, 但是我们可以在xml配置文件中设置<beans/>标签的default-autowire属性来改变它。
if (mbd.getResolvedAutowireMode() == RootBeanDefinition.AUTOWIRE_BY_NAME ||
mbd.getResolvedAutowireMode() == RootBeanDefinition.AUTOWIRE_BY_TYPE) {
MutablePropertyValues newPvs = new MutablePropertyValues(pvs);
// Add property values based on autowire by name if applicable.
if (mbd.getResolvedAutowireMode() == RootBeanDefinition.AUTOWIRE_BY_NAME) {
autowireByName(beanName, mbd, bw, newPvs);
}
// Add property values based on autowire by type if applicable.
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);
if (hasInstAwareBpps || needsDepCheck) {
PropertyDescriptor[] filteredPds =
filterPropertyDescriptorsForDependencyCheck(bw, mbd.allowCaching);
if (hasInstAwareBpps) {
//这里便是最最最重要的了,也就是最终的Autowired了。
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);
}
}
applyPropertyValues(beanName, mbd, bw, pvs);
}
|
Spring 尝试获取bean definition的PropertyValue集合,开始当然是空的,然后下面便是进行根据名字或者类型为我们的PropertyValue集合进行赋值了, 在不设置<beans default-autowire="byName/byType"/>的情况下是不会调用这个方法的,如果设置了byName,我们来看看做了什么?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
|
protected void autowireByName(
String beanName, AbstractBeanDefinition mbd,
BeanWrapper bw, MutablePropertyValues pvs) {
//找到还没赋值的属性名称,看下面方法
String[] propertyNames = unsatisfiedNonSimpleProperties(mbd, bw);
for (String propertyName : propertyNames) {
if (containsBean(propertyName)) {
//递归调用getBean,如果没有创建并注册,有了直接返回。
Object bean = getBean(propertyName);
//将刚得到或创建的bean赋值给PropertyValue
pvs.add(propertyName, bean);
//并将该属性名和实例注册到依赖关系映射表dependentBeanMap和dependencyForBeanMap中
registerDependentBean(propertyName, beanName);
}
}
}
protected String[] unsatisfiedNonSimpleProperties(AbstractBeanDefinition mbd, BeanWrapper bw) {
Set<String> result = new TreeSet<String>();
PropertyValues pvs = mbd.getPropertyValues();
PropertyDescriptor[] pds = bw.getPropertyDescriptors();
//遍历bean的所有属性,并将符合条件的属性名添加到结果列表中
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的所有属性(描述符),然后依次判断查找符合条件的属性,并添加到属性名称数组中,然后遍历这个数组,对其中的属性名依次调用getBean(propertyName)方法来获取或创建该名称的bean实例,并将该bean实例设为PropertyValue的value值,最后添加到依赖关系映射表中(dependencyForBeanMap和dependentBeanMap)。好了此时PropertyValues有值了,后面就可以用它来注入到bean的属性中了。我们接着看上面populateBean方法。
PropertyValue值设置后,Spring会调用getBeanPostProcessor方法遍历Bean工厂中注册的所有BeanPostProcessor,其中就包括AutowiredAnnotationBeanPostProcessor(这些BeanPostProcessor都是系统默认硬编码注册到bean工厂中的)。接着就会调用AutowiredAnnotationBeanPostProcessor的postProcessPropertyValues方法,并将之前的PropertyValues和bean实例传递进去。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
|
//虽然PropertyValues属性传递过去了,但是并没有使用它直接赋值给属性变量(还不清楚为什么会传递它,其实没用到) @Override public PropertyValues postProcessPropertyValues(PropertyValues pvs,
PropertyDescriptor[] pds, Object bean, String beanName) throws BeansException {
//调用下面的方法获取InjectionMetadata对象(其实InjectionElement集合)
InjectionMetadata metadata = findAutowiringMetadata(bean.getClass());
try {
metadata.inject(bean, beanName, pvs);
}
return pvs;
}
private InjectionMetadata findAutowiringMetadata(Class<?> clazz) {
// 先找缓存
InjectionMetadata metadata = this .injectionMetadataCache.get(clazz);
if (metadata == null ) {
synchronized ( this .injectionMetadataCache) {
metadata = this .injectionMetadataCache.get(clazz);
if (metadata == null ) {
//缓存没有,调用buildAutowiringMetadata方法构建
metadata = buildAutowiringMetadata(clazz);
this .injectionMetadataCache.put(clazz, metadata);
}
}
}
return metadata;
}
private InjectionMetadata buildAutowiringMetadata(Class<?> clazz) {
LinkedList<InjectionMetadata.InjectedElement> elements =
new LinkedList<InjectionMetadata.InjectedElement>();
Class<?> targetClass = clazz;
do { //这里一个循环,因为要考虑父类的字段和方法
LinkedList<InjectionMetadata.InjectedElement> currElements =
new LinkedList<InjectionMetadata.InjectedElement>();
for (Field field : targetClass.getDeclaredFields()) {
//遍历每一个field,找到被标记为@Autowired的field
Annotation annotation = findAutowiredAnnotation(field);
if (annotation != null ) {
if (Modifier.isStatic(field.getModifiers())) {
continue ; //不可一世static的。
}
boolean required = determineRequiredStatus(annotation);
//创建AutowiredFieldElement。
currElements.add( new AutowiredFieldElement(field, required));
}
}
for (Method method : targetClass.getDeclaredMethods()) {
//遍历所有方法,这里有个桥方法的处理,我们不关心
Method bridgedMethod = BridgeMethodResolver.findBridgedMethod(method);
Annotation annotation = BridgeMethodResolver
.isVisibilityBridgeMethodPair(method, bridgedMethod) ?
findAutowiredAnnotation(bridgedMethod) :
findAutowiredAnnotation(method);
if (annotation != null &&
method.equals(ClassUtils.getMostSpecificMethod(method, clazz))) {
if (Modifier.isStatic(method.getModifiers())) {
continue ;
}
if (method.getParameterTypes().length == 0 ) {
}
boolean required = determineRequiredStatus(annotation);
PropertyDescriptor pd = BeanUtils.findPropertyForMethod(method);
//创建AutowiredMethodElement。
currElements.add( new AutowiredMethodElement(method, required, pd));
}
}
elements.addAll( 0 , currElements);
targetClass = targetClass.getSuperclass();
}
while (targetClass != null && targetClass != Object. class );
//将InjectionElement集合添加到新建的InjectionMetadata中。
return new InjectionMetadata(clazz, elements);
}
|
上面三个方法看似复杂其实很简单,首先Spring尝试调用findAutowiringMetadata方法获取该bean的InjectionMetadata实例(也就是有哪些属性需要被自动装配,也就是查找被@Autowired注解标记的元素)。怎么获取呢?首先去缓存里面找,找不到就遍历bean的和父类的字段域和方法,如果别标记为@Autowired并且不是静态的就添加到InjectionMetadata中,并添加到缓存中(各种缓存啊)。获得InjectionMetadata对象后便遍历其中的所有InjectionElement对象,调用其中的inject方法。前面说了InjectionElement有两个实现类,我们只看一个就可以,因为基本相同:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
|
@Override protected void inject(Object bean, String beanName, PropertyValues pvs)
throws Throwable {
Field field = (Field) this .member;
try {
Object value;
if ( this .cached) {
value = resolvedCachedArgument(beanName, this .cachedFieldValue);
}
else {
DependencyDescriptor descriptor
= new DependencyDescriptor(field, this .required);
Set<String> autowiredBeanNames = new LinkedHashSet<String>( 1 );
TypeConverter typeConverter = beanFactory.getTypeConverter();
//这里是重中之重,获取真正的属性值。
value = beanFactory.resolveDependency(descriptor, beanName,
autowiredBeanNames, typeConverter);
}
if (value != null ) {
ReflectionUtils.makeAccessible(field);
field.set(bean, value); //最终赋值结束。
}
}
}
}
|
可以看到,虽然PropertyValues属性传递过去了,但是并没有使用它直接赋值给属性变量(还不清楚为什么会传递它,其实没用到),而是通过调用bean工厂的resolveDependency方法来获取属性值得。那我们看一下resolveDependency做了什么?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
|
protected Object doResolveDependency(DependencyDescriptor descriptor,
Class<?> type, String beanName,
Set<String> autowiredBeanNames,
TypeConverter typeConverter) throws BeansException {
if (type.isArray()) { //如果属性类型是数组
Class<?> componentType = type.getComponentType();
Map<String, Object> matchingBeans = findAutowireCandidates(beanName, componentType, descriptor);
if (autowiredBeanNames != null ) {
autowiredBeanNames.addAll(matchingBeans.keySet());
}
TypeConverter converter = (typeConverter != null ? typeConverter : getTypeConverter());
return converter.convertIfNecessary(matchingBeans.values(), type);
} //如果属性是集合,并且是接口
else if (Collection. class .isAssignableFrom(type) && type.isInterface()) {
Class<?> elementType = descriptor.getCollectionType();
Map<String, Object> matchingBeans = findAutowireCandidates(beanName, elementType, descriptor);
if (autowiredBeanNames != null ) {
autowiredBeanNames.addAll(matchingBeans.keySet());
}
TypeConverter converter = (typeConverter != null ? typeConverter : getTypeConverter());
return converter.convertIfNecessary(matchingBeans.values(), type);
} //如果属性是Map并且是接口
else if (Map. class .isAssignableFrom(type) && type.isInterface()) {
Class<?> keyType = descriptor.getMapKeyType();
Class<?> valueType = descriptor.getMapValueType();
Map<String, Object> matchingBeans = findAutowireCandidates(beanName, valueType, descriptor);
if (autowiredBeanNames != null ) {
autowiredBeanNames.addAll(matchingBeans.keySet());
}
return matchingBeans;
} //自定义类型了
else { //都调用了这个方法
Map<String, Object> matchingBeans = findAutowireCandidates(beanName, type, descriptor);
if (matchingBeans.size() > 1 ) {
String primaryBeanName = determinePrimaryCandidate(matchingBeans, descriptor);
if (autowiredBeanNames != null ) {
autowiredBeanNames.add(primaryBeanName);
}
return matchingBeans.get(primaryBeanName);
}
// We have exactly one match.
Map.Entry<String, Object> entry = matchingBeans.entrySet().iterator().next();
if (autowiredBeanNames != null ) {
autowiredBeanNames.add(entry.getKey());
}
return entry.getValue();
}
}
|
这个方法其实就是根据类型到bean工厂中查找类型匹配的bean实例,然后就看到了这几个条件分支语句,如果是数组,集合,映射表,自定义类型都执行了差不多的操作,findAutowireCandidate方法。这个方法会去工厂中执行类型匹配的查找,将匹配的结果集返回,不同的是,集合数组类型会通过TypeConverter进行结果的转换。
到此为止,找到了属性的匹配值,然后反射赋值就完成了整个的自动装配过程。可以看出,@Autowired是通过类型来进行自动装配的。
上面是属性的赋值过程也就是InjectionFieldElement的inject方法,InjectionMethodElement的inject方法大致相同只是对每一个方法参数执行一次resolveDependency方法来获取参数值,然后反射执行方法。
到此为止,整个实例化和装配过程也就讲完了,我们总结一下:
1)一切都是从bean工厂的getBean方法开始的,一旦该方法调用总会返回一个bean实例,无论当前是否存在,不存在就实例化一个并装配,否则直接返回。
2)实例化和装配过程中会多次递归调用getBean方法来解决类之间的依赖。
3)Spring几乎考虑了所有可能性,所以方法特别复杂但完整有条理。
4)@Autowired最终是根据类型来查找和装配元素的,但是我们设置了<beans default-autowire="byName"/>后会影响最终的类型匹配查找。因为在前面有根据BeanDefinition的autowire类型设置PropertyValue值得一步,其中会有新实例的创建和注册。就是那个autowireByName方法。
七、一切的开始
我们上面讲完了整个Autowire过程了。那么,还有一个问题,上一篇我们知道了什么时候执行的配置文件读取和组件扫描,但Spring MVC是在什么时候开始执行真个实例化过程的呢?很简单就在组件扫描完成之后,bean工厂的refresh方法中(还记得吗?)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
public void refresh() throws BeansException, IllegalStateException {
synchronized ( this .startupShutdownMonitor) {
prepareRefresh();
//前面说过,这里面执行了,组件扫描和配置文件读取
ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory();
prepareBeanFactory(beanFactory);
try {
postProcessBeanFactory(beanFactory);
invokeBeanFactoryPostProcessors(beanFactory);
//这里注册了BeanPostProcessor,包括AutowiredAnnotationBeanPostProcessor
registerBeanPostProcessors(beanFactory);
initMessageSource();
initApplicationEventMulticaster();
onRefresh();
registerListeners();
//这里就执行了所有非延迟加载的实例化工作。//here
finishBeanFactoryInitialization(beanFactory);
finishRefresh();
}
}
}
|
就是上面的finishBeanFactoryInitialization方法执行了装配工作,该方法会调用bean工厂的preInstantiateSingletons方法,这个方法会遍历所有注册的bean definition实例,如果是单例并且是非延迟加载的就调用getBean方法。
好了,到此为止我们就清晰的了解了,Spring MVC的实例化和自动装配工作了,如有问题欢迎评论中提出,我们一起讨论。
Spring MVC 解读——@Autowired(转)的更多相关文章
-
Spring MVC 解读——@Autowired、@Controller、@Service从原理层面来分析
目录(?)[+] Spring MVC 解读Autowired 一Autowired 二BeanPostProcessor 三磨刀砍柴 四Bean 工厂 五实例化与装配 六执行装配 七一切的开始 ...
-
Spring MVC 解读——@RequestMapping (1)(转)
转自:http://my.oschina.net/HeliosFly/blog/212329 Spring MVC 解读——@RequestMapping 为了降低文章篇幅,使得文章更目标化,简洁化, ...
-
Spring MVC 解读——@RequestMapping (2)(转)
转自:http://my.oschina.net/HeliosFly/blog/214438 Spring MVC 解读——@RequestMapping 上一篇文章中我们了解了Spring如何处理@ ...
-
Spring MVC 解读——<;mvc:annotation-driven/>;(转)
转自:http://my.oschina.net/HeliosFly/blog/205343 Spring MVC 解读——<mvc:annotation-driven/> 一.Annot ...
-
Spring MVC 解读——<;context:component-scan/>;
转自:http://my.oschina.net/HeliosFly/blog/203149 作者:GoodLoser. Spring MVC 解读---<context:component-s ...
-
Spring MVC 解读——<;mvc:annotation-driven/>;
Spring MVC 解读——<mvc:annotation-driven/> 一.AnnotationDrivenBeanDefinitionParser 通常如果我们希望通过注解的方式 ...
-
Spring MVC 解读——View,ViewResolver(转)
上一篇文章(1)(2)分析了Spring是如何调用和执行控制器方法,以及处理返回结果的,现在我们就分析下Spring如何解析返回的结果生成响应的视图. 一.概念理解 View ---View接口表示一 ...
-
【转】Spring MVC 解读——<;mvc:annotation-driven/>;
转载自:http://my.oschina.net/HeliosFly/blog/205343 一.AnnotationDrivenBeanDefinitionParser 通常如果我们希望通过注解的 ...
-
Spring MVC 起步
跟踪Spring MVC的请求 在请求离开浏览器时①,会带有用户所请求内容的信息,至少会包含请求的URL. 请求旅程的第一站是Spring的DispatcherServlet.与大多数基于Java的W ...
随机推荐
-
ASP.NET Core 中文文档 第四章 MVC(3.6.2 )自定义标签辅助类(Tag Helpers)
原文:Authoring Tag Helpers 作者:Rick Anderson 翻译:张海龙(jiechen) 校对:许登洋(Seay) 示例代码查看与下载 从 Tag Helper 讲起 本篇教 ...
-
mysql导入和导出数据
Linux下如何单个库进行导入和备份操作 1.将数据导入数据库mysql -u账号 -p密码 数据库<sql脚本 mysql -uroot -proot test</home/upload ...
-
PCB板简易流程
PCB布线规则设置 在进行布线之前一般要进行布线规则的设置,(因为元器件的封装已经画出了元件实际的轮廓大小,所以放置元件封装时,即使两个元件封装挨着也一般不会影响元件的实际安装,不过一般还是稍留一点距 ...
-
python and or用法
and 和 or 是python的两个逻辑运算符,可以使用and , or来进行多个条件内容的判断.下面通过代码简单说明下and or的用法: 1. or:当有一个条件为真时,该条件即为真.逻辑图如 ...
-
P1433 吃奶酪 回溯法 优化
题目描述 房间里放着n块奶酪.一只小老鼠要把它们都吃掉,问至少要跑多少距离?老鼠一开始在(0,0)点处. 输入输出格式 输入格式: 第一行一个数n (n<=15) 接下来每行2个实数,表示第i块 ...
-
mybatis ---->; 各种方式使用MBG
1.maven方式使用 配置好.pom文件 ①src/main/resources下创建 generatorConfig.xml,并配置好(自动生成的配置文件骨架) ②src/main/java 下创 ...
-
String的equals()方法源码解析
每个String对象在创建的时候都构造了一个char类型的final声明的不可替换数组,数组中的每一个元素即字符串对应的每一个字符如图: String的equals()在比较的时候会进行两步比较: 1 ...
-
20172302『Java程序设计』课程 结对编程练习_四则运算第二周阶段总结
一.结对对象 姓名:周亚杰 学号:20172302 担任角色:驾驶员(周亚杰) 伙伴第二周博客地址 二.本周内容 (一)继续编写上周未完成代码 1.本周继续编写代码,使代码支持分数类计算 2.相关过程 ...
-
如何搜索IP的地理位置
如何搜索IP的地理位置 http://www.ip138.com/ 打开上边这个网页以后,会显示自身的IP及地理位置,,,,也可以搜索别人的IP和地理位置,手机号等:截图如下:
-
Oracle ASM 相关的 视图(V$) 和 数据字典(X$)
本文转自: http://blog.csdn.net/tianlesoftware/article/details/6733039 ASM由于其高度的封装性,使得我们很难知道窥探其内部的原理.可以通过 ...