关于java:Spring当中循环依赖很少有人讲今天一起来学习

网上对于Spring循环依赖的博客太多了，有很多都剖析的很深刻，写的很用心，甚至还画了时序图、流程图帮忙读者了解，我看了后，感觉本人是懂了，然而闭上眼睛，总感觉还没有齐全了解，总感觉还有一两个坎过不去，对我这种有点笨的人来说，真的好难。过后，我就在想，如果哪一天，我了解了Spring循环依赖，肯定要用本人的形式写篇博客，帮忙大家更好的了解，等我了解后，始终在构思，到底怎么应该写，能力更通俗易懂，就在前几天，我想通了，这么写应该更通俗易懂。在写本篇博客之前，我翻阅了好多对于Spring循环依赖的博客，网上应该还没有像我这样解说的，当初就让咱们开始把。

什么是循环依赖

一言以蔽之：两者相互依赖。

在开发中，可能经常出现这种状况，只是咱们平时并没有留神到原来咱们写的两个类、甚至多个类相互依赖了，为什么留神不到呢？当然是因为没有报错，而且一点问题都木有，如果报错了，或者产生了问题，咱们还会留神不到吗？这一切都是Spring的功绩，它在前面默默的为咱们解决了循环依赖的问题。

如下所示：

@Configuration@ComponentScanpublic class AppConfig {}

@Servicepublic class AuthorService {    @Autowired    BookService bookService;}

@Servicepublic class BookService {    @Autowired    AuthorService authorService;}

public class Main {    public static void main(String[] args) {        ApplicationContext annotationConfigApplicationContext = new AnnotationConfigApplicationContext(AppConfig.class);        BookService bookService = (BookService) annotationConfigApplicationContext.getBean("bookService");        System.out.println(bookService.authorService);        AuthorService authorService = (AuthorService) annotationConfigApplicationContext.getBean("authorService");        System.out.println(authorService.bookService);    }}

运行后果：

com.codebear.springcycle.AuthorService@63376bedcom.codebear.springcycle.BookService@4145bad8

能够看到BookService中须要AuthorService，AuthorService中须要BookService，相似于这样的就叫循环依赖，然而神奇的是居然一点问题没有。

当然有些小伙伴可能get不到它的神奇之处，至于它的神奇之处在哪里，咱们放到前面再说。

任何循环依赖，Spring都能解决吗

不行。

如果是原型 bean的循环依赖，Spring无奈解决：

@Service@Scope(BeanDefinition.SCOPE_PROTOTYPE)public class BookService {    @Autowired    AuthorService authorService;}@Service@Scope(BeanDefinition.SCOPE_PROTOTYPE)public class AuthorService {    @Autowired    BookService bookService;}

启动后，令人恐怖的红色字体在控制台呈现了：

image.png

如果是结构参数注入的循环依赖，Spring无奈解决：

@Servicepublic class AuthorService {    BookService bookService;    public AuthorService(BookService bookService) {        this.bookService = bookService;    }}

@Servicepublic class BookService {    AuthorService authorService;    public BookService(AuthorService authorService) {        this.authorService = authorService;    }}

还是厌恶的红色字体：

image.png

循环依赖能够敞开吗
能够，Spring提供了这个性能，咱们须要这么写：

public class Main {    public static void main(String[] args) {        AnnotationConfigApplicationContext applicationContext = new AnnotationConfigApplicationContext();        applicationContext.setAllowCircularReferences(false);        applicationContext.register(AppConfig.class);        applicationContext.refresh();    }}

再次运行，就报错了：

image.png

须要留神的是，咱们不能这么写：

AnnotationConfigApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class);

applicationContext.setAllowCircularReferences(false);

如果你这么写，程序执行完第一行代码，整个Spring容器曾经初始化实现了，你再设置不容许循环依赖，也于事无补了。

能够循环依赖的神奇之处在哪

有很多小伙伴可能并不感觉能够循环依赖有如许神奇，那是因为不晓得矛盾点在哪，接下来就来说说这个问题：
当beanA，beanB循环依赖：

