spring-常见知识点
Posted xuwc
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了spring-常见知识点相关的知识，希望对你有一定的参考价值。
Spring IOC容器是如何解决循环依赖的问题？
- 什么是循环依赖？
先看代码：
public class A {
private B b;
// 省略set/get方法
}
public class B {
private A a;
// 省略set/get方法
}
可以看到A类里有一个属性是B类对象，而B类里也有一个属性是A类对象，则我们可以称A类对象与B类对象之间互相循环依赖。然后我们对把这俩个类纳入到IOC容器中进行管理，现在进行xml配置：
<bean id="a" class="com.A">
<property name="b" ref="b"/>
</bean>
<bean id="b" class="com.B">
<property name="a" ref="a"/>
</bean>
当配置好xml以后，我们创建容器，并且调用getBean方法来获取某个对象，那么会发生什么事情呢？正常逻辑应该是发生了死循环，a对象的创建需要依赖b对象，而b对象的创建同时也需要a对象。这简直就是没办法解决嘛！但是SpringIOC却解决了这个问题，并且你可以正常的获取到相应的对象而不会发生错误。
那么SpringIOC是如何解决循环依赖的问题呢？
原理
SpringIOC解决循环依赖的思路就是依靠缓存，同时还得引出个概念即早期暴露引用。我们知道在IOC容器里bean的初始化的过程分为三个步骤：创建实例、属性注入实例、回调实例实现的接口方法。解决思路就在这：当我们创建实例与属性注入实例这俩个步骤之间的时候，我们引入缓存，将这些已经创建好但是并没有注入属性的实例放到缓存里，而这些放在缓存里但是没有被注入属性的实例对象，就是解决循环依赖的方法，打个比方：A对象的创建需要引用到B对象，而B对象的创建也需要A对象，而此时当B对象创建的时候直接从缓存里引用A对象（虽然不是完全体A对象，毕竟没有赋值处理），当B对象完成创建以后再被A对象引用进去，则A对象也完成了创建。
这就是SpringIOC解决bean直接循环依赖的思路当然有一个小问题，IOC能够解决的只能是属性之间的循环依赖，如果有bean之间的构造器相互依赖则就解决不了只能报错了。
- 我们现在来看看Spring IOC的源码
先看一下下面介绍源码里的缓存的表：
| 源码 | 级别 | 描述 |
|---|---|---|
| singletonObjects | 一级缓存 | 用于存放完全初始化好的 bean，从该缓存中取出的 bean 可以直接使用 |
| earlySingletonObjects | 二级缓存 | 存放原始的 bean 对象（尚未填充属性），用于解决循环依赖 |
| singletonFactories | 三级缓存 | 存放 bean 工厂对象，用于解决循环依赖 |
省略不必要的代码
protected <T> T doGetBean( final String name, final Class<T> requiredType, final Object[] args, boolean typeCheckOnly)
throws BeansException {
Object bean;
// 从缓存中取得bean的实例
Object sharedInstance = getSingleton(beanName);
if (sharedInstance != null && args == null) {
//进行后续处理，如果是正常的普通bean则返回普通的bean，如果是实现了FactoryBean接口的bean则返回的是getObject里的内容
bean = getObjectForBeanInstance(sharedInstance, name, beanName, null);
}
else {
if (!typeCheckOnly) {
markBeanAsCreated(beanName);
}
try {
final RootBeanDefinition mbd = getMergedLocalBeanDefinition(beanName);
checkMergedBeanDefinition(mbd, beanName, args);
// 解决依赖的问题，这个跟我们说的依赖是不一样的.可以忽略
// ......
// 创建单例 bean
if (mbd.isSingleton()) {
sharedInstance = getSingleton(beanName, new ObjectFactory<Object>() {
@Override
public Object getObject() throws BeansException {
try {
return createBean(beanName, mbd, args);
}
catch (BeansException ex) {
// 发生异常，销毁bean
destroySingleton(beanName);
throw ex;
}
}
});
bean = getObjectForBeanInstance(sharedInstance, 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;
}
以上是doGetBean方法里的代码，当然我省略了跟本章无关的代码。
一步步来吧，先进行初始化a对象的操作，然后发现调用的是createBean(String beanName, RootBeanDefinition mbd, Object[] args)方法，而真正起作用的是doCreateBean(final String beanName, final RootBeanDefinition mbd, final Object[] args)方法。而在这个方法里面包含了三个重要的方法createBeanInstance、populateBean、initializeBean，看过之前系列文章的人都知道这三个方法分别代表：创建实例、属性注入、方法回调，这是bean初始化的核心方法。当然下面这段代码是在createBeanInstance和populateBean中间的一段doCreateBean的代码。
boolean earlySingletonExposure = (mbd.isSingleton() && this.allowCircularReferences && isSingletonCurrentlyInCreation(beanName));
if (earlySingletonExposure) {
// ......
addSingletonFactory(beanName, new ObjectFactory<Object>() {
@Override
public Object getObject() throws BeansException {
return getEarlyBeanReference(beanName, mbd, bean);
}
});
}
这段代码在spring源码注释里描述是用来解决循环依赖的问题的。包含了一个匿名内部类ObjectFactory<T>（普通的工厂类返回的是getObject方法返回的对象），用getEarlyBeanReference实现了getObject方法。同时还调用了addSingletonFactory方法。分别来看一下各自方法的实现：
protected Object getEarlyBeanReference(String beanName, RootBeanDefinition mbd, Object bean) {
Object exposedObject = bean;
if (bean != null && !mbd.isSynthetic() && hasInstantiationAwareBeanPostProcessors()) {
for (BeanPostProcessor bp : getBeanPostProcessors()) {
if (bp instanceof SmartInstantiationAwareBeanPostProcessor) {
SmartInstantiationAwareBeanPostProcessor ibp = (SmartInstantiationAwareBeanPostProcessor) bp;
exposedObject = ibp.getEarlyBeanReference(exposedObject, beanName);
if (exposedObject == null) {
return null;
}
}
}
}
return exposedObject;
}
protected void addSingletonFactory(String beanName, ObjectFactory<?> singletonFactory) {
Assert.notNull(singletonFactory, "Singleton factory must not be null");
synchronized (this.singletonObjects) {
if (!this.singletonObjects.containsKey(beanName)) {
this.singletonFactories.put(beanName, singletonFactory);
this.earlySingletonObjects.remove(beanName);
this.registeredSingletons.add(beanName);
}
}
}
可以看到在addSingletonFactory方法中，会将beanName与singletonFactory形成kv关系put进singletonFactories里面。并且将earlySingletonObjects里面的key值为beanName的kv进行移除。
此时a对象的早期暴露引用已经存在了singletonFactories三级缓存里面。此时a对象进行populateBean方法进行属性注入，发现需要依赖b对象，紧接着就是去初始化b对象。继续重复上面的步骤到b对象进行属性注入这一步的时候（此时singletonFactories三级缓存里已经有了a对象的提前暴露引用和b对象的提前暴露引用的工厂对象），发现需要依赖a对象，此时去获取a对象，看代码：
// Eagerly check singleton cache for manually registered singletons.
Object sharedInstance = getSingleton(beanName);
//继续看这个方法
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);
if (singletonObject == null && allowEarlyReference) {
ObjectFactory<?> singletonFactory = 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);
}
先从singletonObjects一级缓存里取，如果没有取到，则从earlySingletonObjects二级缓存里取，如果还是没取到，则从singletonFactories三级缓存里取，取到以后进行getObject方法返回早期暴露对象引用，同时放进earlySingletonObjects二级缓存里，并且三级缓存里进行删除该kv。
那么到此，a对象的早期暴露引用已经被b对象获取到了，并且在singletonFactories三级缓存里已经没有a对象的早期暴露引用的工厂对象了，a对象的早期暴露引用存在了二级缓存earlySingletonObjects里面，当然singletonFactories三级缓存依然有b对象的早期暴露引用的工厂对象。
继续：b对象拿到了a对象的早期暴露引用，进行完属性注入以后，则返回一个b对象了同时调用方法getSingleton(String beanName, ObjectFactory<?> singletonFactory)，看源码：
//我已经删除了很多无关的代码
public Object getSingleton(String beanName, ObjectFactory<?> singletonFactory) {
// ......
synchronized (this.singletonObjects) {
Object singletonObject = this.singletonObjects.get(beanName);
if (singletonObject == null) {
// ......
beforeSingletonCreation(beanName);
boolean newSingleton = false;
// ... ...
//... ...
try {
singletonObject = singletonFactory.getObject();
newSingleton = true;
}
finally {
// ... ...
}
if (newSingleton) {
addSingleton(beanName, singletonObject);
}
}
return (singletonObject != NULL_OBJECT ? singletonObject : null);
}
}
其实就是俩个方法:singletonObject = singletonFactory.getObject();和addSingleton(beanName, singletonObject);至此我们不需要说明第一个了，着重来看一下addSingleton方法。
protected void addSingleton(String beanName, Object singletonObject) {
synchronized (this.singletonObjects) {
this.singletonObjects.put(beanName, (singletonObject != null ? singletonObject : NULL_OBJECT));
this.singletonFactories.remove(beanName);
this.earlySingletonObjects.remove(beanName);
this.registeredSingletons.add(beanName);
}
}
ok，上面源码已经说明了此时singletonObjects一级缓存将要存入b对象，而二级缓存earlySingletonObjects和三级缓存singletonFactories则把相关缓存的对象移除。至此b对象则只存在一级缓存singletonObjects里面了。
当b对象完成了初始化以后，a对象则进行相关属性的注入引入b的对象。完成实例化的同时a对象也会调用一次addSingleton方法，那么a对象完成以后，也就只有一级缓存singletonObjects里面才有a对象。
至此，属性的循环依赖问题则完美的得到解决。
- 文末
感谢 【减肥是生命的主旋律】 的提问和回答
有一个小问题，为什么在解决循环依赖问题的时候，我们会用到三级缓存singletonFactories呢？感觉二级缓存earlySingletonObjects就可以解决问题了呢？
那么答案就在这里：
protected Object getEarlyBeanReference(String beanName, RootBeanDefinition mbd, Object bean) {
Object exposedObject = bean;
if (bean != null && !mbd.isSynthetic() && hasInstantiationAwareBeanPostProcessors()) {
for (BeanPostProcessor bp : getBeanPostProcessors()) {
if (bp instanceof SmartInstantiationAwareBeanPostProcessor) {
SmartInstantiationAwareBeanPostProcessor ibp = (SmartInstantiationAwareBeanPostProcessor) bp;
exposedObject = ibp.getEarlyBeanReference(exposedObject, beanName);
if (exposedObject == null) {
return null;
}
}
}
}
return exposedObject;
}
在将三级缓存放入二级缓存的时候，会判断是否有SmartInstantiationAwareBeanPostProcessor这样的后置处理器，换句话说这里是给用户提供接口扩展的，所以采用了三级缓存。
最近面试当时问到了Spring AOP的实现方式，然后就问到了jdk动态代理为什么使用接口而不是使用继承，当时一时没转过弯来，后来自己回来看了一下原来如此，面试有时就是这样问题不难，但就是可能想不到这个点去回答。
分析
动态代理是使用反射和字节码的技术，在运行期创建指定接口和类的子类以及其实例对象的技术，通过动态代理可以对代码进行增强。java动态代理主要有两种形式：JDK原生的动态代理和CGLIB动态代理。面试中经常被问到jdk动态代理为什么要使用接口，而不是使用继承，接下来我们将生成一个代理类看看为什么要如此。
首先定义一个接口，上面也提到了要使用接口而不是继承，使用接口就是在使用生成代理类提供方法的模板。
然后实现接口，这个是具体的一个实现了，我们就是要增强这个实现类的方法。
InvocationHandler是由代理实例的调用处理程序实现的接口。每当调用代理实例的时候就会调用InvocationHandler的invoke方法。
测试，Proxy提供了创建动态代理类和实例的静态方法，它也是由这些方法创建的所有动态代理类的超类。这里为什么要使传入classLoader主要是运行时动态生成字节码，然后需要classLoader加载这个类，最终通过反射类实例生成代理类的实例。传入接口UserServive是为了给生成代理类提供方法的模板。
接下来，我们生成一个代理类，我们可以看到生成的代理类其实是继承了Proxy，而java是单继承多实现的。
总结
我们都知道java是单继承多实现的，因为生成的代理实例已经需要顶级父类Proxy了，如果你在定义成父类显然是违背了这个原则，所以jdk动态代理一般都是先定义接口，可能你会使用动态代理，但不一定会注意这个问题。
另外，为何调用代理类的方法就会自动进入InvocationHandler 的 invoke（）方法呢？
其实是因为在动态代理类的定义中，构造函数是含参的构造，参数就是我们invocationHandler 实例，而每一个被代理接口的方法都会在代理类中生成一个对应的实现方法，并在实现方法中最终调用invocationHandler 的invoke方法，这就解释了为何执行代理类的方法会自动进入到我们自定义的invocationHandler的invoke方法中，然后在我们的invoke方法中再利用jdk反射的方式去调用真正的被代理类的业务方法，而且还可以在方法的前后去加一些我们自定义的逻辑。比如切面编程AOP等。
以上是关于spring-常见知识点的主要内容，如果未能解决你的问题，请参考以下文章