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

30次阅读

共计 10401 个字符，预计需要花费 27 分钟才能阅读完成。

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

什么是循环依赖

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

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

如下所示：

@Configuration
@ComponentScan
public class AppConfig {}
@Service
public class AuthorService {
    @Autowired
    BookService bookService;
}
@Service
public 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@63376bed
com.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 无奈解决：

@Service
public class AuthorService {
    BookService bookService;

    public AuthorService(BookService bookService) {this.bookService = bookService;}
}
@Service
public 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@61baa894
com.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@61baa894
com.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@49e4cb85
com.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

正文完
java
发表至： java
2020-07-19
 0
关于java:每天5分钟建造者模式
关于java:奇淫巧技CompletableFuture-异步多线程是真的优雅
Spring笔记03AOP
关于java:Java内存泄露问题分析