创立beanA，发现依赖beanB；
创立beanB，发现依赖beanA；
创立beanA，发现依赖beanB；
创立beanB，发现依赖beanA。
...
好了，死循环了。
循环依赖的矛盾点就在于要创立beanA，它须要beanB，而创立beanB，又须要beanA，而后两个bean都创立不进去。

如何简略的解决循环依赖

如果你已经看过Spring解决循环依赖的博客，应该晓得它其中有好几个Map，一个Map放的是最残缺的对象，称为singletonObjects，一个Map放的是提前裸露进去的对象，称为earlySingletonObjects。

在这里，先要解释下这两个货色：

singletonObjects：单例池，其中寄存的是经验了Spring残缺生命周期的bean，这外面的bean的依赖都曾经填充结束了。
earlySingletonObjects：提前裸露进去的对象的map，其中寄存的是刚刚创立进去的对象，没有经验Spring残缺生命周期的bean，这外面的bean的依赖还未填充结束。
咱们能够这么做：

当咱们创立完beanA，就把本人放到earlySingletonObjects，发现自己须要beanB，而后就去屁颠屁颠创立beanB；
当咱们创立完beanB，就把本人放到earlySingletonObjects，发现自己须要beanA，而后就去屁颠屁颠创立beanA；
创立beanA前，先去earlySingletonObjects看一下，发现自己曾经被创立进去了，把本人返回进来；
beanB拿到了beanA，beanB创立结束，把本人放入singletonObjects；
beanA能够去singletonObjects拿到beanB了，beanA也创立结束，把本人放到singletonObjects。
整个过程完结。
上面让咱们来实现这个性能：
首先，自定义一个注解，字段上打上这个注解的，阐明须要被Autowired：

@Retention(RetentionPolicy.RUNTIME)public @interface CodeBearAutowired {}

再创立两个循环依赖的类：

public class OrderService {    @CodeBearAutowired    public UserService userService;}public class UserService {    @CodeBearAutowired    public OrderService orderService;}

而后就是外围，创建对象，填充属性，并解决Spring循环依赖的问题：

