一文带你解决Spring的循环依赖问题（包含源码解读）

这篇文章讲解一下关于我们在DI依赖注入这一篇文章遇到的Spring循环依赖问题,相信来看这篇文章的同学也被面试官用循环依赖刁难过吧？那么学习循环依赖，首先要知道循环依赖是什么？

本文的核心思想就是，

当面试官问：

“请讲一讲Spring中的循环依赖。”的时候，

我们到底该怎么回答？

主要分下面几点

1. 什么是循环依赖？
2. 什么情况下循环依赖可以被处理？
3. Spring是如何解决的循环依赖？

同时本文希望纠正几个目前业界内经常出现的几个关于循环依赖的错误的说法

1. 只有在setter方式注入的情况下，循环依赖才能解决（错）
2. 三级缓存的目的是为了提高效率（错）

什么是循环依赖？

这里举个例子你就很容易的知道啦，示例如下：

创建AService的Bean对象:

1. 实例化(new AService())

2. 给AService的bService属性赋值—>单例池—>找不到—创建BService的Bean对象
   2.1、实例化 (new BService())

   2.2、给BService的aService属性赋值—>单例池—>找不到—>创建AService的Bean对象。注意：这里就已经进入循环了，所以

   后面也不用进行下去了，因为从这里会回到第一个实例化AService。

3. 给其他属性赋值

4. 其他步骤 (AOP)

5. 放入单例池 Map<beanName，Bean对象>

一句话来说就是对象A依赖对象B的同时对象B也依赖了对象A，用图表示就是下面这样。

代码表示如下，可以自己run一下。

@Component
public class A {
    // A中注入了B
	@Autowired
	private B b;
}

@Component
public class B {
    // B中也注入了A
	@Autowired
	private A a;
}

当然，这是最常见的一种循环依赖，比较特殊的还有自己循环依赖自己

// 自己依赖自己
@Component
public class A {
    // A中注入了A
	@Autowired
	private A a;
}

如何解决循环依赖？

我们现在知道了什么是循环依赖，那么该如何解决它呢？

其实想知道的就是Spring是如何解决循环依赖这个问题的呢？原理很简单，**Spring用了缓存就解决了这个问题，再具体一点就是Spring使用了3级缓存机制，创建了3个缓存池，也就是3个Map用来存储bean的各个阶段的对象。**下面我们就来学习一下Spring中的三级缓存。

这里首先我们要清楚循环依赖的解决方式要分为两种情况来讨论：

1. 简单的循环依赖（没有AOP）
2. 结合了AOP的循环依赖

下面我们先来学习简单的循环依赖如何解决，也就是没有AOP过程的循环依赖。

简单的循环依赖（没有AOP）

我们先来分析一个最简单的例子，就是上面提到的那个demo

@Component
public class A {
    // A中注入了B
	@Autowired
	private B b;
}

@Component
public class B {
    // B中也注入了A
	@Autowired
	private A a;
}

这种情况下的循环依赖是如何被解决的呢？下面就来看一看其具体的解决循环依赖的流程：

首先，我们要知道Spring在创建Bean的时候默认是按照自然排序来进行创建的，所以第一步Spring会去创建A。

与此同时，我们应该知道，Spring在创建Bean的过程中分为三步

1. 实例化，对应方法：AbstractAutowireCapableBeanFactory中的createBeanInstance方法，其作用简单理解就是new了一个对象
2. 属性注入，对应方法：AbstractAutowireCapableBeanFactory的populateBean方法，其作用是为实例化中new出来的对象填充属性
3. 初始化，对应方法：AbstractAutowireCapableBeanFactory的initializeBean方法，其作用是执行aware接口中的方法，初始化方法，完成AOP代理

基于上面的知识，我们开始解读整个循环依赖处理的过程，整个流程以A的创建为起点。

创建A的过程实际上就是调用getBean方法，这个方法有两层含义

1. 创建一个新的Bean
2. 从缓存（单例池）中获取到已经被创建的对象

我们现在分析的是第一层含义，因为这个时候缓存中还没有A嘛！

调用getSingleton(beanName)

首先调用getSingleton(a)方法，这个方法又会调用getSingleton(beanName, true)，在上图中省略了这一步

