结束了两天的河北游,终于回到帝都,这周事情比较多,然而还得继续把上周欠下的债给补上,这一节咱们主要分析一下Spring-IOC中之前被忽略的那些细节以及一些常见的Spring-IOC的面试题。
Bean在创建的时候可以给该Bean做校验,如果递归调用回来发现正在创建中的话,即说明了循环依赖。其实这点和Spring初始化的时候读配置文件涉及到import关键字会导致循环导入时的处理手法是一致的。
【DefaultSingletonBeanRegistry】
protected void beforeSingletonCreation(String beanName) {
if (!this.singletonsCurrentlyInCreation.add(beanName)) {
throw new BeanCurrentlyInCreationException(beanName);
}
}
上图是个单例Bean创建的实例,在创建之前先打标,然后在实例化的时候如果发现已经在创建了,就抛出异常。
【AbstractBeanFactory】
if (isPrototypeCurrentlyInCreation(beanName)) {
throw new BeanCurrentlyInCreationException(beanName);
}
1.4、Spring解决循环依赖的几个缓存
【DefaultSingletonBeanRegistry】中
【AbstractBeanFactory】中
if (isPrototypeCurrentlyInCreation(beanName)) {
throw new BeanCurrentlyInCreationException(beanName);
}
//如果不是做类型检查则是创建bean,这里要进行记录
if (!typeCheckOnly) {
markBeanAsCreated(beanName);
}
//是否需要提前曝光:单例&允许循环依赖&当bean正在创建中,检测循环依赖
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");
}
//为避免后期循环依赖,可以在bean初始化完成前将创建实例的ObjectFactory加入工厂
addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));
}
为什么不把Bean暴露出去,而是暴露个Factory呢?因为有些Bean是需要被代理的,看下getEarlyBeanReference的实现:
- 【AbstractAutowareCapableBeanFactory】
- 3、getEarlyBeanReference()
protected Object getEarlyBeanReference(String beanName, RootBeanDefinition mbd, Object bean) {
Object exposedObject = bean;
if (!mbd.isSynthetic() && hasInstantiationAwareBeanPostProcessors()) {
for (Iterator it = getBeanPostProcessors().iterator(); it.hasNext(); ) {
BeanPostProcessor bp = (BeanPostProcessor) it.next();
if (bp instanceof SmartInstantiationAwareBeanPostProcessor) {
SmartInstantiationAwareBeanPostProcessor ibp = (SmartInstantiationAwareBeanPostProcessor) bp;
exposedObject = ibp.getEarlyBeanReference(exposedObject, beanName);
}
}
}
return exposedObject;
}
当你依赖到了该Bean而单例缓存里面有没有该Bean的时候就会调用该工厂方法生产Bean,看下getSingleton的实现:
- 【DefaultSingletonBeanRegistry】中
- getSingleton()
protected Object getSingleton(String beanName, boolean allowEarlyReference) {
Object singletonObject = this.singletonObjects.get(beanName);
if (singletonObject == null) {
synchronized (this.singletonObjects) {
singletonObject = this.earlySingletonObjects.get(beanName);
if (singletonObject == null && allowEarlyReference) {
ObjectFactory singletonFactory = (ObjectFactory) this.singletonFactories.get(beanName);
if (singletonFactory != null) {
singletonObject = singletonFactory.getObject();
this.earlySingletonObjects.put(beanName, singletonObject);
this.singletonFactories.remove(beanName);
}
}
}
}
return (singletonObject != NULL_OBJECT ? singletonObject : null);
}
【AbstractAutoProxyCreator】
public Object getEarlyBeanReference(Object bean, String beanName) throws BeansException {
Object cacheKey = getCacheKey(bean.getClass(), beanName);
this.earlyProxyReferences.add(cacheKey);
return wrapIfNecessary(bean, beanName, cacheKey);
}
【AbstractAutoProxyCreator】
public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
Object cacheKey = getCacheKey(bean.getClass(), beanName);
if (!this.earlyProxyReferences.contains(cacheKey)) {
return wrapIfNecessary(bean, beanName, cacheKey);
}
return bean;
}
这个BeanPostProcessor很典型了,用于创建代理类的。一般这种BeanPostProcessor总要提供一个getEarlyBeanReference的接口供其他Bean使用,而又防止了其他类直接使用到该类最原始的版本。这就是上述两个方法如此相似的原因。置于略微的差异,你应该看出来,是防止重复执行方法。
protected Object initializeBean(final String beanName, final Object bean, @Nullable RootBeanDefinition mbd) {
if (System.getSecurityManager() != null) {
AccessController.doPrivileged((PrivilegedAction;
}
else {
invokeAwareMethods(beanName, bean);
}
Object wrappedBean = bean;
if (mbd == null || !mbd.isSynthetic()) {
wrappedBean = applyBeanPostProcessorsBeforeInitialization(wrappedBean, beanName);
}
if (wrappedBean != null) {
try {
invokeInitMethods(beanName, wrappedBean, mbd);
}
catch (Throwable ex) {
throw new BeanCreationException(
(mbd != null ? mbd.getResourceDescription() : null),
beanName, "Invocation of init method failed", ex);
}
if (mbd == null || !mbd.isSynthetic()) {
wrappedBean = applyBeanPostProcessorsAfterInitialization(wrappedBean, beanName);
}
}
return wrappedBean;
}
你不能保证这些乱七八糟的BeanPostProcessor会不会改变Bean的版本,当然,如果改变了,肯定要出错的,在这里,Spring就没有做依赖解决了,只是做了依赖检查
- 1.5、Spring解决不了的循环依赖
解决不了的,只能采用依赖检查
【AbstractAutowareCapableBeanFactory】
Object earlySingletonReference = getSingleton(beanName, false);
//只有在检测到有循环依赖的情况下才会不为空
if (earlySingletonReference != null) {
//如果exposedObject没有在初始化方法中被改变,也就是没有被增强
if (exposedObject == bean) {
exposedObject = earlySingletonReference;
}
else if (!this.allowRawInjectionDespiteWrapping && hasDependentBean(beanName)) {
String[] dependentBeans = getDependentBeans(beanName);
Set actualDependentBeans = new LinkedHashSet<>(dependentBeans.length);
//检测依赖
for (String dependentBean : dependentBeans) {
if (!removeSingletonIfCreatedForTypeCheckOnly(dependentBean)) {
actualDependentBeans.add(dependentBean);
}
}
/**
* 因为bean创建后其锁依赖的bean一定是已经创建的
* actualDependentBeans不为空则表示当前bean创建后其依赖的bean却没有全部创建完,也就是说存在循环依赖
*/
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.");
}
}
}
1、当发现最初的Bean和ExposedObject不一致的时候(这里其实值得推敲的,只有BeanPostProcessor会导致Bean的版本更新,但是负责处理代理的BeanPostProcessor也会导致版本更新,最后岂不是和普通的BeanPostProcessor一样走到else里面去抛异常了,诡异了!仔细想想负责处理代理的BeanPostProcessor是不会导致Bean的版本更新的,所以最后要把getSingleton取出来的最新版本的Bean赋给它,好好理解吧,真不知道怎么解释了)就会走到else里面,看看else里面的逻辑:
2、检查所以依赖到该Bean的哪些Bean们,如果他们已经创建了,那么抛异常!这就是为什么用alreadyCreated的原因,因为原型Bean C如果依赖到了该Bean A的话,原型Bean C还能用么?当然作废了,而且还无法解决,框架只能抛异常告诉程序员。
Spring不能完全解决的循环依赖问题?
1、构造方法注入的bean
2、BeanPostProcessor改变了Bean的版本,AbstractAutoProxyCreator等除外
3、原型Bean
面对这样的问题我们该如何解决?
参考 事例