SpringBoot源码解析01----@Bean方法的套娃调用原理

SpringBoot源码解析 第一篇----@Bean方法的套娃调用原理

前言：

​ 本篇攻略是我技术文章系列的处女作，也作为一个记录的开始。

​ 以前也阅读过许多源码，但最终印证了好记性不如烂笔头的道理，所以还是要多做笔记呀。

​ 本系列不会分析那些刻板的执行流程，网上多的是。我会根据开发中经常遇到的***知其然而不知其所以然***的问题从源码入手分析来解惑。

​ 本人目前新手水平，如果分析的有问题，希望读者大佬们能及时指点纠错。

先举个栗子

@Configuration
public class TestConfiguration {

@Bean
public CommonDependency commonDependency() {
return new CommonDependency();
}

@Bean
public OneServer oneServer() {
return new OneServer(commonDependency());
}

@Bean
public AnotherServer anotherServer() {
return new AnotherServer(commonDependency());
}
}

​ 上文代码作为SpringBoot中的配置类，大家都不陌生。其中后两个bean都依赖于commonDependency实例，那么问题来了，后两个bean都调用了第一个bean的new的方法，那么最后容器中到底有几个commonDependency实例呢？ 大部分小伙伴们都会说就一个，因为Spring Bean默认的scope是单例的，但明明又调用了new方法，总有点说不通的地方。

​ 那么SpringBoot内部是如何实现这种写法而不重复创建实例呢？这里就需要小伙伴们对Spring Bean的加载以及实例化机制、BeanFactoryPostProcessor后置处理器的机制、CGLIB动态代理技术有稍微一些了解才可，本文中不会详细讲解这些内容。

​ 在从发现问题到研究明白的过程中，我会以断点调试的思路，一步步地引导并讲解源码，希望小伙伴们能静下心来阅读，最好打开IDE边看源码边阅读，理解更深哦。

​ 首先，给return new CommonDependency()这句话中打上断点，发现程序在此处只执行了一次，说明其他两个bean虽然调用其方法，但并没有走这。这是一条相当有用的信息，相信大家已经明白了，这个方法已经被代理了，在执行目标行前已经被拦截掉并返回。

// 调用栈看着心烦的直接忽略 不影响阅读文章

commonDependency:15, TestConfiguration (com.example.demo)
CGLIB$commonDependency$2:-1, TestConfiguration$$EnhancerBySpringCGLIB$$670cda94 (com.example.demo)
invoke:-1, TestConfiguration$$EnhancerBySpringCGLIB$$670cda94$$FastClassBySpringCGLIB$$eeddf75b (com.example.demo)
invokeSuper:244, MethodProxy (org.springframework.cglib.proxy)
intercept:363, ConfigurationClassEnhancer$BeanMethodInterceptor (org.springframework.context.annotation)
commonDependency:-1, TestConfiguration$$EnhancerBySpringCGLIB$$670cda94 (com.example.demo)
...

​ 从调用栈上我们也可以看出，TestConfiguration类已经变成了

TestConfiguration$$EnhancerBySpringCGLIB$$670cda94

使用CGLIB生成了子类。至于为什么使用CGLIB而不用JDK动态代理、代理的时机等这种支线任务我们先抛开不看，我们先做主线。如果不明白为啥要用代理，请先移步设计模式学习。

​ 这里要涉及到CGLIB的概念，我只简单对照JDK的Proxy代理说一下，如果需要深入了解，可以研究这位大佬的攻略：

https://www.iteye.com/blogs/subjects/cglib-in-action

​ 我们想要知道代理中究竟做了什么神奇逻辑，那么我们首先就要找到这个代理类的增强方法（如果是Proxy代理的话，增强逻辑都是写在InvocationHandler里的， GFLIB这里是MethodInterceptor）,调用栈中正好呼应上了这个类，ConfigurationClassEnhancer$BeanMethodInterceptor，即ConfigurationClassEnhancer中的一个内部类，那么源码分析从这里开始（注意保持清醒）。