public Object getSingleton(String beanName) {
    return getSingleton(beanName, true);
}

getSingleton(beanName, true)这个方法实际上就是到缓存中尝试去获取Bean，整个缓存分为三级

1. singletonObjects，一级缓存，存储的是所有创建好了的单例Bean
2. earlySingletonObjects，二级缓存，存储的是完成实例化，但是还未进行属性注入及初始化的对象
3. singletonFactories，三级缓存，其是提前暴露的一个单例工厂，二级缓存中存储的就是从这个工厂中获取到的对象

因为A是第一次被创建，所以不管哪个缓存中必然都是没有的，因此会进入getSingleton的另外一个重载方法getSingleton(beanName, singletonFactory)。

调用getSingleton(beanName, singletonFactory)

这个方法就是用来创建Bean的，其源码如下：

public Object getSingleton(String beanName, ObjectFactory<?> singletonFactory) {
    Assert.notNull(beanName, "Bean name must not be null");
    synchronized (this.singletonObjects) {
        Object singletonObject = this.singletonObjects.get(beanName);
        if (singletonObject == null) {
            // ....
            // 省略异常处理及日志
            // ....

            // 在单例对象创建前先做一个标记，这里这个标记非常有用，其是判断是否出现循环依赖的条件，也是解决AOP循环依赖的关键一步
            // 将beanName放入到singletonsCurrentlyInCreation这个集合中
            // 标志着这个单例Bean正在创建
            // 如果同一个单例Bean多次被创建，这里会抛出异常
            beforeSingletonCreation(beanName);
            boolean newSingleton = false;
            boolean recordSuppressedExceptions = (this.suppressedExceptions == null);
            if (recordSuppressedExceptions) {
                this.suppressedExceptions = new LinkedHashSet<>();
            }
            try {
                // 上游传入的lambda在这里会被执行，调用createBean方法创建一个Bean后返回
                singletonObject = singletonFactory.getObject();
                newSingleton = true;
            }
            // ...
            // 省略catch异常处理
            // ...
            finally {
                if (recordSuppressedExceptions) {
                    this.suppressedExceptions = null;
                }
                // 创建完成后将对应的beanName从singletonsCurrentlyInCreation移除，代表创建完毕
                afterSingletonCreation(beanName);
            }
            if (newSingleton) {
                // 添加到一级缓存singletonObjects中
                addSingleton(beanName, singletonObject);
            }
        }
        return singletonObject;
    }
}

上面的代码我们主要抓住一点，通过createBean方法返回的Bean最终被放到了一级缓存，也就是单例池中。

那么到这里我们可以得出一个结论：一级缓存中存储的是已经完全创建好了的单例Bean

调用addSingletonFactory方法

如下图所示：

在完成Bean的实例化后，属性注入之前Spring将Bean包装成一个工厂添加进了三级缓存中，对应源码如下：

// 这里传入的ObjectFactory参数也是一个lambda表达式，() -> getEarlyBeanReference(beanName, mbd, bean)
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);
        }
    }
}

这里只是添加了一个工厂，通过这个工厂（ObjectFactory）的getObject方法可以得到一个对象，而这个对象实际上就是通过getEarlyBeanReference这个方法创建的（这也是为什么传入这么一个labmda表达式的原因）。那么，什么时候会去调用这个工厂的getObject方法呢？这个时候就要到创建B的流程了。

当A完成了实例化并添加进了三级缓存后，就要开始为A进行属性注入了，在注入时发现A依赖了B，那么这个时候Spring又会去getBean(b)，然后反射调用setter方法完成属性注入。

因为B需要注入A，所以在创建B的时候，又会去调用getBean(a)，这个时候就又回到之前的流程了，但是不同的是，之前的getBean是为了创建Bean，而此时再调用getBean不是为了创建了，而是要从缓存中获取，因为之前A在实例化后已经将其放入了三级缓存singletonFactories中，所以此时getBean(a)的流程就是这样子了

从这里我们可以看出，注入到B中的A是通过getEarlyBeanReference方法提前暴露出去的一个对象，还不是一个完整的Bean，那么getEarlyBeanReference到底干啥了，我们看下它的源码

