关于属性填充方法的详细介绍可参考链接：属性填充populateBean当填充BeanServiceB会重复上文第1节中的内容：

• a.%20先从一级缓存singletonObjects中获取，发现获取不到，然后看是否在创建中，显然初次创建时不成立，即getSingleton返回null
• b.%20调用第14行的getSingleton方法触发createBean回调，进行bean的生命周期
• c.%20实例化BeanServiceB的不完整对象，并将lambda写入三级缓存
• d.%20属性填充BeanServiceA（见下文1.1.2.1）

• e.%20initializeBean初始化BeanServiceB

  3.1.2.1.%20上面的d，循环依赖处理属性填充BeanServiceA:

  同样，会重复上文第1节的内容，但此时会有不一样的处理：

• a.%20先从一级缓存singletonObjects中获取，发现获取不到，然后看是否在创建中,显然正在创建，singletonsCurrentlyInCreation有beanServiceA

• b.%20从二级缓存中获取%20→%20获取不到%20→%20从三级缓存获取%20→%20lambda表达式回调（见下文1.1.2.1.1）
• c.%20将不完整对象BeanServiceA写入二级缓存，三级缓存删除该对象lambda表达式（上文1中getSingleton方法）

• d.%20返回不完整的BeanServiceA对象

  3.1.1.2.1.1.%20AbstractAutoProxyCreator#getEarlyBeanReference:

  这里涉及Aop

  protected%20Object%20getEarlyBeanReference(String%20beanName,%20RootBeanDefinition%20mbd,%20Object%20bean)%20{
%20%20Object%20exposedObject%20=%20bean;%20%20if%20(!mbd.isSynthetic()%20&&%20hasInstantiationAwareBeanPostProcessors())%20{%20%20%20%20%20%20//遍历后置处理器%20%20%20%20%20%20for%20(BeanPostProcessor%20bp%20:%20getBeanPostProcessors())%20{%20%20%20%20%20%20%20%20%20%20if%20(bp%20instanceof%20SmartInstantiationAwareBeanPostProcessor)%20{%20%20%20%20%20%20%20%20%20%20%20%20%20%20SmartInstantiationAwareBeanPostProcessor%20ibp%20=%20(SmartInstantiationAwareBeanPostProcessor)%20bp;%20%20%20%20%20%20%20%20%20%20%20%20%20%20//%20调用后置处理器的getEarlyBeanReference进行提前暴露bean%20%20%20%20%20%20%20%20%20%20%20%20%20%20exposedObject%20=%20ibp.getEarlyBeanReference(exposedObject,%20beanName);%20%20%20%20%20%20%20%20%20%20}%20%20%20%20%20%20}%20%20}%20%20return%20exposedObject;}

lambda回调会调用后置处理器的getEarlyBeanReference，来获取不完整的bean

• 如果当前依赖的bean不涉及Aop，则返回实例化时创建的不完整bean对象

• 如果当前依赖的bean涉及Aop，则返回一个代理该不完整bean的代理对象

• 本处返回实例化创建的不完整beanServiceA对象

  public%20Object%20getEarlyBeanReference(Object%20bean,%20String%20beanName)%20{
%20%20Object%20cacheKey%20=%20getCacheKey(bean.getClass(),%20beanName);%20%20//%20写入earlyProxyReferences，在后面postProcessAfterInitialization会用到%20%20this.earlyProxyReferences.put(cacheKey,%20bean);%20%20//%20判断是否创建代理对象%20%20return%20wrapIfNecessary(bean,%20beanName,%20cacheKey);}
3.1.2.2%20初始化BeanServiceB时调用AOP后置处理器进行AOP处理

属性填充beanServiceA后，此时填充的beanServiceA是不完整的对象,在initializeBean初始化调用后置处理器的postProcessAfterInitialization方法由于BeanServiceB不涉及AOP，所以返回原始的B对象，此时填充的beanServiceA还是不完整的对象

• B不涉及提前AOP，所以earlyProxyReferences没有beanServiceB（见上文3.1.2.1.1）

• remove返回null，条件成立，执行wrapIfNecessary方法

• 由于beanServiceB不涉及AOP，所以返回原始的B对象

  3.1.2.3. 处理提前暴露的场景，保证返回同一个代理对象

  BeanServiceB不涉及AOP，getSingleton返回null，所以直接返回原始对象exposedObject

  3.1.2.4. BeanServiceB对象写入一级缓存，移除二、三级缓存

  beanServiceB生命周期执行完，返回到3.1节第14行的getSingleton方法，此时返回的还是不完整的beanServiceB对象singletonsCurrentlyInCreation移除bean，表明不再是正在创建的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) {
            ... ... ...
                // 会将当前beanName放入singletonsCurrentlyInCreation，表示当前bean正在创建
                beforeSingletonCreation(beanName);
            ... ... ...
                try {
                    // lambda表达式回到createBean
                    singletonObject = singletonFactory.getObject();
                    newSingleton = true;
                    ... ... ..
                    }
            finally {
                if (recordSuppressedExceptions) {
                    this.suppressedExceptions = null;
                }
                // singletonsCurrentlyInCreation中移除beanName，表示该bean不是正在创建了
                afterSingletonCreation(beanName);
            }
            if (newSingleton) {
                // 将不完整的beanServiceB对象写入一级缓存，移除二、三级缓存
                addSingleton(beanName, singletonObject);
            }
        }
        return singletonObject;
    }
  }

  beanServiceB“不完整对象”写入一级缓存，移除二、三级缓存

  protected void addSingleton(String beanName, Object singletonObject) {
    synchronized (this.singletonObjects) {
        // 写入一级缓存
        this.singletonObjects.put(beanName, singletonObject);
        // 移除二、三级缓存
        this.singletonFactories.remove(beanName);
        this.earlySingletonObjects.remove(beanName);
        this.registeredSingletons.add(beanName);
    }
  }

  3.1.3. BeanServiceA属性填充BeanServiceB（完整bean）

  此时ioc容器已经有了beanServiceB，虽然暂时还是不完整的，因为A还没填充初始化完当beanServiceA填充完beanServiceB后，使得互相循环依赖对方，此时二者都变成了完整的bean此时一级缓存的beanServiceB也由不完整的bean变成了完整的bean，因为是同一个地址A涉及AOP，所以循环依赖时，A会进行提前AOP，所以B中填充的是A的代理对象当A填充完B时，构成互相循环依赖对方

  3.1.4. 初始化BeanServiceA时调用AOP后置处理器进行AOP处理

  由于beanServiceA提前AOP了，所以所以earlyProxyReferences有beanServiceA（见上文3.1.2.1.1）remove返回原始的bean，即earlyProxyReferences对应的value，条件不成立，直接==返回原始bean ==

  3.1.5. 处理提前暴露的场景，保证返回同一个代理对象

  beanServiceA涉及提前AOP，getSingleton返回保存在二级缓存中提前AOP的代理对象A这里面有exposedObject == bean判断，这就是为什么上述3.1.4中AOP后置处理器返回原始bean的原因条件成立，将代理对象赋值放回，保证返回同一个代理对象，即B中的A和A都是同一个代理对象

  3.2. BeanServiceA完整对象写入一级缓存，移除二、三级缓存

  同3.1.2.4节一样，beanServiceA生命周期执行完，会将beanServiceA写入一级缓存，移除二、三级缓存

  四、整体流程

  4.1 涉及循环依赖&&涉及AOP的场景

  

  4.2 不涉及AOP的循环依赖场景