​ ConfigurationClassEnhancer位于Spring context.annotation包，中文意思是*注解配置类的增强器。它是本攻略中的一个核心的选手。根据源码注释，

* Enhances {@link Configuration} classes by generating a CGLIB subclass which
* interacts with the Spring container to respect bean scoping semantics for
* {@code @Bean} methods. Each such {@code @Bean} method will be overridden in
* the generated subclass, only delegating to the actual {@code @Bean} method
* implementation if the container actually requests the construction of a new
* instance. Otherwise, a call to such an {@code @Bean} method serves as a
* reference back to the container, obtaining the corresponding bean by name.

// 这段话大致意思就是说 这个选手是用来通过CGLIB生成子类来增强那些@Configuration配置类，
// 对各种作用域的@Bean返回的实例的处理；也就是重写这些带@Bean的方法，
// 根据每个bean的作用域去判断调用是该产生新实例还是返回旧实例的引用，拿bean名字判断。

大概明白了这个类做的事就是筛选拦截的配置类对象及方法、组织增强行为、以及进行增强生成代理。有跟着看源码的小伙伴会问了，这个类也不受IoC容器管理有啥用，这个问题放到后面解释，角色要轮流登场。

在这个类中，规定了三种增强策略(CGLIB的回调)

private static final Callback[] CALLBACKS = new Callback[] {
// 对@Bean方法的增强
new BeanMethodInterceptor(),
// 如果实现了BeanFactoryAware， 对setBeanFactory()方法增强
new BeanFactoryAwareMethodInterceptor(),
// 原封不动
NoOp.INSTANCE
};

Spring怎样确定配置类中的哪些方法需要增强，就用到了CGLIB中的回调过滤CallbackFilter。当对每个方法进行增强前，就会调用

// 内部类
private static class ConditionalCallbackFilter implements CallbackFilter {

private final Callback[] callbacks;

private final Class<?>[] callbackTypes;

// 构造时 需放入所有增强策略
public ConditionalCallbackFilter(Callback[] callbacks) {
this.callbacks = callbacks;
this.callbackTypes = new Class<?>[callbacks.length];
for (int i = 0; i < callbacks.length; i++) {
this.callbackTypes[i] = callbacks[i].getClass();
}
}

// 当每个方法被重写时，都需调用该方法判断以哪种增强策略进行重写
@Override
public int accept(Method method) {
for (int i = 0; i < this.callbacks.length; i++) {
Callback callback = this.callbacks[i];
if (!(callback instanceof ConditionalCallback) || ((ConditionalCallback) callback).isMatch(method)) {
return i;
}
}
throw new IllegalStateException("No callback available for method " + method.getName());
}

...
}

其中ConditionalCallback接口是对所有增强(回调)策略的实现类的统一要求，要求每个增强逻辑都提供判断【某方法是否适用此策略】(这种方式很常见，源码里很多地方都有)

// 内部接口
private interface ConditionalCallback extends Callback {
boolean isMatch(Method candidateMethod);
}

因为我们要研究@Bean方法 所以只需要看BeanMethodInterceptor策略实现