protected Object getEarlyBeanReference(String beanName, RootBeanDefinition mbd, Object bean) {
    Object exposedObject = bean;
    if (!mbd.isSynthetic() && hasInstantiationAwareBeanPostProcessors()) {
        for (BeanPostProcessor bp : getBeanPostProcessors()) {
            if (bp instanceof SmartInstantiationAwareBeanPostProcessor) {
                SmartInstantiationAwareBeanPostProcessor ibp = (SmartInstantiationAwareBeanPostProcessor) bp;
                exposedObject = ibp.getEarlyBeanReference(exposedObject, beanName);
            }
        }
    }
    return exposedObject;
}

它实际上就是调用了后置处理器的getEarlyBeanReference，而真正实现了这个方法的后置处理器只有一个，就是通过@EnableAspectJAutoProxy注解导入的AnnotationAwareAspectJAutoProxyCreator。也就是说如果在不考虑AOP的情况下，上面的代码等价于：

protected Object getEarlyBeanReference(String beanName, RootBeanDefinition mbd, Object bean) {
    Object exposedObject = bean;
    return exposedObject;
}

也就是说这个工厂啥都没干，直接将实例化阶段创建的对象返回了！所以说在不考虑AOP的情况下三级缓存没什么用，这里我们没考虑AOP所以三级缓存没有用，三级缓存就是用来解决AOP下的循环依赖问题的。

这个时候我们需要将整个创建A这个Bean的流程走完，如下图：

从上图中我们可以看到，虽然在创建B时会提前给B注入了一个还未初始化的A对象，但B从三级缓存中拿到的A对象就是我们正在创建的这个A对象，在B注入到A中之后这个A对象就会初始化完毕，所以给B注入当时一个未初始化完毕的A对象是没有问题的，因为B依赖A上的属性值是个引用，指向的就是Spring容器中这唯一一个A。

我再用文字顺序的再带大家回忆一下这整个流程（可以对比最上面那个文字流程对比看哪里不同了，流程就更清晰了）：

流程中的的普通对象就是我们刚才提到的未初始化完毕的对象

创建AService的Bean对象:

1. 实例化(new AService()) —>AService普通对象–>三级缓存池Map<beanName， AService普通对象>

2. 给AService的bService属性赋值—>去单例池即一级缓存中找BService的bean对象—>找不到—>创建BService的Bean对象
   2.1、实例化 (new BService()) —>BService普通对象

   2.2、给aService属性赋值—>单例池—>找不到—>去三级缓存池中找—>AService普通对象

   2.3、给其他属性赋值

   2.4、其他步骤 (AOP)

   2.5、放入单例池 Map<beanName， Bean对象>

3. 给其他属性赋值

4. 其他步骤 (AOP)

5. 放入单例池 Map<beanName，Bean对象>

上述就是不涉及AOP时的解决循环依赖的流程，下面我们学习存在AOP过程的循环依赖如何解决。

有AOP的循环依赖

现在我们知道了在普通的循环依赖的情况下，三级缓存没有任何作用。三级缓存实际上跟Spring中的AOP相关，我们再来看一看getEarlyBeanReference的代码：

protected Object getEarlyBeanReference(String beanName, RootBeanDefinition mbd, Object bean) {
    Object exposedObject = bean;
    if (!mbd.isSynthetic() && hasInstantiationAwareBeanPostProcessors()) {
        for (BeanPostProcessor bp : getBeanPostProcessors()) {
            if (bp instanceof SmartInstantiationAwareBeanPostProcessor) {
                SmartInstantiationAwareBeanPostProcessor ibp = (SmartInstantiationAwareBeanPostProcessor) bp;
                exposedObject = ibp.getEarlyBeanReference(exposedObject, beanName);
            }
        }
    }
    return exposedObject;
}

如果在开启AOP的情况下，那么就是调用到AnnotationAwareAspectJAutoProxyCreator的getEarlyBeanReference方法，对应的源码如下：

public Object getEarlyBeanReference(Object bean, String beanName) {
    Object cacheKey = getCacheKey(bean.getClass(), beanName);
    this.earlyProxyReferences.put(cacheKey, bean);
    // 如果需要代理，返回一个代理对象，不需要代理，直接返回当前传入的这个bean对象
    return wrapIfNecessary(bean, beanName, cacheKey);
}

