写在前面的话
相关背景及资源:
曹工说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,自己写一个也可以,很简单:
不错的参考资料
https://blog.csdn.net/f641385712/article/details/92801300
总结
如果有问题,欢迎指出;欢迎加群讨论;有帮助的话,请点个赞吧,谢谢
来源:oschina
链接:https://my.oschina.net/u/4340310/blog/4332450