• 不涉及AOP，那么A进行lambda表达式回调后返回就A的原始对象，保存到二级缓存中，所以B属性填充后的A也是A的原始对象

• 当A属性填充完后，A和B相互依赖，使得二者都是完整的对象，可见上文3.1.3的图

  4.3 不涉及循环依赖的AOP场景

• 不涉及循环依赖，也就不涉及提前AOP，正常A经过实例化–属性填充–初始化

• 在初始化时通过AOP后置处理器创建代理对象返回，在上文1.1.5节，二级缓存返回null，最终直接返回代理对象A

  4.4 不涉及循环依赖&&不涉及AOP场景

• 不涉及循环依赖，也就不涉及提前AOP，正常A经过实例化–属性填充–初始化

• 不涉及AOP，则在初始化时通过AOP后置处理器直接返回原始A对象，在上文1.1.5节，二级缓存返回null，最终返回原始A对象

  五、疑问：

  5.1 为什么三级缓存用HashMap，而不像一级缓存使用ConcurrentHashMap

  现有逻辑是，三级缓存的操作是在synchronized代码块里面操作的，是安全的那为什么要用synchronized而不直接用ConcurrentHashMap来保证线程安全呢？二级缓存put的同时要保证三级缓存remove；三级缓存put时要保证二级缓存remove，也就是说二三级缓存操作要保证原子性因为要保证同一个bean是单例的，不然都会lambda回调创建bean，就不是单例的了如果使用ConcurrentHashMap并不能保证二三级缓存操作的原子性，所以要用synchronized这三级缓存都是在synchronized内操作的，至于一级缓存为什么用ConcurrentHashMap，可能其他场景的原因。

  5.2 什么要第三级缓存？

  主要用于循环依赖的bean需要AOP时提前AOP如果没有第三级缓存，那么getSingleton就返回null，就会再次传教A，导致一直循环创建，现有逻辑就不对.那如果将实例化的原始对象放入二级缓存呢？没有第三级缓存，就无法提前AOP，则B属性填充完的A为A原始对象而A在属性填充完B后，需要进行AOP，则经过AOP后置处理器会去创建代理对象A返回这就导致B的属性A不是代理对象，而A却是代理对象，这与Spring的单例bean是矛盾的。

  5.3代码里如果出现了循环依赖怎么处理比较好？

1. 使用@Lazy注解，延迟加载
2. 使用@DependsOn注解，指定加载先后关系
3. 修改文件名称，改变循环依赖类的加载顺序