回到上面的例子，我们对A进行了AOP代理的话，那么此时getEarlyBeanReference将返回一个代理后的对象，而不是实例化阶段创建的对象，这样就意味着B中注入的A将是一个代理对象而不是A的实例化阶段创建后的对象。

这里再用文字顺序的带大家回忆一下这整个流程（可以对比没有AOP的文字流程对比看哪里不同了，流程更加清晰）：

流程中的的普通对象就是我们刚才提到的未初始化完毕的对象

创建AService的Bean对象:

0. creatingSet（这一步就是判断循环依赖用的，并且是Set集合）

1. 实例化(new AService()) —>AService普通对象—>singletonFactories<beanName，lambda表达式(beanName,AService普通对象)>

2. 给AService的bService属性赋值—>去单例池即一级缓存中找BService的bean对象—>三个缓存池都找不到—>创建BService的Bean对象
   2.1、实例化 (new BService()) —>BService普通对象

   2.2、给aService属性赋值—>单例池找不到—>creatingSet判断—>循环依赖—>earlySingletonObjects—>singletonFactories—>lambda表达式—>是否提前进行AOP—>是则返回AService代理对象—>并且放入earlySingletonObjects二级缓存中

   ​ 不需要进行AOP则也无所谓提前了—>返回AService普通对象

   无论返回代理还是普通对象，ObjectFactory这个lambda表达式在整个过程进行完毕即A初始化后都会销毁

   2.3、给其他属性赋值

   2.4、其他步骤 (AOP)这里其实还有一个Map是用来判断是否提前进行过AOP

   2.5、放入单例池 Map<beanName， Bean对象>

3. 给其他属性赋值

4. 其他步骤 (AOP)

5. 放入单例池 Map<beanName，Bean对象>

注意我们在第四步才会进行AOP，这时如果AService需要AOP的话我们最后会得到一个AOP之后的代理对象，而不再是原来的AService对象了！！！那么原本BService中的AService属性就是错的了，因为AOP时不会处理BService中的属性，这也就是下文中为什么**如果进行AOP的话需要提前得到一个代理对象的原因。**而且只有出现了循环依赖才会提前进行AOP获得代理对象，下文会对其详细解释。

这里再说明一下三级缓存在Spring中对应名称及作用
singletonObjects: 第一级缓存:存储最终Bean对象 (经过所有步骤之后的对象)
earlySingletonObjects : 第二级缓存：保持单例bean用的。比如Aservice还有一个cService属性也需要赋值，且这个C也有一个属性是A，那么它俩也构成了循环依赖，那么如果也需要AOP时就也会给CService返回一个A的代理对象，这个对象不会和B的A代理对象相同，就构成了错误，所以正如普通对象放入三级缓存一样，代理对象会放入二级缓存，在需要时会取出来。
singletonFactories : 第三级缓存 打破循环

看到上面那个流程图你可能会产生下面这些疑问

1. 在给B注入的时候为什么要注入一个代理对象？

答：当我们对A进行了AOP代理时，说明我们希望从容器中获取到的就是A代理后的对象而不是A本身（因为我们要的就是经过AOP之后的A对象），因此把A当作依赖进行注入时也要注入它的代理对象

2. 明明初始化的时候是A对象，那么Spring是在哪里将代理对象放入到容器中的呢？

在完成初始化后，Spring又调用了一次getSingleton方法，这一次传入的参数又不一样了，false可以理解为禁用三级缓存，前面图中已经提到过了，在为B中注入A时已经将三级缓存中的工厂取出，并从工厂中获取到了一个对象放入到了二级缓存中，所以这里的这个getSingleton方法做的就是从二级缓存中获取到这个代理后的A对象。exposedObject == bean可以认为是必定成立的，除非你非要在初始化阶段的后置处理器中替换掉正常流程中的Bean，例如增加一个后置处理器：

@Component
public class MyPostProcessor implements BeanPostProcessor {
	@Override
	public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
		if (beanName.equals("a")) {
			return new A();
		}
		return bean;
	}
}

不过，请不要做这种骚操作，徒增烦恼！

3. 初始化的时候是对A对象本身进行初始化，而容器中以及注入到B中的都是代理对象，这样不会有问题吗？