// 内部类
private static class BeanMethodInterceptor
// 实现了MethodInterceptor 即要实现增强逻辑
// 实现了ConditionalCallback 即要提供能否适用的匹配方法
implements MethodInterceptor, ConditionalCallback {

@Override
@Nullable
// 增强逻辑 类比JDK动态代理中InvocationHandler 都差不多的
// enhancedConfigInstance CGLib动态生成的代理类实例
// beanMethod 被调用的方法引用
// beanMethodArgs 这个方法的参数列表
// cglibMethodProxy 代理方法引用
public Object intercept(Object enhancedConfigInstance,
Method beanMethod,
Object[] beanMethodArgs,
MethodProxy cglibMethodProxy) throws Throwable {

// 获取到装他的IoC容器
ConfigurableBeanFactory beanFactory = getBeanFactory(enhancedConfigInstance);

// 获取依赖的bean的名字
// 这个BeanAnnotationHelper就是一个保存beanMethod和beanName的一个缓存映射 方便寻找依赖关系
String beanName = BeanAnnotationHelper.determineBeanNameFor(beanMethod);

// 这里判断 原@Bean方法所依赖的其他实例是否为代理依赖(涉及到其他问题，与本文无相干)
if (BeanAnnotationHelper.isScopedProxy(beanMethod)) {
String scopedBeanName = ScopedProxyCreator.getTargetBeanName(beanName);
if (beanFactory.isCurrentlyInCreation(scopedBeanName)) {
beanName = scopedBeanName;
}
}

// PS:这里我没太看懂(这里的调用栈太深了) 当bean工厂中已经存在了该FactoryBean
// 当不是代理依赖的时候，就使用JDK代理或者CGLIB代理产生一个新的bean返回 ？？？
if (factoryContainsBean(beanFactory, BeanFactory.FACTORY_BEAN_PREFIX + beanName) &&
factoryContainsBean(beanFactory, beanName)) {
Object factoryBean = beanFactory.getBean(BeanFactory.FACTORY_BEAN_PREFIX 										+ beanName);
if (factoryBean instanceof ScopedProxyFactoryBean) {
}
else {
return enhanceFactoryBean(factoryBean, beanMethod.getReturnType(), 								beanFactory, beanName);
}
}

// 判断是否为当前工厂调用的方法
// 这里不太好理解 当依赖@Bean方法在上 被依赖@Bean方法在下面时，比如oneServer()在前，		   		  // commonDependency实例还没被创建，那么此时这里为true，会调用代理方法的父类方法(即原方法)
// 原方法会去调用commonDependency() 此方法依旧带有@Bean注解又被拦截，再次走到这里时，
// 这里的判断就为false 因为当前工厂调用的方法 仍然是oneServer()
// 鱿鱼丝会进入到resolveBeanReference方法中 后面会分析方法内部
if (isCurrentlyInvokedFactoryMethod(beanMethod)) {
...
return cglibMethodProxy.invokeSuper(enhancedConfigInstance, beanMethodArgs);
}
return resolveBeanReference(beanMethod, beanMethodArgs, beanFactory, beanName);
}

}

在上方的intercept方法中，读了半天发现又是套娃。那么我们就要看看这个resolveBeanReference到底做了什么。

private Object resolveBeanReference(Method beanMethod,
Object[] beanMethodArgs,
ConfigurableBeanFactory beanFactory,
String beanName) {
// 4个参数 分别是 调用的方法 方法参数列表 容器 以及这个bean的name

// 这里要判断目前要获取的这个bean 的创建状态 是否正在创建
boolean alreadyInCreation = beanFactory.isCurrentlyInCreation(beanName);
try {
// 官方注解的意思是 在某些情况下 这个bean可能会在用户直接或间接的行为下标记为已经创建
// 为了保证不出错 暂时性把这个状态改成false 处理完成后再修改回去
if (alreadyInCreation) {
beanFactory.setCurrentlyInCreation(beanName, false);
}
// 这里判断有没有参数要传
boolean useArgs = !ObjectUtils.isEmpty(beanMethodArgs);
if (useArgs && beanFactory.isSingleton(beanName)) {
for (Object arg : beanMethodArgs) {
if (arg == null) {
useArgs = false;
break;
}
}
}
// ※ 这里终于到重点了 增强逻辑会从IoC容器中尝试着拿这个bean (有可能没有)
Object beanInstance = (useArgs ? beanFactory.getBean(beanName, beanMethodArgs) :
beanFactory.getBean(beanName));
// 如果拿出来的bean 不是返回的类型
if (!ClassUtils.isAssignableValue(beanMethod.getReturnType(), beanInstance)) {
// 如果容器中不存在此Name的bean 会返回一个NullBean  这里这么调用没问题
if (beanInstance.equals(null)) {
...
beanInstance = null;
}
else {
// 如果类型都对不上 直接报错...
...
try {
BeanDefinition beanDefinition = 																beanFactory.getMergedBeanDefinition(beanName);
msg += " Overriding bean of same name declared in: " + 										beanDefinition.getResourceDescription();
}
catch (NoSuchBeanDefinitionException ex) {
// Ignore - simply no detailed message then.
}
throw new IllegalStateException(msg);
}
}

// 走到这里 要么是已经拿出了合适的bean 要么是没有
// 这里是使用了实例化策略中记录的当前工厂调用的方法 内部维护的是一个ThreadLocal
// 从之前的缓存映射中找到这个方法的beanName 然后把bean的依赖关系注册到容器中

Method currentlyInvoked = 																	SimpleInstantiationStrategy.getCurrentlyInvokedFactoryMethod();
// currentlyInvoked代表了工厂调用配置类的根方法
if (currentlyInvoked != null) {
String outerBeanName = 																	BeanAnnotationHelper.determineBeanNameFor(currentlyInvoked);
beanFactory.registerDependentBean(beanName, outerBeanName);
}
return beanInstance;
}
finally {
// 最后再还原修改过的bean创建状态
if (alreadyInCreation) {
beanFactory.setCurrentlyInCreation(beanName, true);
}
}
}