public class Cycle {    // 单例池，外面放的是残缺的bean，已实现填充属性    private final Map<String, Object> singletonObjects = new ConcurrentHashMap<>();    // 寄存的是提前裸露进去的bean，没有经验过spring残缺的生命周期，没有填充属性    private final Map<String, Object> earlySingletonObjects = new HashMap<>();    // 在Spring中，这个map寄存的是beanNam和beanDefinition的映射关系    static Map<String, Class<?>> map = new HashMap<>();    static {        map.put("orderService", OrderService.class);        map.put("userService", UserService.class);    }    // 如果先调用init办法，就是预加载，如果间接调用getBean就是懒加载，两者的循环依赖问题都解决了    public void init() {        for (Map.Entry<String, Class<?>> stringClassEntry : map.entrySet()) {            createBean(stringClassEntry.getKey());        }    }    public Object getBean(String beanName) {        // 尝试从singletonObjects中取，        Object singletonObject = this.singletonObjects.get(beanName);        if (singletonObject != null) {            return singletonObject;        }        // 尝试从earlySingletonObjects取        singletonObject = this.earlySingletonObjects.get(beanName);        if (singletonObject != null) {            return singletonObject;        }        return createBean(beanName);    }    private Object createBean(String beanName) {        Object singletonObject;        try {            // 创建对象            singletonObject = map.get(beanName).getConstructor().newInstance();            // 把没有实现填充属性的半成品 bean 放入earlySingletonObjects            earlySingletonObjects.put(beanName, singletonObject);            // 填充属性            populateBean(singletonObject);            // bean创立胜利，放入singletonObjects            this.singletonObjects.put(beanName, singletonObject);            return singletonObject;        } catch (Exception ignore) {        }        return null;    }    private void populateBean(Object object) {        Field[] fields = object.getClass().getDeclaredFields();        for (Field field : fields) {            if (field.getAnnotation(CodeBearAutowired.class) != null) {                Object value = getBean(field.getName());                try {                    field.setAccessible(true);                    field.set(object, value);                } catch (IllegalAccessException ignored) {                }            }        }    }}

预加载调用：

public class Main {    public static void main(String[] args) {        Cycle cycle = new Cycle();        cycle.init();        UserService userService = (UserService) cycle.getBean("userService");        OrderService orderService = (OrderService) cycle.getBean("orderService");        System.out.println(userService.orderService);        System.out.println(orderService.userService);    }}

运行后果：

com.codebear.cycleeasy.OrderService@61baa894com.codebear.cycleeasy.UserService@b065c63

懒加载调用：

public class Main {    public static void main(String[] args) {        Cycle cycle = new Cycle();        UserService userService = (UserService) cycle.getBean("userService");        OrderService orderService = (OrderService) cycle.getBean("orderService");        System.out.println(userService.orderService);        System.out.println(orderService.userService);    }}

运行后果：

com.codebear.cycleeasy.OrderService@61baa894com.codebear.cycleeasy.UserService@b065c63

为什么无奈解决原型、构造方法注入的循环依赖

在下面，咱们本人手写了解决循环依赖的代码，能够看到，外围是利用一个map，来解决这个问题的，这个map就相当于缓存。

为什么能够这么做，因为咱们的bean是单例的，而且是字段注入（setter注入）的，单例意味着只须要创立一次对象，前面就能够从缓存中取出来，字段注入，意味着咱们无需调用构造方法进行注入。

如果是原型bean，那么就意味着每次都要去创建对象，无奈利用缓存；
如果是构造方法注入，那么就意味着须要调用构造方法注入，也无奈利用缓存。

须要aop怎么办？

咱们下面的计划看起来很美妙，然而还有一个问题，如果咱们的bean创立进去，还要做一点加工，怎么办？兴许，你没有了解这句话的意思，再说的明确点，如果beanA和【beanB的代理对象】循环依赖，或者【beanA的代理对象】和beanB循环依赖，再或者【beanA的代理对象】和【beanB的代理对象】循环依赖，怎么办？

这里说的创立代理对象仅仅是“加工”的其中一种可能。

遇到这种状况，咱们总不能把创立完的对象间接扔到缓存把？咱们这么做的话，如果【beanA的代理对象】和【beanB的代理对象】循环依赖，咱们最终获取的beanA中的beanB还是beanB，并非是beanB的代理对象。

聪慧的你，肯定在想，这还不简略吗：
咱们创立完对象后，判断这个对象是否须要代理，如果须要代理，创立代理对象，而后把代理对象放到earlySingletonObjects不就OJ8K了？
就像这样：

private Object createBean(String beanName) {

Object singletonObject;try {    // 创建对象    singletonObject = map.get(beanName).getConstructor().newInstance();    // 创立bean的代理对象    /**     * if( 须要代理){     *     singletonObject=创立代理对象;     *     * }     */    // 把没有实现填充属性的半成品 bean 放入earlySingletonObjects    earlySingletonObjects.put(beanName, singletonObject);    // 填充属性    populateBean(singletonObject);    // bean创立胜利，放入singletonObjects    this.singletonObjects.put(beanName, singletonObject);    return singletonObject;} catch (Exception ignore) {}return null;

}

这的确能够，然而，这违反了Spring的初衷，Spring的初衷是心愿在bean生命周期的最初几步才去aop，如果像下面说的这么做，就意味着一旦创立完对象，Spring就会去aop了，这就违反了Spring的初衷，所以Spring并没有这么做。

然而如果真的呈现了aop bean循环依赖，就没方法了，只能先去aop，然而如果没有呈现循环依赖，Spring并不心愿在这里就进行aop，所以Spring引入了Map<String, ObjectFactory<?>>，ObjectFactory是一个函数式接口，能够了解为工厂办法，当创立完对象后，把【取得这个对象的工厂办法】放入这个map，等真的产生循环依赖，就去执行这个【取得这个对象的工厂办法】，获取加工实现的对象。

上面间接放出代码：

public class Cycle {    // 单例池，外面放的是残缺的bean，已实现填充属性    private final Map<String, Object> singletonObjects = new ConcurrentHashMap<>();    // 寄存的是 加工bean的工厂办法    private final Map<String, ObjectFactory<?>> singletonFactories = new HashMap<>();    // 寄存的是提前裸露进去的bean，没有经验过spring残缺的生命周期，没有填充属性    private final Map<String, Object> earlySingletonObjects = new HashMap<>();    private final Set<String> singletonsCurrentlyInCreation = new HashSet<>();    static Map<String, Class<?>> map = new HashMap<>();    static {        map.put("orderService", OrderService.class);        map.put("userService", UserService.class);    }    public void init() {        for (Map.Entry<String, Class<?>> stringClassEntry : map.entrySet()) {            createBean(stringClassEntry.getKey());        }    }    private Object createBean(String beanName) {        Object instance = null;        try {            instance = map.get(beanName).getConstructor().newInstance();        } catch (Exception ex) {        }        Object finalInstance = instance;        this.singletonFactories.put(beanName, () -> {            // 创立代理对象            return finalInstance;        });        populateBean(instance);        this.singletonObjects.put(beanName, instance);        return instance;    }    public Object getBean(String beanName) {        // 尝试从singletonObjects中取，        Object singletonObject = this.singletonObjects.get(beanName);        if (singletonObject != null) {            return singletonObject;        }        // 尝试从earlySingletonObjects取        singletonObject = this.earlySingletonObjects.get(beanName);        if (singletonObject != null) {            return singletonObject;        }        // 尝试从singletonFactories取出工厂办法        ObjectFactory<?> objectFactory = this.singletonFactories.get(beanName);        if (objectFactory != null) {            singletonObject = objectFactory.getObject();            this.earlySingletonObjects.put(beanName, singletonObject);            return singletonObject;        }        return createBean(beanName);    }    private void populateBean(Object object) {        Field[] fields = object.getClass().getDeclaredFields();        for (Field field : fields) {            if (field.getAnnotation(CodeBearAutowired.class) != null) {                Object value = getBean(field.getName());                try {                    field.setAccessible(true);                    field.set(object, value);                } catch (IllegalAccessException ignored) {                }            }        }    }}

调用办法：

 public static void main(String[] args) {        Cycle cycle = new Cycle();        cycle.init();        System.out.println(((UserService) cycle.getBean("userService")).orderService);        System.out.println(((OrderService) cycle.getBean("orderService")).userService);    }

运行后果：

com.codebear.cycles.OrderService@49e4cb85com.codebear.cycles.UserService@2133c8f8

二级缓存能不能解决循环依赖，三级循环到底有什么用？

我的观点可能和网上的支流观点有很大的出入，至于我的观点是对是错，请各位自行判断。

二级缓存能够解决循环依赖，哪怕aop bean循环依赖，下面咱们曾经提到了，咱们能够创立完对象，间接创立代理对象，把代理对象放入二级缓存，这样咱们从二级缓存取得的肯定是aop bean，并非是bean自身。

三级缓存有什么用？网上的支流观点是为了解决循环依赖，还有就是为了效率，为了解决循环依赖，咱们下面曾经探讨过了，我的观点是二级缓存曾经能够解决循环依赖了，上面就让咱们想想，和效率是否有关系？

我的观点是没有关系，理由如下：
咱们把【取得对象的工厂办法】放入了map

• 如果没有循环依赖，这个map基本没有用到，和效率没有关系；
• 如果是一般bean循环依赖，三级缓存间接返回了bean，和效率还是没有关系；
• 如果是aop bean循环依赖，如果没有三级缓存，间接创立代理对象，放入二级缓存，如果有三级缓存，还是须要创立代理对象，只是两者的机会不同，和效率还是没有关系。

有了这篇博客的根底，当你再看其余对于Spring循环依赖的博客，应该会轻松的多，因为咱们毕竟本人解决了循环依赖，Spring的循环依赖只是在咱们之上做了进一步的封装与改良。

最初

私信回复 材料 支付一线大厂Java面试题总结+阿里巴巴泰山手册+各知识点学习思维导+一份300页pdf文档的Java外围知识点总结！

这些材料的内容都是面试时面试官必问的知识点，篇章包含了很多知识点，其中包含了有基础知识、Java汇合、JVM、多线程并发、spring原理、微服务、Netty 与RPC 、Kafka、日记、设计模式、Java算法、数据库、Zookeeper、分布式缓存、数据结构等等。

作者： CodeBear
原文：https://0x9.me/EL7No