答：不会，这是因为不管是cglib代理还是jdk动态代理生成的代理类，内部都持有一个目标类的引用，当调用代理对象的方法时，实际会去调用目标对象的方法，A完成初始化相当于代理对象自身也完成了初始化

4. 三级缓存为什么要使用工厂而不是直接使用引用？换而言之，为什么需要这个三级缓存，直接通过二级缓存暴露一个引用不行吗？

答：这个工厂的目的在于延迟对实例化阶段生成的对象的代理，只有真正发生循环依赖的时候，才去提前生成代理对象，否则只会创建一个工厂并将其放入到三级缓存中，但是不会去通过这个工厂去真正创建对象

我们思考一种简单的情况，就以单独创建A为例，假设AB之间现在没有依赖关系，但是A被代理了，这个时候当A完成实例化后还是会进入下面这段代码：

// A是单例的，mbd.isSingleton()条件满足
// allowCircularReferences：这个变量代表是否允许循环依赖，默认是开启的，条件也满足
// isSingletonCurrentlyInCreation：正在在创建A，也满足
// 所以earlySingletonExposure=true
boolean earlySingletonExposure = (mbd.isSingleton() && this.allowCircularReferences &&
                                  isSingletonCurrentlyInCreation(beanName));
// 还是会进入到这段代码中
if (earlySingletonExposure) {
	// 还是会通过三级缓存提前暴露一个工厂对象
    addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));
}

看到了吧，即使没有循环依赖，也会将其添加到三级缓存中，而且是不得不添加到三级缓存中，因为到目前为止Spring也不能确定这个Bean有没有跟别的Bean出现循环依赖。

假设我们在这里直接使用二级缓存的话，那么意味着所有的Bean在这一步都要完成AOP代理。这样做有必要吗？

不仅没有必要，而且违背了Spring在结合AOP跟Bean的生命周期的设计！Spring结合AOP跟Bean的生命周期本身就是通过AnnotationAwareAspectJAutoProxyCreator这个后置处理器来完成的，在这个后置处理的postProcessAfterInitialization方法中对初始化后的Bean完成AOP代理。**如果出现了循环依赖，那没有办法，只有给Bean先创建代理，但是没有出现循环依赖的情况下，设计之初就是让Bean在生命周期的最后一步完成代理而不是在实例化后就立马完成代理。**但我们使用三级就不一样了，只需要在出现循环依赖并且需要进行AOP时才会提前进行AOP，并且把代理对象放进二级缓存，与普通对象放入三级缓存分开（如果只有二级而两者放入一个缓存池，那么为了区分就无论是否后来需要进行AOP都提前进行AOP了，这样才全部都是代理对象而没有其他对象）。

三级缓存真的提高了效率了吗？

现在我们已经知道了三级缓存的真正作用，但是这个答案可能还无法说服你，所以我们再最后总结分析一波，三级缓存真的提高了效率了吗？分为两点讨论：

1. 没有进行AOP的Bean间的循环依赖

从上文分析可以看出，这种情况下三级缓存根本没用！所以不会存在什么提高了效率的说法

2. 进行了AOP的Bean间的循环依赖

就以我们上的A、B为例，其中A被AOP代理，我们先分析下使用了三级缓存的情况下，A、B的创建流程

假设不使用三级缓存，直接在二级缓存中

上面两个流程的唯一区别在于为A对象创建代理的时机不同，在使用了三级缓存的情况下为A创建代理的时机是在B中需要注入A的时候，而不使用三级缓存的话在A实例化后就需要马上为A创建代理然后放入到二级缓存中去。对于整个A、B的创建过程而言，消耗的时间是一样的

综上，不管是哪种情况，三级缓存提高了效率这种说法都是错误的！

最后，是否这样处理循环依赖就万事大吉了呢？其实不然，Spring对一些循环依赖是没有进行处理的，我们继续看。

什么情况下循环依赖可以被处理？

在回答这个问题之前首先要明确一点，Spring解决循环依赖是有前置条件的

1. 出现循环依赖的Bean必须要是单例
2. 依赖注入的方式不能全是构造器注入的方式

其中第一点应该很好理解，第二点：不能全是构造器注入是什么意思呢？我们还是用代码说话