其实@Bean方法调用@Bean方法时 会通过增强 先从IoC容器中获取，当获取不到时才会创建并加载为FactoryBean。

​ 而什么时候配置类对象就变成了代理子类了呢？这个增强器是什么时候被SpringBoot所用的呢？这时候就需要配合其他支线任务去解释了。（后面的部分需要两个类的代码穿插讲解）

​ ConfigurationClassPostProcessor 配置类后置处理器 一个Spring中非常强大的后置处理器登场(功能太多，注解取代XML文件的操作大多都在这里，本文之说相干的部分)。在这里bean工厂的一些概念就不进行讲解了，不懂的小伙伴们需要多了解一下。它的作用就是在bean工厂启动收集完所有BeanDefinition后，优先找到

直接上代码

// 在它的后置处理钩子方法中 做的就是把所有选中的配置类进行CGLIB增强

// 这里顺便说一下 为什么要用CGLIB而不是JDK代理  JDK代理的前提是必须实现有接口且约束规范
// 而在配置类中所配置的内容种类繁多 并无规范可言 而且可以嵌套 所以CGLIB的优势就凸显了
@Override
public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) {
int factoryId = System.identityHashCode(beanFactory);
if (this.factoriesPostProcessed.contains(factoryId)) {
throw new IllegalStateException(
"postProcessBeanFactory already called on this post-processor against " + beanFactory);
}
this.factoriesPostProcessed.add(factoryId);
if (!this.registriesPostProcessed.contains(factoryId)) {
// 这里做的就是对每个beanDefinition进行标记是否为配置类
// 但这个if不会被执行，此操作在postProcessBeanDefinitionRegistry方法中已经完成
processConfigBeanDefinitions((BeanDefinitionRegistry) beanFactory);
}

// 主要我们需要研究此方法
enhanceConfigurationClasses(beanFactory);
beanFactory.addBeanPostProcessor(new ImportAwareBeanPostProcessor(beanFactory));
}

继续套娃，阅读enhanceConfigurationClasses方法()

