什么是三级缓存

在获取单例bean的时候，会进入以下方法：

org.springframework.beans.factory.support.DefaultSingletonBeanRegistry#getSingleton(java.lang.String, boolean)
protected Object getSingleton(String beanName, boolean allowEarlyReference) {
                // 1
        Object singletonObject = this.singletonObjects.get(beanName);
        if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {
            synchronized (this.singletonObjects) {
                                // 2
                singletonObject = this.earlySingletonObjects.get(beanName);
                if (singletonObject == null && allowEarlyReference) {
                                        // 3
                    ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName);
                    if (singletonFactory != null) {
                                                // 4
                        singletonObject = singletonFactory.getObject();
                        this.earlySingletonObjects.put(beanName, singletonObject);
                        this.singletonFactories.remove(beanName);
                    }
                }
            }
        }
        return singletonObject;
    }

这里面涉及到了该类中的三个field。

    /** 1级缓存 Cache of singleton objects: bean name to bean instance. */
    private final Map<String, Object> singletonObjects = new ConcurrentHashMap<>(256);

    /** 2级缓存 Cache of early singleton objects: bean name to bean instance. */
    private final Map<String, Object> earlySingletonObjects = new HashMap<>(16);

    /** 3级缓存 Cache of singleton factories: bean name to ObjectFactory. */
    private final Map<String, ObjectFactory<?>> singletonFactories = new HashMap<>(16);

接着说前面的代码。

• 1处，在最上层的缓存singletonObjects中，获取单例bean，这里面拿到的bean，直接可以使用；如果没取到，则进入2处
• 2处，在2级缓存earlySingletonObjects中，查找bean；
• 3处，如果在2级缓存中，还是没找到，则在3级缓存中查找对应的工厂对象，利用拿到的工厂对象（工厂对象中，有3个field，一个是beanName，一个是RootBeanDefinition，一个是已经创建好的，但还没有注入属性的bean），去获取包装后的bean，或者说，代理后的bean。
  什么是已经创建好的，但没有注入属性的bean？
  比如一个bean，有10个字段，你new了之后，对象已经有了，内存空间已经开辟了，堆里已经分配了该对象的空间了，只是此时的10个field还是null。

ioc容器，普通循环依赖，一级缓存够用吗

说实话，如果简单写写的话，一级缓存都没问题。给大家看一个我以前写的渣渣ioc容器：

曹工说Tomcat4：利用 Digester 手撸一个轻量的 Spring IOC容器

@Data
public class BeanDefinitionRegistry {
    /**
     * map：存储 bean的class-》bean实例
     */
    private Map<Class, Object> beanMapByClass = new ConcurrentHashMap<>();

    /**
     * 根据bean 定义获取bean
     * 1、先查bean容器，查到则返回
     * 2、生成bean，放进容器（此时，依赖还没注入，主要是解决循环依赖问题）
     * 3、注入依赖
     *
     * @param beanDefiniton
     * @return
     */
    private Object getBean(MyBeanDefiniton beanDefiniton) {
        Class<?> beanClazz = beanDefiniton.getBeanClazz();
        Object bean = beanMapByClass.get(beanClazz);
        if (bean != null) {
            return bean;
        }
        // 0
        bean = generateBeanInstance(beanClazz);


        // 1 先行暴露，解决循环依赖问题
        beanMapByClass.put(beanClazz, bean);
        beanMapByName.put(beanDefiniton.getBeanName(), bean);

        // 2 查找依赖
        List<Field> dependencysByField = beanDefiniton.getDependencysByField();
        if (dependencysByField == null) {
            return bean;
        }

        // 3
        for (Field field : dependencysByField) {
            try {
                autowireField(beanClazz, bean, field);
            } catch (Exception e) {
                throw new RuntimeException(beanClazz.getName() + " 创建失败",e);
            }
        }

        return bean;
    }
}

大家看上面的代码，我只定义了一个field，就是一个map，存放bean的class-》bean。

    /**
     * map：存储 bean的class-》bean实例
     */
    private Map<Class, Object> beanMapByClass = new ConcurrentHashMap<>();

• 0处，生成bean，直接就是new
• 1处，先把这个不完整的bean，放进map
• 2处，获取需要注入的属性集合
• 3处，进行自动注入，就是根据field的Class，去map里查找对应的bean，设置到field里。

