Spring自定义BeanPostProcessor的时候怎么支持循环依赖

1. 什么是循环依赖?

循环依赖说白了就是在我们的程序中，类A需要依赖于类B，类B又需要依赖于类A，这时候两个类实例就构成了相互依赖，你中有我，我中有你。

@Component
public class A {
    @Autowired
    private B b;
}

@Component
public class B {
    @Autowired
    private A a;
}

2. Spring什么情况下可以帮助我们解决循环依赖？

我们知道在spring中，如果我们的bean是单例的，并且不是通过构造方法进行依赖注入，spring大部分情况下是可以帮助我么解决循环依赖问题的，当然也有
可能解决不了。

(具体参考：这个Spring循环依赖的坑，90%以上的人都不知道)。

3. Prototype类型为什么解决不了循环依赖？

在spring的AbstractBeanFactory中的doGetBean方法中有一个判断，如果是Prototype类型并且该实例正在创建中，直接抛出异常。

// Fail if we're already creating this bean instance:
// We're assumably within a circular reference.
if (isPrototypeCurrentlyInCreation(beanName)) {
	throw new BeanCurrentlyInCreationException(beanName);
}

/**
 * Return whether the specified prototype bean is currently in creation
 * (within the current thread).
 * @param beanName the name of the bean
 */
protected boolean isPrototypeCurrentlyInCreation(String beanName) {
	Object curVal = this.prototypesCurrentlyInCreation.get();
	return (curVal != null &&
			(curVal.equals(beanName) || (curVal instanceof Set && ((Set<?>) curVal).contains(beanName))));
}

4. 构造方法注入为什么解决不了循环依赖？

思考一个逻辑，spring创建A的时候，发现A的构造函数中需要注入B，然后spring去创建B，这时候发现，B的构造函数中又需要注入A，可是这时候A还在等待B创
建成功后进行注入，A还没创建好呢，这时候就构成了死等待，A等待B创建，B等待A创建，最终的结果就是都进行不下去了，spring检测到后就直接给我们抛异常
了。

5. 自定义BeanPostProcessor

 这时候如果我们想要自定义BeanPostProcessor，并且可能需要通过代理原始类，扩展我们的功能，那么这时候，如果我们像下面这样写：

@Component
public class TestBeanPostProcessor implements BeanPostProcessor,MethodInterceptor{

    @Override
    public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
        if(bean instanceof A){
            System.out.println("对A创建代理");
            Enhancer enhancer = new Enhancer();
            enhancer.setSuperclass(A.class);
            enhancer.setCallback(this);
            return enhancer.create();
        }
        return bean;
    }

    @Override
    public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
        return null;
    }

    @Override
    public Object intercept(Object o, Method method, Object[] objects, MethodProxy methodProxy) throws Throwable {
        System.out.println("代理拦截" + method.getName());
        Object object = methodProxy.invokeSuper(o, objects);
        return object;
    }
}

这样你只能收获到无情的报错：

org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'a': Bean with name 
'a' has been injected into other beans [b] 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.

这段错误大概的意思就是，我们已经注入的bean后来被修改了，导致注入的bean和最终实际的bean不是一个，所以报错了，当然，你也可以按照提示，通过
allowEagerInit这个属性进行配置，允许这种不一致的情况发生，只是我不推荐这种做法，很有可能带来莫名其妙的错误。

---

下面我们来改写一下实现方式

@Component
public class TestBeanPostProcessor implements SmartInstantiationAwareBeanPostProcessor,MethodInterceptor{

    @Override
    public Object getEarlyBeanReference(Object bean, String beanName) throws BeansException {
        if(bean instanceof A){
            System.out.println("对A创建代理");
            Enhancer enhancer = new Enhancer();
            enhancer.setSuperclass(A.class);
            enhancer.setCallback(this);
            return enhancer.create();
        }
        return bean;
    }

    @Override
    public Object intercept(Object o, Method method, Object[] objects, MethodProxy methodProxy) throws Throwable {
        System.out.println("代理拦截" + method.getName());
        Object object = methodProxy.invokeSuper(o, objects);
        return object;
    }
}

你会发现这种方式成功启动了，并且在B中注入的A实例就是我们代理后的对象。