// 从对带有标记的beanDefinition，使用ConfigurationClassEnhancer进行代理增强
public void enhanceConfigurationClasses(ConfigurableListableBeanFactory beanFactory) {
Map<String, AbstractBeanDefinition> configBeanDefs = new LinkedHashMap<>();
for (String beanName : beanFactory.getBeanDefinitionNames()) {
BeanDefinition beanDef = beanFactory.getBeanDefinition(beanName);
Object configClassAttr = beanDef.getAttribute(ConfigurationClassUtils.
CONFIGURATION_CLASS_ATTRIBUTE);
...

// 这里只代理Full类型的 也就是@Configuration标注的类 而且没有关掉注解proxyBeanMethod开			  // 关的
// 这里又涉及到众多要素 我就不解释Full Site Null 类型了 源码在ConfigurationClassUtils
if (ConfigurationClassUtils.CONFIGURATION_CLASS_FULL.equals(configClassAttr)) 			  {
...
// 把符合的beanDefinition放入map 后面操作
configBeanDefs.put(beanName, (AbstractBeanDefinition) beanDef);
}
}
// 没配置类就不增强了
if (configBeanDefs.isEmpty()) {
return;
}

// ※ 这里就创建了上面讲到了增强器
ConfigurationClassEnhancer enhancer = new ConfigurationClassEnhancer();
// 遍历刚才收集到的配置类beanDefinition
for (Map.Entry<String, AbstractBeanDefinition> entry : configBeanDefs.entrySet()) 		  {
AbstractBeanDefinition beanDef = entry.getValue();
beanDef.setAttribute(AutoProxyUtils.PRESERVE_TARGET_CLASS_ATTRIBUTE, 						Boolean.TRUE);
Class<?> configClass = beanDef.getBeanClass();
// 这里调用了增强器的代理方法
Class<?> enhancedClass = enhancer.enhance(configClass, this.beanClassLoader);
if (configClass != enhancedClass) {
...
// 把代理过的Class类型替换到原先的BeanDefinition中
beanDef.setBeanClass(enhancedClass);
}
}
}

我们发现是BeanFactory后置处理时，创建了增强器并在bean工厂中搜索到配置类的bean信息，对其骨架进行了增强修改，而此时TestConfiguration还并未出生；当然，***等他出生时，他已经不是他***了。

​ 最后我们跳回到ConfigurationClassEnhancer中，解决余下的问题，生成增强的代理。

// 该方法被后置处理器中的实例调用
public Class<?> enhance(Class<?> configClass, @Nullable ClassLoader classLoader) {
// 怎样判断一个类信息已经被我的逻辑增强过了 就是使用EnhancedConfiguration这个标记接口 其实就是
// BeanFactoryAware 子接口用作标记
if (EnhancedConfiguration.class.isAssignableFrom(configClass)) {
...
return configClass;
}
// 没被增强过的就增强
Class<?> enhancedClass = createClass(newEnhancer(configClass, classLoader));
...
return enhancedClass;
}

// 增强方法 CGLIB使用
private Enhancer newEnhancer(Class<?> configSuperClass, @Nullable ClassLoader classLoader) {
Enhancer enhancer = new Enhancer();
// 原配置类作为代理类的父类
enhancer.setSuperclass(configSuperClass);
// 追加一个标记接口 2个作用
// 1：用来标记生出来的是已经增强过了
// 2：加上BeanFactoryAware 让Bean工厂把自己暴漏出来 同时再工厂注入自己的时候
// 再触发另一个增强拦截(我最上面说过的三种回调机制中的BeanFactoryAwareMethodInterceptor)
// (疯狂套娃 我这里不说了 感兴趣的自行阅读源码了解)
enhancer.setInterfaces(new Class<?>[] {EnhancedConfiguration.class});
// 不使用工厂创建
enhancer.setUseFactory(false);
// 代理类名的追加
enhancer.setNamingPolicy(SpringNamingPolicy.INSTANCE);
enhancer.setStrategy(new BeanFactoryAwareGeneratorStrategy(classLoader));
// 把回调过滤器放进去 让CGLIB判断对于什么方法做怎样的增强
enhancer.setCallbackFilter(CALLBACK_FILTER);
enhancer.setCallbackTypes(CALLBACK_FILTER.getCallbackTypes());
return enhancer;
}

// 内部接口 我上面说了它干什么用的了
public interface EnhancedConfiguration extends BeanFactoryAware {
}

​ 源码分析到此结束，大致流程就是标注了@Configuration的类会在容器初始化时就被修改了内容，替换成了增强子类；等到创建后执行每个@Bean方法时，每个实例会只创建一次，其他方法再调用便是从IoC容器中获取，保证了实例的单例属性。

本篇文章还有许多细节没有说清楚，读者可以自己研究或者留言评论；如果有分析错误的地方，请评论指正谢谢。

• 点赞
• 收藏
• 分享
• 文章举报