上面这个代码，有啥问题没？spring为啥整整三级？

ioc，一级缓存有什么问题

一级缓存的问题在于，就1个map，里面既有完整的已经ready的bean，也有不完整的，尚未设置field的bean。

如果这时候，有其他线程去这个map里获取bean来用怎么办？拿到的bean，不完整，怎么办呢？属性都是null，直接空指针了。

所以，我们就要加一个map，这个map，用来存放那种不完整的bean。这里，还是拿spring举例。我们可以只用下面这两层：

    /** 1级缓存 Cache of singleton objects: bean name to bean instance. */
    private final Map<String, Object> singletonObjects = new ConcurrentHashMap<>(256);

    /** 2级缓存 Cache of early singleton objects: bean name to bean instance. */
    private final Map<String, Object> earlySingletonObjects = new HashMap<>(16);

因为spring代码里是三级缓存，所以我们对源码做一点修改。

修改spring源码，只使用二级缓存

修改创建bean的代码，不放入第三级缓存，只放入第二级缓存

创建了bean之后，属性注入之前，将创建出来的不完整bean，放到earlySingletonObjects

这个代码，在org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory#doCreateBean，我这边只有4.0版本的spring源码工程，不过这套逻辑，算是spring核心逻辑，和5.x版本差别不大。