6. 为什么第二种方式能成功呢？

注意一下这两种实现方式，第一种是实现了BeanPostProcessor，并对postProcessBeforeInitialization方法进行了重写；第二种是实现了
SmartInstantiationAwareBeanPostProcessor，并对getEarlyBeanReference进行了重写。要想明白原因，我们需要知道spring在什么时候回触发
BeanPostProcessor的调用。

之所以第二种能够成功，是因为Spring中提前暴露bean时的一段处理逻辑，这段逻辑位于AbstractAutowireCapableBeanFactory中的doCreateBean方法中。

protected Object doCreateBean(final String beanName, final RootBeanDefinition mbd, final @Nullable Object[] args)
			throws BeanCreationException {
		
		...
		
		// 如果允许循环依赖，并且当前bean正在创建中，那么先放入singletonFactories,singletonFactories属于是一个缓存，spring获取bean
		// bean实例的时候，会先从singletonObjects获取，获取不到再从earlySingletonObjects获取，如果还没有，就会从singletonFactories
		// 进行获取，因为提前暴露的对象我们已经add到singletonFactories中了，那么从singletonFactories获取对象时就会调用
		// () -> getEarlyBeanReference(beanName, mbd, bean),从而就可以提前获取到代理对象了
		boolean earlySingletonExposure = (mbd.isSingleton() && this.allowCircularReferences &&
				isSingletonCurrentlyInCreation(beanName));
		if (earlySingletonExposure) {
			if (logger.isTraceEnabled()) {
				logger.trace("Eagerly caching bean '" + beanName +
						"' to allow for resolving potential circular references");
			}
			// 这里是重点，里面封装了能够正确注入代理的逻辑
			// 重点就是getEarlyBeanReference(beanName, mbd, bean)方法
			addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));
		}

		// Initialize the bean instance.
		Object exposedObject = bean;
		try {
			// 在这个方法里面，会执行AutowiredAnnotationBeanPostProcessor的postProcessProperties，从而进行了@Autowird属性的注入
			populateBean(beanName, mbd, instanceWrapper);
			// 在这个方法里面，会触发第一种BeanPostProcessor的postProcessBeforeInitialization方法的调用
			exposedObject = initializeBean(beanName, exposedObject, mbd);
		}catch (Throwable 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<>(dependentBeans.length);
					for (String dependentBean : dependentBeans) {
						if (!removeSingletonIfCreatedForTypeCheckOnly(dependentBean)) {
							actualDependentBeans.add(dependentBean);
						}
					}
					// 这里就是我们上面报错的地方，因为检测出来了依赖的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.");
					}
				}
			}
		}

		...
		
		return exposedObject;
	}

	protected Object getEarlyBeanReference(String beanName, RootBeanDefinition mbd, Object bean) {
		Object exposedObject = bean;
		if (!mbd.isSynthetic() && hasInstantiationAwareBeanPostProcessors()) {
			for (BeanPostProcessor bp : getBeanPostProcessors()) {
			// 从这里就可以发现，对于提前暴露的bean引用，这里会调用SmartInstantiationAwareBeanPostProcessor的
			//getEarlyBeanReference的方法，并将该方法返回的对象作为实际暴露的对象，那么就不难理解为什么我们重写了这个方法后，就可以将我们代
			//理后的对象正确注入了
				if (bp instanceof SmartInstantiationAwareBeanPostProcessor) {
					SmartInstantiationAwareBeanPostProcessor ibp = (SmartInstantiationAwareBeanPostProcessor) bp;
					exposedObject = ibp.getEarlyBeanReference(exposedObject, beanName);
				}
			}
		}
		return exposedObject;
	}

现在我们来看一看第一种方式为什么不能成功。通过上面代码的标注，我么知道了第一种方式postProcessBeforeInitialization方法的调用是在initializeBean中，而
我们的@Autowird注解的注入是在initializeBean的前一个方法populateBean中，也就是B中都已经注入了A提前暴露出来的对象后，我们的
postProcessBeforeInitialization方法又将A对象实例给改成了我们的代理对象，从而导致了注入的A的bean对象和最终的A的bean对象不是一个。