听说 Spring Bean 的创建还有一条捷径？-Toy模板网

这篇具有很好参考价值的文章主要介绍了听说 Spring Bean 的创建还有一条捷径？。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

在 Spring Bean 的创建方法中，有如下一段代码：

AbstractAutowireCapableBeanFactory#createBean：

@Override
protected Object createBean(String beanName, RootBeanDefinition mbd, @Nullable Object[] args)
		throws BeanCreationException {
	//...
	try {
		// Give BeanPostProcessors a chance to return a proxy instead of the target bean instance.
		Object bean = resolveBeforeInstantiation(beanName, mbdToUse);
		if (bean != null) {
			return bean;
		}
	}
	try {
		Object beanInstance = doCreateBean(beanName, mbdToUse, args);
		return beanInstance;
	}
	//...
}

我们平时说的 Bean 的创建逻辑都是指 doCreateBean 方法中的逻辑，在松哥前面几篇文章中，凡是涉及到 Bean 的创建流程的，我说的也都是 doCreateBean 方法的流程。

但是小伙伴们注意，在 doCreateBean 方法执行之前，其实还有一个 resolveBeforeInstantiation 方法会先执行，而这个方法可能就直接产生一个 Bean 了！如果这个方法直接产生一个 Bean 了，那么 doCreateBean 方法中的逻辑就不会生效了。

那么 resolveBeforeInstantiation 方法存在的意义是什么呢？其实大家从该方法的注释上大概也能看出一些端倪出来了：

给 BeanPostProcessor 一个机会去创建一个代理对象，用这个代理对象来代替目标 Bean。

1. resolveBeforeInstantiation

看下面的源码小伙伴们一定要先搞清楚两个比较相似的单词，否则看到后面就乱了：

instantiation：实例化，从 Class 到 Bean 就是实例化。
initialization：初始化，给 Bean 做各种配置就是初始化。

搞明白这两个单词，我们来看源码。

首先我先来和小伙伴们稍微梳理一下 resolveBeforeInstantiation 方法。

AbstractAutowireCapableBeanFactory#resolveBeforeInstantiation：

@Nullable
protected Object resolveBeforeInstantiation(String beanName, RootBeanDefinition mbd) {
	Object bean = null;
	if (!Boolean.FALSE.equals(mbd.beforeInstantiationResolved)) {
		// Make sure bean class is actually resolved at this point.
		if (!mbd.isSynthetic() && hasInstantiationAwareBeanPostProcessors()) {
			Class<?> targetType = determineTargetType(beanName, mbd);
			if (targetType != null) {
				bean = applyBeanPostProcessorsBeforeInstantiation(targetType, beanName);
				if (bean != null) {
					bean = applyBeanPostProcessorsAfterInitialization(bean, beanName);
				}
			}
		}
		mbd.beforeInstantiationResolved = (bean != null);
	}
	return bean;
}

小伙伴们看一下，这里有一个判断条件，mbd.isSynthetic 是判断是否是一个合成 Bean，这种一般都是 Spring 定义的，我们自定义的 Bean 一般都不属于这一类，然后后面的 hasInstantiationAwareBeanPostProcessors 方法则是判断当前是否存在 InstantiationAwareBeanPostProcessor 类型的后置处理器，如果存在，则进入到 if 分支中。

如果我们想要在 resolveBeforeInstantiation 方法中就完成 Bean 的处理，那么就需要自己提供一个 InstantiationAwareBeanPostProcessor 类型的后置处理器。

接下来会调用两个方法：

applyBeanPostProcessorsBeforeInstantiation：从名字可以看出来，这个是在实例化之前触发的方法，所以这个方法的参数还是 Class，因为还未实例化。
applyBeanPostProcessorsAfterInitialization：从名字可以看出来，这个是在初始化之后出发的方法，所以这个方法的参数是 Bean，因为此时已经完成了初始化了。

1.1 applyBeanPostProcessorsBeforeInstantiation