protected Object doCreateBean(final String beanName, final RootBeanDefinition mbd, final Object[] args) {
        BeanWrapper instanceWrapper = null;
        if (mbd.isSingleton()) {
            instanceWrapper = this.factoryBeanInstanceCache.remove(beanName);
        }
        if (instanceWrapper == null) {
            // 1
            instanceWrapper = createBeanInstance(beanName, mbd, args);
        }
        final Object bean = (instanceWrapper != null ? instanceWrapper.getWrappedInstance() : null);
        Class beanType = (instanceWrapper != null ? instanceWrapper.getWrappedClass() : null);
        ...
        boolean earlySingletonExposure = (mbd.isSingleton() && this.allowCircularReferences &&
                isSingletonCurrentlyInCreation(beanName));
        if (earlySingletonExposure) {
            // 2
            earlySingletonObjects.put(beanName,bean);
            registeredSingletonObjects.add(beanName);
            // 3
//            addSingletonFactory(beanName, new ObjectFactory() {
//                public Object getObject() throws BeansException {
//                    return getEarlyBeanReference(beanName, mbd, bean);
//                }
//            });
        }

• 1处，就是创建对象，就是new
• 2处，这是我加的代码，放入二级缓存
• 3处，本来这就是增加三级缓存的位置，被我注释了。现在，就不会往三级缓存放东西了

修改获取bean的代码，只从第一、第二级缓存获取，不从第三级获取

org.springframework.beans.factory.support.DefaultSingletonBeanRegistry#getSingleton(java.lang.String, boolean)

之前的代码是文章开头那样的，我这里修改为：

    protected Object getSingleton(String beanName, boolean allowEarlyReference) {
        Object singletonObject = this.singletonObjects.get(beanName);
        if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {
            synchronized (this.singletonObjects) {
                singletonObject = this.earlySingletonObjects.get(beanName);
                return singletonObject;
            }
        }
        return (singletonObject != NULL_OBJECT ? singletonObject : null);

这样，就是只用两级缓存了。

两级缓存，有啥问题？

ioc循环依赖，一点问题都没有，完全够用了。

我这边一个简单的例子，

public class Chick{
    private Egg egg;

    public Egg getEgg() {
        return egg;
    }

    public void setEgg(Egg egg) {
        this.egg = egg;
    }
}
public class Egg {
    private Chick chick;

    public Chick getChick() {
        return chick;
    }

    public void setChick(Chick chick) {
        this.chick = chick;
    }
}

    <bean id="chick" class="foo.Chick" lazy-init="true">
        <property name="egg" ref="egg"/>
    </bean>
    <bean id="egg" class="foo.Egg" lazy-init="true">
        <property name="chick" ref="chick"/>
    </bean>

public class CircleBootstrap {
    public static void main(String[] args) {       
        ClassPathXmlApplicationContext ctx = new ClassPathXmlApplicationContext(
                "context-namespace-test-aop.xml");
        Egg egg = (Egg) ctx.getBean(Egg.class);
    }
}

结论：

所以，一级缓存都能解决的问题，二级当然更没问题。

但是，如果我这里给上面的Egg类，加个切面（aop的逻辑，意思就是最终会生成Egg的一个动态代理对象），那还有问题没？

    <aop:config>
        <aop:pointcut id="mypointcut" expression="execution(public * foo.Egg.*(..))"/>
        <aop:aspect id="myAspect" ref="performenceAspect">
            <aop:after method="afterIncubate" pointcut-ref="mypointcut"/>
        </aop:aspect>
    </aop:config>

注意这里的切点：

execution(public * foo.Egg.*(..))

就是切Egg类的方法。

加了这个逻辑后，我们继续运行，在Egg egg = (Egg) ctx.getBean(Egg.class);行，会抛出如下异常：

我涂掉了一部分，因为那是官方对这个异常的推论，因为我们改了代码，所以推论不准确，因此干脆隐去。

这个异常是说：

兄弟啊，bean egg已经被注入到了其他bean：chick中。（因为我们循环依赖了），但是，注入到chick中的，是Egg类型。但是，我们这里最后对egg这个bean，进行了后置处理，生成了代理对象。那其他bean里，用原始的bean，是不是不太对啊？

所以，spring给我们抛错了。

怎么理解呢？ 以io流举例，我们一开始都是用的原始字节流，然后给别人用的也是字节流，但是，最后，我感觉不方便，我自己悄悄弄了个缓存字符流（类比代理对象），我是方便了，但是，别人用的，还是原始的字节流啊。

你bean不是单例吗？不能这么玩吧？

所以，这就是二级缓存，不能解决的问题。

什么问题？aop情形下，注入到其他bean的，不是最终的代理对象。

三级缓存，怎么解决这个问题

要解决这个问题，必须在其他bean（chick），来查找我们（以上面例子为例，我们是egg）的时候，查找到最终形态的egg，即代理后的egg。

怎么做到这点呢？

加个三级缓存，里面不存具体的bean，里面存一个工厂对象。通过工厂对象，是可以拿到最终形态的代理后的egg。

ok，我们将前面修改的代码还原：

protected Object doCreateBean(final String beanName, final RootBeanDefinition mbd, final Object[] args) {
        BeanWrapper instanceWrapper = null;
        if (mbd.isSingleton()) {
            instanceWrapper = this.factoryBeanInstanceCache.remove(beanName);
        }
        if (instanceWrapper == null) {
            // 1
            instanceWrapper = createBeanInstance(beanName, mbd, args);
        }
        final Object bean = (instanceWrapper != null ? instanceWrapper.getWrappedInstance() : null);
        Class beanType = (instanceWrapper != null ? instanceWrapper.getWrappedClass() : null);

        boolean earlySingletonExposure = (mbd.isSingleton() && this.allowCircularReferences &&
                isSingletonCurrentlyInCreation(beanName));
        if (earlySingletonExposure) {
            // 2
//            Map<String, Object> earlySingletonObjects = this.getEarlySingletonObjects();
//            earlySingletonObjects.put(beanName,bean);
//
//            Set<String> registeredSingletonObjects = this.getRegisteredSingletonObjects();
//            registeredSingletonObjects.add(beanName);

            // 3
            addSingletonFactory(beanName, new ObjectFactory() {
                public Object getObject() throws BeansException {
                    return getEarlyBeanReference(beanName, mbd, bean);
                }
            });
        }

• 1处，创建bean，单纯new，不注入
• 2处，revert我们的代码
• 3处，这里new了一个ObjectFactory，然后会存入到如下的第三级缓存。
  注意，new一个匿名内部类（假设这个匿名类叫AA）的对象，其中用到的外部类的变量，都会在AA中隐式生成对应的field。
  
  大家看上图，里面的3个字段，和下面代码1处中的，几个字段，是一一对应的。

   /** 3级缓存 Cache of singleton factories: bean name to ObjectFactory. */
   private final Map<String, ObjectFactory<?>> singletonFactories = new HashMap<>(16);
  

           addSingletonFactory(beanName, new ObjectFactory() {
               public Object getObject() throws BeansException {
                   // 1
                   return getEarlyBeanReference(beanName, mbd, bean);
               }
           });
  

ok，现在，egg已经把自己存进去了，存在了第三级缓存，1级和2级都没有，那后续chick在使用getSingleton查找egg的时候，就会进入下面的逻辑了（就是文章开头的那段代码,下面已经把我们的修改还原了）：

protected Object getSingleton(String beanName, boolean allowEarlyReference) {
//        Object singletonObject = this.singletonObjects.get(beanName);
//        if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {
//            synchronized (this.singletonObjects) {
//                singletonObject = this.earlySingletonObjects.get(beanName);
//                return singletonObject;
//            }
//        }
//        return (singletonObject != NULL_OBJECT ? singletonObject : null);

        Object singletonObject = this.singletonObjects.get(beanName);
        if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {
            synchronized (this.singletonObjects) {
                singletonObject = this.earlySingletonObjects.get(beanName);
                if (singletonObject == null && allowEarlyReference) {
                    ObjectFactory singletonFactory = this.singletonFactories.get(beanName);
                    if (singletonFactory != null) {
                        // 1
                        singletonObject = singletonFactory.getObject();
                        this.earlySingletonObjects.put(beanName, singletonObject);
                        this.singletonFactories.remove(beanName);
                    }
                }
            }
        }
        return (singletonObject != NULL_OBJECT ? singletonObject : null);
    }

上面就会进入1处，调用singletonFactory.getObject();。

而前面我们知道，这个factory的逻辑是：

            addSingletonFactory(beanName, new ObjectFactory() {
                public Object getObject() throws BeansException {
                    // 1
                    return getEarlyBeanReference(beanName, mbd, bean);
                }
            });

1处就是这个工厂方法的逻辑，这里面，简单说，就会去调用各个beanPostProcessor的getEarlyBeanReference方法。

其中，主要就是aop的主力beanPostProcessor，AbstractAutoProxyCreator#getEarlyBeanReference

其实现如下：

    public Object getEarlyBeanReference(Object bean, String beanName) throws BeansException {
        Object cacheKey = getCacheKey(bean.getClass(), beanName);
        this.earlyProxyReferences.add(cacheKey);
        // 1
        return wrapIfNecessary(bean, beanName, cacheKey);
    }

这里的1处，就会去对egg这个bean，创建代理，此时，返回的对象，就是个代理对象了，那，注入到chick的，自然也是代理后的egg了。

关于SmartInstantiationAwareBeanPostProcessor

我们上面说的那个getEarlyBeanReference就在这个接口中。

这个接口继承了BeanPostProcessor。

而创建代理对象，目前就是在如下两个方法中去创建：

public interface BeanPostProcessor {
    Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException;
    Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException;    
}

这两个方法，都是在实例化之后，创建代理。那我们前面创建代理，是在依赖解析过程中：

public interface SmartInstantiationAwareBeanPostProcessor extends InstantiationAwareBeanPostProcessor {
    ...
    Object getEarlyBeanReference(Object bean, String beanName) throws BeansException;
}

所以，spring希望我们，在这几处，要返回同样的对象，即：既然你这几处都要返回代理对象，那就不能返回不一样的代理对象。

那我们再看看，到底，AbstractAutoProxyCreator有没有遵守约定呢，这几个方法里，有没有去返回同样的代理包装对象呢？

getEarlyBeanReference

    public Object getEarlyBeanReference(Object bean, String beanName) throws BeansException {
        Object cacheKey = getCacheKey(bean.getClass(), beanName);
        // 1
        this.earlyProxyReferences.add(cacheKey);
        return wrapIfNecessary(bean, beanName, cacheKey);
    }

1处，往field：

private final Set<Object> earlyProxyReferences =
      Collections.newSetFromMap(new ConcurrentHashMap<Object, Boolean>(16));

里，加了个cachekey，这个cachekey，主要也就是如下的字符串，用来唯一标识而已。

    protected Object getCacheKey(Class<?> beanClass, String beanName) {
        return beanClass.getName() + "_" + beanName;
    }

我们可以看看这个field在哪里被用到了。

也就两处，一处就是当前位置；另外一处，下面讲。

这里，主要就是看看到底要不要生成代理对象，要的话，就生成，不要就算了，另外，做了个标记：在earlyProxyReferences加了当前bean的key，表示：当前bean，已经被getEarlyBeanReference方法处理过了。

至于，最终到底有没有生成代理对象，另说。毕竟调用wrapIfNecessary也不是说，一定就满足切面，要生成代理对象。

可能返回的仍然是原始对象。

postProcessBeforeInitialization

public Object postProcessBeforeInitialization(Object bean, String beanName) {
   return bean;
}

这一处，没做处理。

postProcessAfterInitialization

    @Override
    public Object postProcessAfterInitialization(@Nullable Object bean, String beanName) {
        if (bean != null) {
            Object cacheKey = getCacheKey(bean.getClass(), beanName);
            //1
            if (this.earlyProxyReferences.remove(cacheKey) != bean) {
                return wrapIfNecessary(bean, beanName, cacheKey);
            }
        }
        return bean;
    }

这里,1处这个判断哈，就用到了前面我们说的那个field。那个field，只在两处用，一处就是调用getEarlyBeanReference，会往里面把当前bean的key放进去；另外一处，就是这里。

这里判断，如果field里不包含当前bean，就去调用wrapIfNecessary；如果包含（意味着，getEarlyBeanReference处理过了），就不调用了。

这里，说到底，就是保证了，wrapIfNecessary只被调用一次。

看吧，wrapIfNecessary也就这两处被调用了。

所以，我们可以得出结论，在aop这个beanPostProcessor中，有多处机会可以返回一个proxy对象，但是，最终，只要在其中一处处理了，其他处，根本不再继续处理。

另外，还有一点很重要，在这个aop beanPostProcessor中，传入了原始的bean，我们会去判断，是否要给它创建代理，如果要，就创建；如果不要则：

返回原始对象。

整个流程串起来

上面这个后置处理器看明白了，接下来，再看看创建bean的核心流程：

protected Object doCreateBean(final String beanName, final RootBeanDefinition mbd, final Object[] args) {
        // 1 
        BeanWrapper instanceWrapper = createBeanInstance(beanName, mbd, args);
        final Object bean = instanceWrapper.getWrappedInstance();

        if (earlySingletonExposure) {
            // 2
            addSingletonFactory(beanName, new ObjectFactory() {
                @Override
                public Object getObject() throws BeansException {
                    return getEarlyBeanReference(beanName, mbd, bean);
                }
            });
        }

        // 3 
        Object exposedObject = bean;
        // 4
        populateBean(beanName, mbd, instanceWrapper);

        // 5
        if (exposedObject != null) {
            exposedObject = initializeBean(beanName, exposedObject, mbd);
        }

        if (earlySingletonExposure) {
            // 6
            Object earlySingletonReference = getSingleton(beanName, false);

            if (earlySingletonReference != null) {
                // 7
                if (exposedObject == bean) {
                    exposedObject = earlySingletonReference;
                }
                else if (!this.allowRawInjectionDespiteWrapping && hasDependentBean(beanName)) {
                    // 8
                    ...
                }
            }
        }

        return exposedObject;
    }

上面流程中，做了部分删减。但基本创建一个bean，就这几步了。

• 1处，创建bean对象，此时，属性什么的全是null，可以理解为，只是new了，field还没设置
• 2处，添加到第三级缓存；加进去的，只是个factory，只有循环依赖的时候，才会发挥作用
• 3处，把原始bean，存到exposedObject
• 4处，填充属性；循环依赖情况下，A/B循环依赖。假设当前为A，那么此时填充A的属性的时候，会去：
  new B；
  填充B的field，发现field里有一个是A类型，然后就去getBean(“A”)，然后走到第三级缓存，拿到了A的ObjectFactory，然后调用ObjectFactory，然后调用AOP的后置处理器类：getEarlyBeanReference，拿到代理后的bean（假设此处切面满足，要创建代理）；
  经过上面的步骤后，B里面，field已经填充ok，其中，且填充的field是代理后的A，这里命名为proxy A。
  B 继续其他的后续处理。
  B处理完成后，被填充到当前的origin A（原始A）的field中
• 5处，对A进行后置处理，此时调用aop后置处理器的，postProcessAfterInitialization；前面我们说了，此时不会再去调用wrapIfNecessary，所以这里直接返回原始A，即 origin A
• 6处，去缓存里获取A，拿到的A，是proxy A
• 7处，我们梳理下：
  exposedObject：origin A
  bean：原始A
  earlySingletonReference： proxy A
  此时，下面这个条件是满足的，所以，exposedObject，最终被替换为proxy A：

  if (exposedObject == bean) {
   exposedObject = earlySingletonReference;
  }