写在前面的话#
相关背景及资源：
曹工说Spring Boot源码（1）-- Bean Definition到底是什么，附spring思维导图分享
曹工说Spring Boot源码（2）-- Bean Definition到底是什么，咱们对着接口，逐个方法讲解
曹工说Spring Boot源码（3）-- 手动注册Bean Definition不比游戏好玩吗，我们来试一下
曹工说Spring Boot源码（4）-- 我是怎么自定义ApplicationContext，从json文件读取bean definition的？
曹工说Spring Boot源码（5）-- 怎么从properties文件读取bean
曹工说Spring Boot源码（6）-- Spring怎么从xml文件里解析bean的
曹工说Spring Boot源码（7）-- Spring解析xml文件，到底从中得到了什么（上）
曹工说Spring Boot源码（8）-- Spring解析xml文件，到底从中得到了什么（util命名空间）
曹工说Spring Boot源码（9）-- Spring解析xml文件，到底从中得到了什么（context命名空间上）
曹工说Spring Boot源码（10）-- Spring解析xml文件，到底从中得到了什么（context:annotation-config 解析）
曹工说Spring Boot源码（11）-- context:component-scan，你真的会用吗（这次来说说它的奇技淫巧）
曹工说Spring Boot源码（12）-- Spring解析xml文件，到底从中得到了什么（context:component-scan完整解析)
曹工说Spring Boot源码（13）-- AspectJ的运行时织入（Load-Time-Weaving），基本内容是讲清楚了（附源码）
曹工说Spring Boot源码（14）-- AspectJ的Load-Time-Weaving的两种实现方式细细讲解，以及怎么和Spring Instrumentation集成
曹工说Spring Boot源码（15）-- Spring从xml文件里到底得到了什么（context：load-time-weaver 完整解析）
曹工说Spring Boot源码（16）-- Spring从xml文件里到底得到了什么（aop：config完整解析【上】）
曹工说Spring Boot源码（17）-- Spring从xml文件里到底得到了什么（aop：config完整解析【中】）
曹工说Spring Boot源码（18）-- Spring AOP源码分析三部曲，终于快讲完了 (aop：config完整解析【下】)
曹工说Spring Boot源码（19）-- Spring 带给我们的工具利器，创建代理不用愁（ProxyFactory）
曹工说Spring Boot源码（20）-- 码网恢恢，疏而不漏，如何记录Spring RedisTemplate每次操作日志
曹工说Spring Boot源码（21）-- 为了让大家理解Spring Aop利器ProxyFactory，我已经拼了
曹工说Spring Boot源码（22）-- 你说我Spring Aop依赖AspectJ，我依赖它什么了
曹工说Spring Boot源码（23）-- ASM又立功了，Spring原来是这么递归获取注解的元注解的
曹工说Spring Boot源码（24）-- Spring注解扫描的瑞士军刀，asm技术实战（上）
曹工说Spring Boot源码（25）-- Spring注解扫描的瑞士军刀，ASM + Java Instrumentation，顺便提提Jar包破解
曹工说Spring Boot源码（26）-- 学习字节码也太难了，实在不能忍受了，写了个小小的字节码执行引擎
曹工说Spring Boot源码（27）-- Spring的component-scan，光是include-filter属性的各种配置方式，就够玩半天了
曹工说Spring Boot源码（28）-- Spring的component-scan机制，让你自己来进行简单实现，怎么办
工程结构图：
什么是三级缓存#
在获取单例bean的时候，会进入以下方法：
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry#getSingleton(java.lang.String, boolean)
protected Object getSingleton(String beanName, boolean allowEarlyReference) {
// 1
Object singletonObject = this.singletonObjects.get(beanName);
if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {
synchronized (this.singletonObjects) {
// 2
singletonObject = this.earlySingletonObjects.get(beanName);
if (singletonObject == null && allowEarlyReference) {
// 3
ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName);
if (singletonFactory != null) {
// 4
singletonObject = singletonFactory.getObject();
this.earlySingletonObjects.put(beanName, singletonObject);
this.singletonFactories.remove(beanName);
}
}
}
}
return singletonObject;
}
这里面涉及到了该类中的三个field。
/** 1级缓存 Cache of singleton objects: bean name to bean instance. */
private final Map<String, Object> singletonObjects = new ConcurrentHashMap<>(256);
/** 2级缓存 Cache of early singleton objects: bean name to bean instance. */
private final Map<String, Object> earlySingletonObjects = new HashMap<>(16);
/** 3级缓存 Cache of singleton factories: bean name to ObjectFactory. */
private final Map<String, ObjectFactory<?>> singletonFactories = new HashMap<>(16);
接着说前面的代码。
-
1处，在最上层的缓存
singletonObjects中，获取单例bean，这里面拿到的bean，直接可以使用；如果没取到，则进入2处 -
2处，在2级缓存
earlySingletonObjects中，查找bean； -
3处，如果在2级缓存中，还是没找到，则在3级缓存中查找对应的工厂对象，利用拿到的工厂对象（工厂对象中，有3个field，一个是beanName，一个是RootBeanDefinition，一个是已经创建好的，但还没有注入属性的bean），去获取包装后的bean，或者说，代理后的bean。
什么是已经创建好的，但没有注入属性的bean？
比如一个bean，有10个字段，你new了之后，对象已经有了，内存空间已经开辟了，堆里已经分配了该对象的空间了，只是此时的10个field还是null。
ioc容器，普通循环依赖，一级缓存够用吗#
说实话，如果简单写写的话，一级缓存都没问题。给大家看一个我以前写的渣渣ioc容器：
曹工说Tomcat4：利用 Digester 手撸一个轻量的 Spring IOC容器
@Data
public class BeanDefinitionRegistry {
/**
* map：存储 bean的class-》bean实例
*/
private Map<Class, Object> beanMapByClass = new ConcurrentHashMap<>();
/**
* 根据bean 定义获取bean
* 1、先查bean容器，查到则返回
* 2、生成bean，放进容器（此时，依赖还没注入，主要是解决循环依赖问题）
* 3、注入依赖
*
* @param beanDefiniton
* @return
*/
private Object getBean(MyBeanDefiniton beanDefiniton) {
Class<?> beanClazz = beanDefiniton.getBeanClazz();
Object bean = beanMapByClass.get(beanClazz);
if (bean != null) {
return bean;
}
// 0
bean = generateBeanInstance(beanClazz);
// 1 先行暴露，解决循环依赖问题
beanMapByClass.put(beanClazz, bean);
beanMapByName.put(beanDefiniton.getBeanName(), bean);
// 2 查找依赖
List<Field> dependencysByField = beanDefiniton.getDependencysByField();
if (dependencysByField == null) {
return bean;
}
// 3
for (Field field : dependencysByField) {
try {
autowireField(beanClazz, bean, field);
} catch (Exception e) {
throw new RuntimeException(beanClazz.getName() + " 创建失败",e);
}
}
return bean;
}
}
大家看上面的代码，我只定义了一个field，就是一个map，存放bean的class-》bean。
/**
* map：存储 bean的class-》bean实例
*/
private Map<Class, Object> beanMapByClass = new ConcurrentHashMap<>();
- 0处，生成bean，直接就是new
- 1处，先把这个不完整的bean，放进map
- 2处，获取需要注入的属性集合
- 3处，进行自动注入，就是根据field的Class，去map里查找对应的bean，设置到field里。
上面这个代码，有啥问题没？spring为啥整整三级？
ioc，一级缓存有什么问题#
一级缓存的问题在于，就1个map，里面既有完整的已经ready的bean，也有不完整的，尚未设置field的bean。
如果这时候，有其他线程去这个map里获取bean来用怎么办？拿到的bean，不完整，怎么办呢？属性都是null，直接空指针了。
所以，我们就要加一个map，这个map，用来存放那种不完整的bean。这里，还是拿spring举例。我们可以只用下面这两层：
/** 1级缓存 Cache of singleton objects: bean name to bean instance. */
private final Map<String, Object> singletonObjects = new ConcurrentHashMap<>(256);
/** 2级缓存 Cache of early singleton objects: bean name to bean instance. */
private final Map<String, Object> earlySingletonObjects = new HashMap<>(16);
因为spring代码里是三级缓存，所以我们对源码做一点修改。
修改spring源码，只使用二级缓存#
修改创建bean的代码，不放入第三级缓存，只放入第二级缓存#
创建了bean之后，属性注入之前，将创建出来的不完整bean，放到earlySingletonObjects
这个代码，在org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory#doCreateBean，我这边只有4.0版本的spring源码工程，不过这套逻辑，算是spring核心逻辑，和5.x版本差别不大。
protected Object doCreateBean(final String beanName, final RootBeanDefinition mbd, final Object[] args) {
BeanWrapper instanceWrapper = null;
if (mbd.isSingleton()) {
instanceWrapper = this.factoryBeanInstanceCache.remove(beanName);
}
if (instanceWrapper == null) {
// 1
instanceWrapper = createBeanInstance(beanName, mbd, args);
}
final Object bean = (instanceWrapper != null ? instanceWrapper.getWrappedInstance() : null);
Class beanType = (instanceWrapper != null ? instanceWrapper.getWrappedClass() : null);
...
boolean earlySingletonExposure = (mbd.isSingleton() && this.allowCircularReferences &&
isSingletonCurrentlyInCreation(beanName));
if (earlySingletonExposure) {
// 2
earlySingletonObjects.put(beanName,bean);
registeredSingletonObjects.add(beanName);
// 3
// addSingletonFactory(beanName, new ObjectFactory() {
// public Object getObject() throws BeansException {
// return getEarlyBeanReference(beanName, mbd, bean);
// }
// });
}
- 1处，就是创建对象，就是new
- 2处，这是我加的代码，放入二级缓存
- 3处，本来这就是增加三级缓存的位置，被我注释了。现在，就不会往三级缓存放东西了
修改获取bean的代码，只从第一、第二级缓存获取，不从第三级获取#
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry#getSingleton(java.lang.String, boolean)
之前的代码是文章开头那样的，我这里修改为：
protected Object getSingleton(String beanName, boolean allowEarlyReference) {
Object singletonObject = this.singletonObjects.get(beanName);
if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {
synchronized (this.singletonObjects) {
singletonObject = this.earlySingletonObjects.get(beanName);
return singletonObject;
}
}
return (singletonObject != NULL_OBJECT ? singletonObject : null);
这样，就是只用两级缓存了。
两级缓存，有啥问题？#
ioc循环依赖，一点问题都没有，完全够用了。
我这边一个简单的例子，
public class Chick{
private Egg egg;
public Egg getEgg() {
return egg;
}
public void setEgg(Egg egg) {
this.egg = egg;
}
}
public class Egg {
private Chick chick;
public Chick getChick() {
return chick;
}
public void setChick(Chick chick) {
this.chick = chick;
}
<bean id="chick" class="foo.Chick" lazy-init="true">
<property name="egg" ref="egg"/>
</bean>
<bean id="egg" class="foo.Egg" lazy-init="true">
<property name="chick" ref="chick"/>
</bean>
ClassPathXmlApplicationContext ctx = new ClassPathXmlApplicationContext(
"context-namespace-test-aop.xml");
Egg egg = (Egg) ctx.getBean(Egg.class);
结论：
所以，一级缓存都能解决的问题，二级当然更没问题。
但是，如果我这里给上面的Egg类，加个切面（aop的逻辑，意思就是最终会生成Egg的一个动态代理对象），那还有问题没？
<aop:config>
<aop:pointcut id="mypointcut" expression="execution(public * foo.Egg.*(..))"/>
<aop:aspect id="myAspect" ref="performenceAspect">
<aop:after method="afterIncubate" pointcut-ref="mypointcut"/>
</aop:aspect>
</aop:config>
注意这里的切点：
execution(public * foo.Egg.*(..))
就是切Egg类的方法。
加了这个逻辑后，我们继续运行，在 Egg egg = (Egg) ctx.getBean(Egg.class);行，会抛出如下异常：
我涂掉了一部分，因为那是官方对这个异常的推论，因为我们改了代码，所以推论不准确，因此干脆隐去。
这个异常是说：
兄弟啊，bean egg已经被注入到了其他bean：chick中。（因为我们循环依赖了），但是，注入到chick中的，是Egg类型。但是，我们这里最后对egg这个bean，进行了后置处理，生成了代理对象。那其他bean里，用原始的bean，是不是不太对啊？
所以，spring给我们抛错了。
怎么理解呢？ 以io流举例，我们一开始都是用的原始字节流，然后给别人用的也是字节流，但是，最后，我感觉不方便，我自己悄悄弄了个缓存字符流（类比代理对象），我是方便了，但是，别人用的，还是原始的字节流啊。
你bean不是单例吗？不能这么玩吧？
所以，这就是二级缓存，不能解决的问题。
什么问题？aop情形下，注入到其他bean的，不是最终的代理对象。
三级缓存，怎么解决这个问题#
要解决这个问题，必须在其他bean（chick），来查找我们（以上面例子为例，我们是egg）的时候，查找到最终形态的egg，即代理后的egg。
怎么做到这点呢？
加个三级缓存，里面不存具体的bean，里面存一个工厂对象。通过工厂对象，是可以拿到最终形态的代理后的egg。
ok，我们将前面修改的代码还原：
protected Object doCreateBean(final String beanName, final RootBeanDefinition mbd, final Object[] args) {
BeanWrapper instanceWrapper = null;
if (mbd.isSingleton()) {
instanceWrapper = this.factoryBeanInstanceCache.remove(beanName);
}
if (instanceWrapper == null) {
// 1
instanceWrapper = createBeanInstance(beanName, mbd, args);
}
final Object bean = (instanceWrapper != null ? instanceWrapper.getWrappedInstance() : null);
Class beanType = (instanceWrapper != null ? instanceWrapper.getWrappedClass() : null);
boolean earlySingletonExposure = (mbd.isSingleton() && this.allowCircularReferences &&
isSingletonCurrentlyInCreation(beanName));
if (earlySingletonExposure) {
// 2
// Map<String, Object> earlySingletonObjects = this.getEarlySingletonObjects();
// earlySingletonObjects.put(beanName,bean);
//
// Set<String> registeredSingletonObjects = this.getRegisteredSingletonObjects();
// registeredSingletonObjects.add(beanName);
// 3
addSingletonFactory(beanName, new ObjectFactory() {
public Object getObject() throws BeansException {
return getEarlyBeanReference(beanName, mbd, bean);
}
});
}
-
1处，创建bean，单纯new，不注入
-
2处，revert我们的代码
-
3处，这里new了一个ObjectFactory，然后会存入到如下的第三级缓存。
/** 3级缓存 Cache of singleton factories: bean name to ObjectFactory. */ private final Map<String, ObjectFactory<?>> singletonFactories = new HashMap<>(16);注意，new一个匿名内部类（假设这个匿名类叫AA）的对象，其中用到的外部类的变量，都会在AA中隐式生成对应的field。
大家看上图，里面的3个字段，和下面代码1处中的，几个字段，是一一对应的。
addSingletonFactory(beanName, new ObjectFactory() { public Object getObject() throws BeansException { // 1 return getEarlyBeanReference(beanName, mbd, bean); } });
ok，现在，egg已经把自己存进去了，存在了第三级缓存，1级和2级都没有，那后续chick在使用getSingleton查找egg的时候，就会进入下面的逻辑了（就是文章开头的那段代码,下面已经把我们的修改还原了）：
protected Object getSingleton(String beanName, boolean allowEarlyReference) {
// Object singletonObject = this.singletonObjects.get(beanName);
// if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {
// synchronized (this.singletonObjects) {
// singletonObject = this.earlySingletonObjects.get(beanName);
// return singletonObject;
// }
// }
// return (singletonObject != NULL_OBJECT ? singletonObject : null);
Object singletonObject = this.singletonObjects.get(beanName);
if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {
synchronized (this.singletonObjects) {
singletonObject = this.earlySingletonObjects.get(beanName);
if (singletonObject == null && allowEarlyReference) {
ObjectFactory singletonFactory = this.singletonFactories.get(beanName);
if (singletonFactory != null) {
// 1
singletonObject = singletonFactory.getObject();
this.earlySingletonObjects.put(beanName, singletonObject);
this.singletonFactories.remove(beanName);
}
}
}
}
return (singletonObject != NULL_OBJECT ? singletonObject : null);
}
上面就会进入1处，调用singletonFactory.getObject();。
而前面我们知道，这个factory的逻辑是：
addSingletonFactory(beanName, new ObjectFactory() {
public Object getObject() throws BeansException {
// 1
return getEarlyBeanReference(beanName, mbd, bean);
}
});
1处就是这个工厂方法的逻辑，这里面，简单说，就会去调用各个beanPostProcessor的getEarlyBeanReference方法。
其中，主要就是aop的主力beanPostProcessor，AbstractAutoProxyCreator#getEarlyBeanReference
其实现如下：
public Object getEarlyBeanReference(Object bean, String beanName) throws BeansException {
Object cacheKey = getCacheKey(bean.getClass(), beanName);
this.earlyProxyReferences.add(cacheKey);
// 1
return wrapIfNecessary(bean, beanName, cacheKey);
}
这里的1处，就会去对egg这个bean，创建代理，此时，返回的对象，就是个代理对象了，那，注入到chick的，自然也是代理后的egg了。
关于SmartInstantiationAwareBeanPostProcessor#
我们上面说的那个getEarlyBeanReference就在这个接口中。
这个接口继承了BeanPostProcessor。
而创建代理对象，目前就是在如下两个方法中去创建：
public interface BeanPostProcessor {
Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException;
Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException;
}
这两个方法，都是在实例化之后，创建代理。那我们前面创建代理，是在依赖解析过程中：
public interface SmartInstantiationAwareBeanPostProcessor extends InstantiationAwareBeanPostProcessor {
...
Object getEarlyBeanReference(Object bean, String beanName) throws BeansException;
}
所以，spring希望我们，在这几处，要返回同样的对象，即：既然你这几处都要返回代理对象，那就不能返回不一样的代理对象。
那我们再看看，到底，AbstractAutoProxyCreator有没有遵守约定呢，这几个方法里，有没有去返回同样的代理包装对象呢？
getEarlyBeanReference#
public Object getEarlyBeanReference(Object bean, String beanName) throws BeansException {
Object cacheKey = getCacheKey(bean.getClass(), beanName);
// 1
this.earlyProxyReferences.add(cacheKey);
return wrapIfNecessary(bean, beanName, cacheKey);
}
1处，往field：
private final Set<Object> earlyProxyReferences =
Collections.newSetFromMap(new ConcurrentHashMap<Object, Boolean>(16));
里，加了个cachekey，这个cachekey，主要也就是如下的字符串，用来唯一标识而已。
protected Object getCacheKey(Class<?> beanClass, String beanName) {
return beanClass.getName() + "_" + beanName;
}
我们可以看看这个field在哪里被用到了。
也就两处，一处就是当前位置；另外一处，下面讲。
这里，主要就是看看到底要不要生成代理对象，要的话，就生成，不要就算了，另外，做了个标记：在earlyProxyReferences加了当前bean的key，表示：当前bean，已经被getEarlyBeanReference方法处理过了。
至于，最终到底有没有生成代理对象，另说。毕竟调用wrapIfNecessary也不是说，一定就满足切面，要生成代理对象。
可能返回的仍然是原始对象。
postProcessBeforeInitialization#
public Object postProcessBeforeInitialization(Object bean, String beanName) {
return bean;
}
这一处，没做处理。
postProcessAfterInitialization#
public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
if (bean != null) {
Object cacheKey = getCacheKey(bean.getClass(), beanName);
// 1
if (!this.earlyProxyReferences.contains(cacheKey)) {
return wrapIfNecessary(bean, beanName, cacheKey);
}
}
return bean;
}
这里,1处这个判断哈，就用到了前面我们说的那个field。那个field，只在两处用，一处就是调用getEarlyBeanReference，会往里面把当前bean的key放进去；另外一处，就是这里。
这里判断，如果field里不包含当前bean，就去调用wrapIfNecessary；如果包含（意味着，getEarlyBeanReference处理过了），就不调用了。
这里，说到底，就是保证了，wrapIfNecessary只被调用一次。
看吧，wrapIfNecessary也就这两处被调用了。
所以，我们可以得出结论，在aop这个beanPostProcessor中，有多处机会可以返回一个proxy对象，但是，最终，只要在其中一处处理了，其他处，根本不再继续处理。
另外，还有一点很重要，在这个aop beanPostProcessor中，传入了原始的bean，我们会去判断，是否要给它创建代理，如果要，就创建；如果不要则：
返回原始对象。
整个流程串起来#
上面这个后置处理器看明白了，接下来，再看看创建bean的核心流程：
protected Object doCreateBean(final String beanName, final RootBeanDefinition mbd, final Object[] args) {
// 1
BeanWrapper instanceWrapper = createBeanInstance(beanName, mbd, args);
final Object bean = instanceWrapper.getWrappedInstance();
if (earlySingletonExposure) {
// 2
addSingletonFactory(beanName, new ObjectFactory() {
@Override
public Object getObject() throws BeansException {
return getEarlyBeanReference(beanName, mbd, bean);
}
});
}
// 3
Object exposedObject = bean;
// 4
populateBean(beanName, mbd, instanceWrapper);
// 5
if (exposedObject != null) {
exposedObject = initializeBean(beanName, exposedObject, mbd);
}
if (earlySingletonExposure) {
// 6
Object earlySingletonReference = getSingleton(beanName, false);
if (earlySingletonReference != null) {
// 7
if (exposedObject == bean) {
exposedObject = earlySingletonReference;
}
else if (!this.allowRawInjectionDespiteWrapping && hasDependentBean(beanName)) {
// 8
...
}
}
}
return exposedObject;
}
上面流程中，做了部分删减。但基本创建一个bean，就这几步了。
-
1处，创建bean对象，此时，属性什么的全是null，可以理解为，只是new了，field还没设置
-
2处，添加到第三级缓存；加进去的，只是个factory，只有循环依赖的时候，才会发挥作用
-
3处，把原始bean，存到exposedObject
-
4处，填充属性；循环依赖情况下，A/B循环依赖。假设当前为A，那么此时填充A的属性的时候，会去：
new B；
填充B的field，发现field里有一个是A类型，然后就去getBean("A")，然后走到第三级缓存，拿到了A的ObjectFactory，然后调用ObjectFactory，然后调用AOP的后置处理器类：getEarlyBeanReference，拿到代理后的bean（假设此处切面满足，要创建代理）；
经过上面的步骤后，B里面，field已经填充ok，其中，且填充的field是代理后的A，这里命名为proxy A。
B 继续其他的后续处理。
B处理完成后，被填充到当前的origin A（原始A）的field中
-
5处，对A进行后置处理，此时调用aop后置处理器的，postProcessAfterInitialization；前面我们说了，此时不会再去调用wrapIfNecessary，所以这里直接返回原始A，即 origin A
-
6处，去缓存里获取A，拿到的A，是proxy A
-
7处，我们梳理下：
exposedObject：origin A
bean：原始A
earlySingletonReference： proxy A
此时，下面这个条件是满足的，所以，exposedObject，最终被替换为proxy A：
if (exposedObject == bean) { exposedObject = earlySingletonReference; }
源码#
文章用到的aop循环依赖的demo，自己写一个也可以，很简单：
更新于2020-07-01：回答评论区问题#
问题描述：只使用第一、第二级缓存，是否可行#
这两个问题，本质是一个问题，就是，不用第三级的ObjectFactory行不行，代码直接调用getEarlyBeanReference，拿到bean A的早期引用后，放到第二级缓存，后续bean B去解析依赖时，，注入的不就是最终形态的bean A了吗。
我回答的时候，只是思考了一下，并没有实际测试。下面我们修改下源码，测试一下。
修改源码#
获取单例的地方，修改为只使用第一、第二级缓存#
protected Object getSingleton(String beanName, boolean allowEarlyReference) {
Object singletonObject = this.singletonObjects.get(beanName);
if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {
synchronized (this.singletonObjects) {
singletonObject = this.earlySingletonObjects.get(beanName);
return singletonObject;
}
}
return (singletonObject != NULL_OBJECT ? singletonObject : null);
}
创建bean的地方，修改代码，获取earlyBeanReference后，手动放入第二级缓存#
如下是原始代码：
AbstractAutowireCapableBeanFactory#doCreateBean
// 原始代码长这样
addSingletonFactory(beanName, new ObjectFactory() {
@Override
public Object getObject() throws BeansException {
Object earlyBeanReference = getEarlyBeanReference(beanName, mbd, bean);
if (earlyBeanReference != bean) {
log.info("{} has been wrapped to {}", bean,earlyBeanReference);
}
return earlyBeanReference;
}
});
修改后，长这样：
/**
* 只使用第一、第二级缓存，即，只使用：
* singletonObjects
* earlySingletonObjects
* 不使用第三级：
* singletonFactories
*/
// 1
Object earlyBeanReference = getEarlyBeanReference(beanName, mbd, bean);
// 2
addEarlyReference(beanName, earlyBeanReference);
1处，主要是，获取了早期引用，然后2处，调用我们自己写的一个方法：
DefaultSingletonBeanRegistry#addEarlyReference
/**
* 修改版本，直接添加早期引用
* {@link SmartInstantiationAwareBeanPostProcessor#getEarlyBeanReference(Object, String)}
* 拿到早期引用，然后添加到earlySingletonObjects
* 不使用第三级缓存singletonFactories
* @param beanName
* @param earlyReference 调用getEarlyBeanReference(java.lang.Object, java.lang.String)
*/
protected void addEarlyReference(String beanName, Object earlyReference) {
synchronized (this.singletonObjects) {
if (!this.singletonObjects.containsKey(beanName)) {
// 1
this.earlySingletonObjects.put(beanName,earlyReference);
this.registeredSingletons.add(beanName);
}
}
}
1处代码，把早期引用，存到了二级缓存。
测试该场景下有什么问题#
-
首先，我们继续用前面的例子，我们要getBean(egg)，egg这个bean，依赖了chick，chick又依赖egg。egg最终要生成代理对象。
-
首先，创建egg，获取其早期引用，放到二级缓存。
这里注意，egg虽然生成了代理对象，但是，其属性，chick是null。
-
接下来，开始egg解析依赖的时候，发现依赖了chick，所以，会去创建chick，并创建chick的早期引用
到此为止，早期引用中，已经存放了两个对象，egg（代理对象，但chick属性为null），chick。
-
填充chick的field：egg
此时，chick已经好了。唯一的问题是，egg还没好，egg里面的chick属性，还是null。
-
egg此时的field依赖，chick已经解决了，此时的egg，长这样：
-
此时，egg的属性已经填充了，是不是该去生成代理了
public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
if (bean != null) {
Object cacheKey = getCacheKey(bean.getClass(), beanName);
// 1
if (!this.earlyProxyReferences.contains(cacheKey)) {
return wrapIfNecessary(bean, beanName, cacheKey);
}
}
return bean;
}
不过这里的1处，earlyProxyReferences已经包含了egg这个bean了，所以不会再去生成代理。
-
使用不完整的早期引用，替换了populateDependency完成的egg，出大事了
if (earlySingletonExposure) { Object earlySingletonReference = getSingleton(beanName, false); if (earlySingletonReference != null) { // 1 if (exposedObject == bean) { // 2 exposedObject = earlySingletonReference; } }
此时，1处是满足的，见上图。所以，进入2处，2处的earlySingletonReference，就是我们从二级缓存拿到的早期引用，这个早期引用，一切都好，唯一的问题是，这里的field：chick是null
所以，问题，就是这么个问题，只用二级缓存，此时的chick是null。
更新于2020-07-04：手动调用getEarlyReferencde，放到二级缓存，真的有问题吗#
这次的评论区问题，说实话，我非常感谢，因为，借此问题，我发现，我上面讲的：
更新于2020-07-01的那部分，结论是错误的。
这个问题是什么意思呢？就是这位同学认为：
更新于2020-07-01那部分的试验，最终我的结论是，最终这个Egg对象，是一个代理对象，但是其中的Chick field是null，所以，有问题。
但是，正常情况下，生成的代理对象，其中的field，本来就是null。
我举个例子，是我们实际中的业务代码：
@Service
public class SeatInformationServiceImpl extends ServiceImpl<SeatInformationMapper, SeatInformation> implements ISeatInformationService {
@Autowired
private SeatInformationMapper seatInformationMapper;
@Autowired
private ICenterService centerService;
@Autowired
private RestTemplate restTemplate;
// 1
@Transactional(rollbackFor = Exception.class)
@Override
public void delete(String token,Long seatId) throws BusinessException {
...
}
这个service，就是我从业务代码里copy的，其中，1处，注解了Transactional注解，而事务一般就是基于aop实现的，所以，最终这个service，肯定是会生成代理对象的。
我们看看这个生成的代理对象，长什么样子？
而代理对象，要获取真正的target时，是可以拿到的，如下所示。
ok，所以，我2020-07-01的试验中，过程是没问题的，但结论有问题。
- 错误结论：手动调用getEarlyReference放入二级缓存，去掉三级缓存，这样有问题
- 正确结论：手动调用getEarlyReference放入二级缓存，去掉三级缓存，这样没有问题
而且，关键是，我在这种试验场景下，最终去执行如下代码，切面也是生效了的：
public static void main(String[] args) {
ClassPathXmlApplicationContext ctx = new ClassPathXmlApplicationContext(
"context-namespace-test-aop.xml");
Egg egg = (Egg) ctx.getBean(Egg.class);
egg.incubate();
}
开始孵化
09:45:41.754 [main] DEBUG o.s.b.f.s.DefaultListableBeanFactory - Returning cached instance of singleton bean 'performenceAspect'
孵化完成 --------这部分是切面打印的
既然先行手动调用getEarlyBeanReference这种方案可以解决问题，为什么还要弄三级缓存#
问题就在于，我们每次都去调用getEarlyReference，是可以解决问题，没错。但是，这一步，很多时候都是没有必要的。
在没有循环依赖的时候，这个方法，是从来不会被调用的；也就是说，我们为了解决系统中那百分之1可能出现的循环依赖问题，而让百分之99的bean，创建时，都去走上这么一圈。
效率说不过去吧？
ok，大家要明白，这个方法，SmartInstantiationAwareBeanPostProcessor#getEarlyBeanReference，其存在的意义，就是为了解决aop场景下的循环依赖。
没有这个场景，就不需要这个方案。
大家可以仔细思考下，上面的红圈这里，这个条件，什么时候才会是true？
不错的参考资料#
https://blog.csdn.net/f641385712/article/details/92801300
总结#
如果有问题，欢迎指出；欢迎加群讨论；有帮助的话，请点个赞吧，谢谢
发表评论 取消回复