spring源码分析-spring是如何获取组件的
spring这个框架我已经用很久了，差不多两年吧，也写过一些分析源码的文章，当时主要是在b站看培训班课程时写的笔记。一方面是学习spring的基本用法，另一方面是巩固所学，毕竟手和脑一块动起来学的东西比较牢。而且，写点东西后续回顾起来也快。
但是，spring实在太复杂了，尤其是钻入源码层面非常容易迷失，在n个层次的调用栈跳来跳去，晕头转向。尽管如此，每次看还是有新的体会，有些当初看不懂的地方渐渐明白了。想着趁热打铁，把自己的理解记录下来，因此有了这篇文章。
本文内容是从源码角度对spring如何实例化组件的理解。
ApplicationContext和BeanFactory先搞清楚
ApplicationContext和BeanFactory这两个组件在前期我是混淆不清的，觉得他们都差不多，毕竟他们之间互为继承关系。一般工作中使用的ApplicationContext接口实现类是AnnotationConfigApplicationContext，看看其继承图：
再观察下AnnotationConfigApplicationContext的类结构：
// org.springframework.context.annotation.AnnotationConfigApplicationContext
public class AnnotationConfigApplicationContext extends GenericApplicationContext implements AnnotationConfigRegistry {
private final AnnotatedBeanDefinitionReader reader;
private final ClassPathBeanDefinitionScanner scanner;
//.................省略................
}
再看看其父类GenericApplicationContext的类结构：
// org.springframework.context.support.GenericApplicationContext
public class GenericApplicationContext extends AbstractApplicationContext implements BeanDefinitionRegistry {
// beanFactory的真面目，实现类为DefaultListableBeanFactory
private final DefaultListableBeanFactory beanFactory;
private ResourceLoader resourceLoader;
private boolean customClassLoader = false;
private final AtomicBoolean refreshed = new AtomicBoolean();
//..................省略................
}
所以，我的理解是beanFactory其实是ApplicationContext的一个成员变量（至少在Annotation模式下的spring是如此）。而且，beanFactory是真正的bean工厂，获取bean的真实逻辑来自beanFactory，下面分析其原理。
首先说明下AnnotationConfigApplicationContext的beanFactory是DefaultListableBeanFactory这个是怎么实现的：
// org.springframework.context.support.GenericApplicationContext
// AnnotationConfigApplicationContext的父类是GenericApplicationContext，且一般使用无参构造函数进行实例化，所以不言而喻了吧
public GenericApplicationContext() {
this.beanFactory = new DefaultListableBeanFactory();
}
获取bean的方式最常见的方式一般是applicationContext.getBean(xxxx.class)，那看看其逻辑：
// org.springframework.context.annotation.AnnotationConfigApplicationContext
@Override
public <T> T getBean(Class<T> requiredType) throws BeansException {
assertBeanFactoryActive();
// 最终使用的是成员变量beanFactory获取bean
return getBeanFactory().getBean(requiredType);
}
所以beanFactory才是真正管理bean的地方。
既然是管理bean的地方那必然有个地方存放bean单例，分析下DefaultListableBeanFactory的继承体系
看看其父类DefaultSingletonBeanRegistry类结构
// org.springframework.beans.factory.support.DefaultSingletonBeanRegistry
public class DefaultSingletonBeanRegistry extends SimpleAliasRegistry implements SingletonBeanRegistry {
/**
* Internal marker for a null singleton object:
* used as marker value for concurrent Maps (which don't support null values).
*/
protected static final Object NULL_OBJECT = new Object();
/** Logger available to subclasses */
protected final Log logger = LogFactory.getLog(getClass());
/** Cache of singleton objects: bean name --> bean instance */
// 完全实例化的组件放在这
private final Map<String, Object> singletonObjects = new ConcurrentHashMap<String, Object>(256);
/** Cache of singleton factories: bean name --> ObjectFactory */
// 用于解决循环依赖的问题，组件A依赖组件B，组件B依赖组件A，那么还为完全实例的组件A将被丢入此
private final Map<String, ObjectFactory<?>> singletonFactories = new HashMap<String, ObjectFactory<?>>(16);
/** Cache of early singleton objects: bean name --> bean instance */
// 用于解决循环依赖的问题，配合singletonFactories使用，这里存放的组件是还未注入属性的对象
private final Map<String, Object> earlySingletonObjects = new HashMap<String, Object>(16);
/** Set of registered singletons, containing the bean names in registration order */
private final Set<String> registeredSingletons = new LinkedHashSet<String>(256);
/** Names of beans that are currently in creation */
private final Set<String> singletonsCurrentlyInCreation =
Collections.newSetFromMap(new ConcurrentHashMap<String, Boolean>(16));
/** Names of beans currently excluded from in creation checks */
private final Set<String> inCreationCheckExclusions =
Collections.newSetFromMap(new ConcurrentHashMap<String, Boolean>(16));
/** List of suppressed Exceptions, available for associating related causes */
private Set<Exception> suppressedExceptions;
/** Flag that indicates whether we're currently within destroySingletons */
private boolean singletonsCurrentlyInDestruction = false;
/** Disposable bean instances: bean name --> disposable instance */
private final Map<String, Object> disposableBeans = new LinkedHashMap<String, Object>();
/** Map between containing bean names: bean name --> Set of bean names that the bean contains */
private final Map<String, Set<String>> containedBeanMap = new ConcurrentHashMap<String, Set<String>>(16);
/** Map between dependent bean names: bean name --> Set of dependent bean names */
private final Map<String, Set<String>> dependentBeanMap = new ConcurrentHashMap<String, Set<String>>(64);
/** Map between depending bean names: bean name --> Set of bean names for the bean's dependencies */
private final Map<String, Set<String>> dependenciesForBeanMap = new ConcurrentHashMap<String, Set<String>>(64);
//.............省略.................
}
看了上述类结构大致可以理解为什么beanFactory才是bean工厂了，其有四个很重要的容器对象singletonObjects、singletonFactories、earlySingletonObjects、singletonsCurrentlyInCreation，他们搭配使用可解决循环依赖问题，关于这点后面在介绍实例化的过程中进行穿插分析。
spring是如何获取组件的
spring是个组件容器，获取组件的过程自然可以猜到：如果容器中有组件实例则直接返回，没有则创建，然后放入容器的某个map存着，最后返回该组件。具体的原理值得分析，下面展开：
经过上面的分析已经知道真正的bean工厂是DefaultListableBeanFactory，因此接下来从这个类切入。
DefaultListableBeanFactory重载了很多getBean方法，其实内部互相调来调去，我们直接关注用于实例化bean的方法：
// org.springframework.beans.factory.support.DefaultListableBeanFactory
protected <T> T doGetBean(
final String name, final Class<T> requiredType, final Object[] args, boolean typeCheckOnly)
throws BeansException {
// 处理bean名称，比如beanFacotry带&，比如alias这类的别名，
//逻辑简单也不是很重要，就不展开了
final String beanName = transformedBeanName(name);
Object bean;
// Eagerly check singleton cache for manually registered singletons.
// getSingleton这个方法经常出现，后面会展开分析
Object sharedInstance = getSingleton(beanName);
if (sharedInstance != null && args == null) {
if (logger.isDebugEnabled()) {
// 如果发生循环依赖则进入此逻辑
if (isSingletonCurrentlyInCreation(beanName)) {
logger.debug("Returning eagerly cached instance of singleton bean '" + beanName +
"' that is not fully initialized yet - a consequence of a circular reference");
}
else {
logger.debug("Returning cached instance of singleton bean '" + beanName + "'");
}
}
// 获取bean实例，上述步骤不是获取bean实例了吗？为何还有此步骤？原因其实是考虑bean实例是beanFactory的情况，如果是beanFactory则需调用其getObject方法返回bean单例
bean = getObjectForBeanInstance(sharedInstance, name, beanName, null);
}
else {
// Fail if we're already creating this bean instance:
// We're assumably within a circular reference.
if (isPrototypeCurrentlyInCreation(beanName)) {
throw new BeanCurrentlyInCreationException(beanName);
}
// Check if bean definition exists in this factory.
// 父容器的情况，一般很少用到，springmvc会用到？暂不了解
BeanFactory parentBeanFactory = getParentBeanFactory();
if (parentBeanFactory != null && !containsBeanDefinition(beanName)) {
// Not found -> check parent.
String nameToLookup = originalBeanName(name);
if (args != null) {
// Delegation to parent with explicit args.
return (T) parentBeanFactory.getBean(nameToLookup, args);
}
else {
// No args -> delegate to standard getBean method.
return parentBeanFactory.getBean(nameToLookup, requiredType);
}
}
if (!typeCheckOnly) {
markBeanAsCreated(beanName);
}
try {
// 合并bean定义，从没碰到这种用法
final RootBeanDefinition mbd = getMergedLocalBeanDefinition(beanName);
checkMergedBeanDefinition(mbd, beanName, args);
// Guarantee initialization of beans that the current bean depends on.
// 处理depondsOn的依赖问题，如果是这种方式的循环依赖，spring也无解...
String[] dependsOn = mbd.getDependsOn();
if (dependsOn != null) {
for (String dep : dependsOn) {
if (isDependent(beanName, dep)) {
throw new BeanCreationException(mbd.getResourceDescription(), beanName,
"Circular depends-on relationship between '" + beanName + "' and '" + dep + "'");
}
registerDependentBean(dep, beanName);
getBean(dep);
}
}
// Create bean instance.
if (mbd.isSingleton()) {
// 这里也是个getSingleton，是另一个重载的方法，后续重点分析
sharedInstance = getSingleton(beanName, new ObjectFactory<Object>() {
@Override
public Object getObject() throws BeansException {
try {
// creatBean重点方法，后续重点分析，实例化的逻辑切入点
return createBean(beanName, mbd, args);
}
catch (BeansException ex) {
// Explicitly remove instance from singleton cache: It might have been put there
// eagerly by the creation process, to allow for circular reference resolution.
// Also remove any beans that received a temporary reference to the bean.
destroySingleton(beanName);
throw ex;
}
}
});
bean = getObjectForBeanInstance(sharedInstance, name, beanName, mbd);
}
else if (mbd.isPrototype()) {
// 多例的情况，遇到的较少，暂不分析了
// It's a prototype -> create a new instance.
Object prototypeInstance = null;
try {
beforePrototypeCreation(beanName);
prototypeInstance = createBean(beanName, mbd, args);
}
finally {
afterPrototypeCreation(beanName);
}
// 获取bean实例，上述步骤不是获取bean实例了吗？为何还有此步骤？原因其实是考虑bean实例是beanFactory的情况，如果是beanFactory则需调用其getObject方法返回bean单例
bean = getObjectForBeanInstance(prototypeInstance, name, beanName, mbd);
}
//..................省略..................
}
catch (BeansException ex) {
cleanupAfterBeanCreationFailure(beanName);
throw ex;
}
}
// Check if required type matches the type of the actual bean instance.
// ....................省略...................
return (T) bean;
}
分析下getSingleton的几个重载方法，这个方法出现的很频繁：
第一个重载方法：
// org.springframework.beans.factory.support.DefaultSingletonBeanRegistry
public Object getSingleton(String beanName) {
return getSingleton(beanName, true);
}
protected Object getSingleton(String beanName, boolean allowEarlyReference) {
Object singletonObject = this.singletonObjects.get(beanName);
// singletonObject中没有，但是singletonsCurrentlyInCreation中却有，说明这个bean正在实例化中，但没完全实例化
// 为什么会出现这种情况呢？原因是循环依赖导致的
if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {
synchronized (this.singletonObjects) {
// 先从earlySingletonObjects取，没有则打算从singletonFactory进行实例化
singletonObject = this.earlySingletonObjects.get(beanName);
if (singletonObject == null && allowEarlyReference) {
ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName);
if (singletonFactory != null) {
// 关于这点后续会分析到切入点
singletonObject = singletonFactory.getObject();
// 放入earlySingletonObjects中
this.earlySingletonObjects.put(beanName, singletonObject);
this.singletonFactories.remove(beanName);
}
}
}
}
return (singletonObject != NULL_OBJECT ? singletonObject : null);
}
这个方法其实挺简单的，复杂的点主要是针对循环依赖的问题做了个性化处理：如果目标bean正在实例化，则从
earlySingletonObjects或者singletonFactories获取。（注：获取的bean其实还未完全实例化，因为还未注入属性）。没有循环依赖的情况就直接返回结果。
第二个重载方法：
// org.springframework.beans.factory.support.DefaultSingletonBeanRegistry
// 请注意！第二个入参是ObjectFactory！
public Object getSingleton(String beanName, ObjectFactory<?> singletonFactory) {
Assert.notNull(beanName, "'beanName' must not be null");
synchronized (this.singletonObjects) {
Object singletonObject = this.singletonObjects.get(beanName);
if (singletonObject == null) {
if (this.singletonsCurrentlyInDestruction) {
throw new BeanCreationNotAllowedException(beanName,
"Singleton bean creation not allowed while singletons of this factory are in destruction " +
"(Do not request a bean from a BeanFactory in a destroy method implementation!)");
}
if (logger.isDebugEnabled()) {
logger.debug("Creating shared instance of singleton bean '" + beanName + "'");
}
// 前处理，逻辑是在singletonsCurrentlyInCreation加入当前bean
// 用于标志当前bean已进入实例化bean阶段！
beforeSingletonCreation(beanName);
boolean newSingleton = false;
boolean recordSuppressedExceptions = (this.suppressedExceptions == null);
if (recordSuppressedExceptions) {
this.suppressedExceptions = new LinkedHashSet<Exception>();
}
try {
// 重头戏，后面重点分析，其实逻辑是createBean方法
singletonObject = singletonFactory.getObject();
newSingleton = true;
}
catch (IllegalStateException ex) {
// Has the singleton object implicitly appeared in the meantime ->
// if yes, proceed with it since the exception indicates that state.
singletonObject = this.singletonObjects.get(beanName);
if (singletonObject == null) {
throw ex;
}
}
catch (BeanCreationException ex) {
if (recordSuppressedExceptions) {
for (Exception suppressedException : this.suppressedExceptions) {
ex.addRelatedCause(suppressedException);
}
}
throw ex;
}
finally {
if (recordSuppressedExceptions) {
this.suppressedExceptions = null;
}
// 从singletonsCurrentlyInCreation移除当前bean
// 标志着bean初始化结束
afterSingletonCreation(beanName);
}
if (newSingleton) {
// 加入singletonObjects、registeredSingletons
// 移除singletonFactories、earlySingletonObjects
addSingleton(beanName, singletonObject);
}
}
return (singletonObject != NULL_OBJECT ? singletonObject : null);
}
}
分析下createBean方法，这个方法是真正的实例化bean的地方
// org.springframework.beans.factory.support.DefaultListableBeanFactory
protected Object createBean(String beanName, RootBeanDefinition mbd, Object[] args) throws BeanCreationException {
if (logger.isDebugEnabled()) {
logger.debug("Creating instance of bean '" + beanName + "'");
}
RootBeanDefinition mbdToUse = mbd;
// Make sure bean class is actually resolved at this point, and
// clone the bean definition in case of a dynamically resolved Class
// which cannot be stored in the shared merged bean definition.
Class<?> resolvedClass = resolveBeanClass(mbd, beanName);
if (resolvedClass != null && !mbd.hasBeanClass() && mbd.getBeanClassName() != null) {
mbdToUse = new RootBeanDefinition(mbd);
mbdToUse.setBeanClass(resolvedClass);
}
// Prepare method overrides.
// 很少见用的，不了解不分析
try {
mbdToUse.prepareMethodOverrides();
}
catch (BeanDefinitionValidationException ex) {
throw new BeanDefinitionStoreException(mbdToUse.getResourceDescription(),
beanName, "Validation of method overrides failed", ex);
}
try {
// Give BeanPostProcessors a chance to return a proxy instead of the target bean instance.
// 尝试使用InstantiationAwareBeanPostProcessor返回bean
// 用的比较少，好像springAop中有使用
Object bean = resolveBeforeInstantiation(beanName, mbdToUse);
if (bean != null) {
return bean;
}
}
catch (Throwable ex) {
throw new BeanCreationException(mbdToUse.getResourceDescription(), beanName,
"BeanPostProcessor before instantiation of bean failed", ex);
}
//doXXX才是真正的逻辑！
Object beanInstance = doCreateBean(beanName, mbdToUse, args);
if (logger.isDebugEnabled()) {
logger.debug("Finished creating instance of bean '" + beanName + "'");
}
return beanInstance;
}
// org.springframework.beans.factory.support.DefaultListableBeanFactory
protected Object doCreateBean(final String beanName, final RootBeanDefinition mbd, final Object[] args)
throws BeanCreationException {
// Instantiate the bean.
BeanWrapper instanceWrapper = null;
if (mbd.isSingleton()) {
instanceWrapper = this.factoryBeanInstanceCache.remove(beanName);
}
if (instanceWrapper == null) {
// 创建bean实例，这里返回的实例是没有填充过属性的！
instanceWrapper = createBeanInstance(beanName, mbd, args);
}
final Object bean = (instanceWrapper != null ? instanceWrapper.getWrappedInstance() : null);
Class<?> beanType = (instanceWrapper != null ? instanceWrapper.getWrappedClass() : null);
mbd.resolvedTargetType = beanType;
// Allow post-processors to modify the merged bean definition.
synchronized (mbd.postProcessingLock) {
if (!mbd.postProcessed) {
try {
// 很少见到用，可能某些框架会用吧，暂无能力分析
applyMergedBeanDefinitionPostProcessors(mbd, beanType, beanName);
}
catch (Throwable ex) {
throw new BeanCreationException(mbd.getResourceDescription(), beanName,
"Post-processing of merged bean definition failed", ex);
}
mbd.postProcessed = true;
}
}
// Eagerly cache singletons to be able to resolve circular references
// even when triggered by lifecycle interfaces like BeanFactoryAware.
// 是否允许早期单例暴露，怎么理解呢，其实就是这个组件还没完全初始化完，是否要暴露出去
// 一般都是true
// 用于解决循环依赖的问题
boolean earlySingletonExposure = (mbd.isSingleton() && this.allowCircularReferences &&
isSingletonCurrentlyInCreation(beanName));
if (earlySingletonExposure) {
if (logger.isDebugEnabled()) {
logger.debug("Eagerly caching bean '" + beanName +
"' to allow for resolving potential circular references");
}
// 添加到SingletonFactory
// 前面提过一嘴singletonFactory的问题，逻辑实现在这
addSingletonFactory(beanName, new ObjectFactory<Object>() {
@Override
public Object getObject() throws BeansException {
// 正常情况下直接返回bean，但是要素aop增强这类的情况要特殊处理，暂不分析
return getEarlyBeanReference(beanName, mbd, bean);
}
});
}
// Initialize the bean instance.
Object exposedObject = bean;
try {
// 填充属性，包括各种依赖等，我打算当个黑盒分析，逻辑很复杂，目前本人能力不够...
populateBean(beanName, mbd, instanceWrapper);
if (exposedObject != null) {
// 初始化bean，beanPostProcessor接口的切人点就在这，还有InitializingBean接口的切入点也在这
// 逻辑比较简单，总而言之是支持对实例化后的bean做个性化的改造
exposedObject = initializeBean(beanName, exposedObject, mbd);
}
}
catch (Throwable ex) {
if (ex instanceof BeanCreationException && beanName.equals(((BeanCreationException) ex).getBeanName())) {
throw (BeanCreationException) ex;
}
else {
throw new BeanCreationException(
mbd.getResourceDescription(), beanName, "Initialization of bean failed", ex);
}
}
// 这部分暂不分析，不理解，太菜了！
if (earlySingletonExposure) {
Object earlySingletonReference = getSingleton(beanName, false);
if (earlySingletonReference != null) {
if (exposedObject == bean) {
exposedObject = earlySingletonReference;
}
else if (!this.allowRawInjectionDespiteWrapping && hasDependentBean(beanName)) {
String[] dependentBeans = getDependentBeans(beanName);
Set<String> actualDependentBeans = new LinkedHashSet<String>(dependentBeans.length);
for (String dependentBean : dependentBeans) {
if (!removeSingletonIfCreatedForTypeCheckOnly(dependentBean)) {
actualDependentBeans.add(dependentBean);
}
}
if (!actualDependentBeans.isEmpty()) {
throw new BeanCurrentlyInCreationException(beanName,
"Bean with name '" + beanName + "' has been injected into other beans [" +
StringUtils.collectionToCommaDelimitedString(actualDependentBeans) +
"] in its raw version as part of a circular reference, but has eventually been " +
"wrapped. This means that said other beans do not use the final version of the " +
"bean. This is often the result of over-eager type matching - consider using " +
"'getBeanNamesOfType' with the 'allowEagerInit' flag turned off, for example.");
}
}
}
}
// Register bean as disposable.
try {
registerDisposableBeanIfNecessary(beanName, bean, mbd);
}
catch (BeanDefinitionValidationException ex) {
throw new BeanCreationException(
mbd.getResourceDescription(), beanName, "Invalid destruction signature", ex);
}
return exposedObject;
}
总结
简单总结提炼下spring获取组件的过程，面对一大堆的源码难免晕头转向。
-
在基于使用注解方式下的spring，用于实例化的组件是
DefaultListableBeanFactory -
DefaultListableBeanFactory中有四个变量singletonObjects、singletonFactories、earlySingletonObjects、singletonsCurrentlyInCreation，用来存储单例和解决循环依赖的问题 -
获取组件是从
DefaultListableBeanFactory获取，组件存的地方是singletonObjects，如果有就直接返回，没有得分情况考虑：-
循环依赖的情况，有个标志是
singletonsCurrentlyInCreation中会存储该bean，这种情况先从组件earlySingletonObjects中获取，没有再从singletonFactories获取，需要注意的是此时获取的组件bean是未完全实例化完的，因为属性还未完全注入 -
非循环依赖的情况，其实就是组件中没有这个实例，那么现在的工作就是实例化bean，实例化bean的过程总结来看就一下几点：
-
根据bean定义分析用哪种构造方式实例化bean：自动注入 or 无参构造 等等，此时将获得一个原始组件bean，即还未经过属性注入
-
将原始bean进行
earlySingletonExposure，即存放到singletonFactories中 -
分析属性依赖进行组件的属性注入
-
初始化bean，即针对组件调用BeanPostProcessor、InitializingBean等接口的方法
-
-
图解说明spring是如何解决循环依赖问题的
上面在分析spring实例化组件过程的时候穿插说明了spring是如何解决循环依赖的，但感觉不够直观，为了便于理解，我简单画了个小漫画，总结下spring对循环依赖的处理。
最后
从源码角度分析理解了spring是如何获取bean的，其实工作中一般会封个SpringContextUtils方便在全局范围获取容器组件。经过这次分析学习后对其中的过程理解更深刻了，以后用起来也会更顺手，就算报错看到那一堆堆栈也没那么慌了，哈哈！由于本人水平还是太菜，有些较复杂地方当黑盒直接跳过了，比如属性填充，自动注入的构造方式，等等。当然，文中的一些分析肯定有理解不到位的地方，希望大家不吝赐教指出，也期待自己以后在经验更丰富的时候能对本文进行完善！
扫一扫
344
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