@Nullable
protected Object applyBeanPostProcessorsBeforeInstantiation(Class<?> beanClass, String beanName) {
	for (InstantiationAwareBeanPostProcessor bp : getBeanPostProcessorCache().instantiationAware) {
		Object result = bp.postProcessBeforeInstantiation(beanClass, beanName);
		if (result != null) {
			return result;
		}
	}
	return null;
}

这个地方就很简单了，就是执行 InstantiationAwareBeanPostProcessor 类型的后置处理器的 postProcessBeforeInstantiation 方法。

1.2 applyBeanPostProcessorsAfterInitialization

@Override
public Object applyBeanPostProcessorsAfterInitialization(Object existingBean, String beanName)
		throws BeansException {
	Object result = existingBean;
	for (BeanPostProcessor processor : getBeanPostProcessors()) {
		Object current = processor.postProcessAfterInitialization(result, beanName);
		if (current == null) {
			return result;
		}
		result = current;
	}
	return result;
}

这个是执行 BeanPostProcessor 的 postProcessAfterInitialization 方法。

所以这块的源码其实并不难，道理很简单。

1.3 案例

松哥写一个简单的案例小伙伴们来看下。

假设我有一个 BookService，如下：

public class BookService {

    public void hello() {
        System.out.println("hello javaboy");
    }
}

然后我再创建一个 InstantiationAwareBeanPostProcessor 类型的后置处理器，并且重写前面提到的 postProcessBeforeInstantiation 和 postProcessAfterInitialization 方法：

public class MyInstantiationAwareBeanPostProcessor implements InstantiationAwareBeanPostProcessor {
    @Override
    public Object postProcessBeforeInstantiation(Class<?> beanClass, String beanName) throws BeansException {
        if (beanClass == BookService.class) {
            Enhancer enhancer = new Enhancer();
            enhancer.setSuperclass(beanClass);
            enhancer.setCallback((MethodInterceptor) (obj, method, args, proxy) -> {
                String name = method.getName();
                System.out.println(name + " 方法开始执行了...");
                Object invoke = proxy.invokeSuper(obj, args);
                System.out.println(name + " 方法执行结束了...");
                return invoke;
            });
            BookService bookService = (BookService) enhancer.create();
            return bookService;
        }
        return InstantiationAwareBeanPostProcessor.super.postProcessBeforeInstantiation(beanClass, beanName);
    }

    @Override
    public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
        System.out.println("bean.getClass() ========= " + bean.getClass());
        return InstantiationAwareBeanPostProcessor.super.postProcessAfterInitialization(bean, beanName);
    }
}

在 postProcessBeforeInstantiation 方法中，如果要创建的 Bean 是 BookService，则这里通过 Enhancer 来创建一个 CGLIB 的代理对象，如果是其他的 Bean 的创建，则调用父类方法即可。这样重写之后，就会导致在 1.1 小节中，获取到的 result 就是一个代理的 BookService 对象。

在 postProcessAfterInitialization 方法中，我未做任何额外处理，就是把拿到的 Bean 打印了一下，此时我们拿到手的 Bean 其实就是前面 postProcessBeforeInstantiation 方法生成的代理对象，然后这里调用父类方法去返回，实际上就是把参数 Bean 原封不动返回。

最后将这两个 Bean 注册到 Spring 容器中：

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">
    <bean class="org.javaboy.bean.aop2.BookService" id="bookService"/>
    <bean class="org.javaboy.bean.aop2.MyInstantiationAwareBeanPostProcessor"
          id="myInstantiationAwareBeanPostProcessor"/>
</beans>

然后初始化 Spring 容器：

ClassPathXmlApplicationContext ctx = new ClassPathXmlApplicationContext("aop2.xml");
BookService bs = ctx.getBean(BookService.class);
System.out.println("bs.getClass() = " + bs.getClass());
bs.hello();

最终执行结果如下：

听说 Spring Bean 的创建还有一条捷径？,spring,python,前端