@Component
public class A {
//	@Autowired
//	private B b;
	public A(B b) {

	}
}


@Component
public class B {

//	@Autowired
//	private A a;

	public B(A a){

	}
}

在上面的例子中，A中注入B的方式是通过构造器，B中注入A的方式也是通过构造器，这个时候循环依赖是无法被解决，如果你的项目中有两个这样相互依赖的Bean，在启动时就会报出以下错误：

Caused by: org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'a': Requested bean is currently in creation: Is there an unresolvable circular reference?

为了测试循环依赖的解决情况跟注入方式的关系，我们做如下四种情况的测试

依赖情况	依赖注入方式	循环依赖是否被解决
AB相互依赖（循环依赖）	均采用setter方法注入	是
AB相互依赖（循环依赖）	均采用构造器注入	否
AB相互依赖（循环依赖）	A中注入B的方式为setter方法，B中注入A的方式为构造器	是
AB相互依赖（循环依赖）	B中注入A的方式为setter方法，A中注入B的方式为构造器	否

从上面的测试结果我们可以看到，不是只有在setter方法注入的情况下循环依赖才能被解决，即使存在构造器注入的场景下，循环依赖依然被可以被正常处理掉。那么到底是为什么呢？

其实答案很简单，setter注入和构造注入的区别就是是否会创建A，如果我们使用setter注入那么A就会通过无参构造方法（或者是不会进行构造注入的构造方法）创建出A实例即可以进入创建A实例这个过程，而使用构造注入则无法创建A，因为构造方法的参数BSpring容器就需要先去获取，然后进入循环依赖（A也获取不到，因为A的构造方法根本就没有进行）。

那么对于上述3.4例子一个是一个否你就也明白原因了吧？是的原因就是循环依赖的入口就是A（Spring在创建Bean时默认会根据自然排序进行创建），并且A已经通过无参构造方法创建出来普通对象了。

那有同学说我就要用构造注入创建bean呢？能不能解决循环依赖问题？

这也是可以的，只需要在构造注入的方法上面加上@Lazy注解就可以了，就是懒加载机制。不了解的同学可以认为加上这个注解之后再执行A的构造注入如果需要B时Spring会创建B的一个代理对象传进去，这样就可以进行初始化了。（这里代理对象实现就是通过CGLib实现的，它是一种基于继承实现的代理）。

总结

面试官问我们：”Spring是如何解决的循环依赖？“

答：Spring通过三级缓存解决了循环依赖，其中一级缓存为单例池（singletonObjects）,二级缓存为早期曝光对象earlySingletonObjects，三级缓存为早期曝光对象工厂（singletonFactories）。当A、B两个类发生循环引用时，在A完成实例化后，就使用实例化后的对象去创建一个对象工厂，并添加到三级缓存中，如果A被AOP代理，那么通过这个工厂获取到的就是A代理后的对象，如果A没有被AOP代理，那么这个工厂获取到的就是A实例化的对象。当A进行属性注入时，会去创建B，同时B又依赖了A，所以创建B的同时又会去调用getBean(a)来获取需要的依赖，此时的getBean(a)会从缓存中获取，第一步，先获取到三级缓存中的工厂；第二步，调用对象工工厂的getObject方法来获取到对应的对象，得到这个对象后将其注入到B中。紧接着B会走完它的生命周期流程，包括初始化、后置处理器等。当B创建完后，会将B再注入到A中，此时A再完成它的整个生命周期。至此，循环依赖结束！

面试官：”为什么要使用三级缓存呢？二级缓存能解决循环依赖吗？“

答：如果要使用二级缓存解决循环依赖，意味着所有Bean在实例化后就要完成AOP代理，这样违背了Spring设计的原则，Spring在设计之初就是通过AnnotationAwareAspectJAutoProxyCreator这个后置处理器来在Bean生命周期的最后一步来完成AOP代理，而不是在实例化后就立马进行AOP代理。并且如果有多个循环依赖的话也会导致出错。

---

感谢耐心看到这里的同学，觉得文章对您有帮助的话希望同学们不要吝啬您手中的赞，动动您智慧的小手，您的认可就是我创作的动力！
之后还会勤更自己的学习笔记，感兴趣的朋友点点关注哦。