可以看到，最终拿到的 BookService 就是一个代理对象，从源码层面来讲，这个代理对象在 resolveBeforeInstantiation 方法中就生成了，后续的 doCreateBean 方法实际上并未执行。

这就是 resolveBeforeInstantiation 方法的作用，实际上就是给 BeanPostProcessor 一个机会去创建一个代理对象，用这个代理对象来代替目标 Bean。

2. 源码实践

松哥为什么会关注到这个方法呢？

如果有小伙伴研究过 Spring AOP 源码，就会发现这个方法在处理 Spring AOP 的时候，有一个用武之地。

当我们在 Spring AOP 中，往往通过如下代码来定义切面：

@Component
@Aspect
@EnableAspectJAutoProxy
public class LogAspect {
    //...
}

这个类上面有一个 @Aspect 注解，那么问题来了，Spring 是如何识别出这是一个切面而非普通的 Bean 的？

答案就是在 1.1 小节中的 applyBeanPostProcessorsBeforeInstantiation 方法中，这个方法会遍历所有 InstantiationAwareBeanPostProcessor 类型的后置处理器，InstantiationAwareBeanPostProcessor 有一个子类是 AnnotationAwareAspectJAutoProxyCreator，在这个处理器中，识别出来了 LogAspect 是一个切面。

具体识别方法如下：

首先调用 AnnotationAwareAspectJAutoProxyCreator 的 postProcessBeforeInstantiation 方法（实际上是 AnnotationAwareAspectJAutoProxyCreator 的父类 AbstractAutoProxyCreator 中的方法）：

@Override
public Object postProcessBeforeInstantiation(Class<?> beanClass, String beanName) {
	Object cacheKey = getCacheKey(beanClass, beanName);
	if (!StringUtils.hasLength(beanName) || !this.targetSourcedBeans.contains(beanName)) {
		if (isInfrastructureClass(beanClass) || shouldSkip(beanClass, beanName)) {
			this.advisedBeans.put(cacheKey, Boolean.FALSE);
			return null;
		}
	}
	//...
}

从这个地方开始，分成了两条线：

如果是一个切面 Bean 的话，则执行第一个方法 isInfrastructureClass 就可以返回 true 了。
如果是一个普通 Bean 的话，则第一个方法会返回 false，此时就会执行第二个方法 shouldSkip（虽然该方法也会返回 false），但是该方法有一些其他的价值在里边。

2.1 切面 Bean

我们先来看 isInfrastructureClass 方法，先来看切面 Bean 是怎么处理的。

这个方法我摘了一部分出来，我们重点关注 isInfrastructureClass 方法，这个方法用来判断当前类是否是一个 Aspect：

@Override
protected boolean isInfrastructureClass(Class<?> beanClass) {
	return (super.isInfrastructureClass(beanClass) ||
			(this.aspectJAdvisorFactory != null && this.aspectJAdvisorFactory.isAspect(beanClass)));
}

这里的判断主要是两方面：

调用父类的方法去判断当前类是否和 AOP 相关：

protected boolean isInfrastructureClass(Class<?> beanClass) {
	boolean retVal = Advice.class.isAssignableFrom(beanClass) ||
			Pointcut.class.isAssignableFrom(beanClass) ||
			Advisor.class.isAssignableFrom(beanClass) ||
			AopInfrastructureBean.class.isAssignableFrom(beanClass);
	return retVal;
}

这个就不用我解释了，这些都是我们在 AOP 中的老熟人了。

调用 aspectJAdvisorFactory.isAspect 方法去判断当前类是否包含 @Aspect 注解：

AbstractAspectJAdvisorFactory#isAspect

@Override
public boolean isAspect(Class<?> clazz) {
	return (hasAspectAnnotation(clazz) && !compiledByAjc(clazz));
}
private boolean hasAspectAnnotation(Class<?> clazz) {
	return (AnnotationUtils.findAnnotation(clazz, Aspect.class) != null);
}