网上关于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;
}

启动后,令人恐惧的红色字体在控制台出现了:

如果是构造参数注入的循环依赖,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;
}
}

还是讨厌的红色字体:

循环依赖可以关闭吗

可以,Spring提供了这个功能,我们需要这么写:

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

再次运行,就报错了:

需要注意的是,我们不能这么写:

        AnnotationConfigApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class);
applicationContext.setAllowCircularReferences(false);

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

可以循环依赖的神奇之处在哪

有很多小伙伴可能并不觉得可以循环依赖有多么神奇,那是因为不知道矛盾点在哪,接下来就来说说这个问题:

当beanA,beanB循环依赖:

  1. 创建beanA,发现依赖beanB;
  2. 创建beanB,发现依赖beanA;
  3. 创建beanA,发现依赖beanB;
  4. 创建beanB,发现依赖beanA。

    ...

    好了,死循环了。

循环依赖的矛盾点就在于要创建beanA,它需要beanB,而创建beanB,又需要beanA,然后两个bean都创建不出来。

如何简单的解决循环依赖

如果你曾经看过Spring解决循环依赖的博客,应该知道它其中有好几个Map,一个Map放的是最完整的对象,称为singletonObjects,一个Map放的是提前暴露出来的对象,称为earlySingletonObjects。

在这里,先要解释下这两个东西:

  • singletonObjects:单例池,其中存放的是经历了Spring完整生命周期的bean,这里面的bean的依赖都已经填充完毕了。
  • earlySingletonObjects:提前暴露出来的对象的map,其中存放的是刚刚创建出来的对象,没有经历Spring完整生命周期的bean,这里面的bean的依赖还未填充完毕。

我们可以这么做:

  1. 当我们创建完beanA,就把自己放到earlySingletonObjects,发现自己需要beanB,然后就去屁颠屁颠创建beanB;
  2. 当我们创建完beanB,就把自己放到earlySingletonObjects,发现自己需要beanA,然后就去屁颠屁颠创建beanA;
  3. 创建beanA前,先去earlySingletonObjects看一下,发现自己已经被创建出来了,把自己返回出去;
  4. beanB拿到了beanA,beanB创建完毕,把自己放入singletonObjects;
  5. 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的循环依赖只是在我们之上做了进一步的封装与改进。

帮助你更好的理解Spring循环依赖的更多相关文章

  1. spring 循环依赖的一次 理解

    前言: 在看spring 循环依赖的问题中,知道原理,网上一堆的资料有讲原理. 但今天在看代码过程中,又产生了疑问. 疑问点如下: // 疑问点: 先进行 dependon 判断String[] de ...

  2. Spring循环依赖的解决

    ## Spring循环依赖的解决 ### 什么是循环依赖 循环依赖,是依赖关系形成了一个圆环.比如:A对象有一个属性B,那么这时候我们称之为A依赖B,如果这时候B对象里面有一个属性A.那么这时候A和B ...

  3. 这个 Spring 循环依赖的坑,90% 以上的人都不知道

    1. 前言 这两天工作遇到了一个挺有意思的Spring循环依赖的问题,但是这个和以往遇到的循环依赖问题都不太一样,隐藏的相当隐蔽,网络上也很少看到有其他人遇到类似的问题.这里权且称他非典型Spring ...

  4. Springboot源码分析之Spring循环依赖揭秘

    摘要: 若你是一个有经验的程序员,那你在开发中必然碰到过这种现象:事务不生效.或许刚说到这,有的小伙伴就会大惊失色了.Spring不是解决了循环依赖问题吗,它是怎么又会发生循环依赖的呢?,接下来就让我 ...

  5. Spring — 循环依赖

    读完这篇文章你将会收获到 Spring 循环依赖可以分为哪两种 Spring 如何解决 setter 循环依赖 Spring 为何是三级缓存 , 二级不行 ? Spring 为啥不能解决构造器循环依赖 ...

  6. 3.1 spring5源码系列--循环依赖 之 手写代码模拟spring循环依赖

    本次博客的目标 1. 手写spring循环依赖的整个过程 2. spring怎么解决循环依赖 3. 为什么要二级缓存和三级缓存 4. spring有没有解决构造函数的循环依赖 5. spring有没有 ...

  7. spring循环依赖问题分析

    新搞了一个单点登录的项目,用的cas,要把源码的cas-webapp改造成适合我们业务场景的项目,于是新加了一些spring的配置文件. 但是在项目启动时报错了,错误日志如下: 一月 , :: 下午 ...

  8. Spring 循环依赖

    循环依赖就是循环引用,就是两个或多个Bean相互之间的持有对方,比如CircleA引用CircleB,CircleB引用CircleC,CircleC引用CircleA,则它们最终反映为一个环.此处不 ...

  9. Spring 循环依赖的三种方式(三级缓存解决Set循环依赖问题)

    本篇文章解决以下问题: [1] . Spring循环依赖指的是什么? [2] . Spring能解决哪种情况的循环依赖?不能解决哪种情况? [3] . Spring能解决的循环依赖原理(三级缓存) 一 ...

随机推荐

  1. react 使用的方法:

    react  使用方法: 第一步: 初始化react 项目 (1)安装node npm (2)npm install --global create-react-app (3)create-react ...

  2. JNI通过线程c回调java层的函数

    1.参看博客:http://www.jianshu.com/p/e576c7e1c403 Android JNI 篇 - JNI回调的三种方法(精华篇) 2.参看博客: JNI层线程回调Java函数关 ...

  3. @Inherited 注解的作用

    @Inherited 用于放在注解上,例如 @Inherited @Documented @Target(ElementType.TYPE) public @interface InheritedAn ...

  4. ORACLE误删除表数据或误更新/插入数据如何恢复

    工作中一不小心将本不该删除/更新/插入的数据进行删除/更新/插入了,这时候一定要尽快进行恢复. 工具/原料   PL/SQL 方法/步骤     首先新建一张测试表TEST,里面输入记录.由于删除/更 ...

  5. python之浅谈计算机基础

    目录 一.计算机基础之编程 什么是编程语言 什么是编程 为什么要编程 二.计算机组成原理 1. 计算机五大组成 CPU 存储器 输入设备 输出设备 2.计算机五大部分补充 CPU相关 应用程序启动流程 ...

  6. 什么是JDK的SPI机制

    什么是SPI和API Application Programming Interface (API)? The API is the description of classes/interfaces ...

  7. 生日聚会Party——这个线性dp有点嚣张

    题目描述 今天是hidadz小朋友的生日,她邀请了许多朋友来参加她的生日party. hidadz带着朋友们来到花园中,打算 坐成一排玩游戏.为了游戏不至于无聊,就座的方案应满足如下条件:对于任意连续 ...

  8. cin cout 的优化(神优化)外号:神读入

    在比赛里,经常出现数据集超大造成 cin TLE的情况.这时候大部分人(包括原来我也是)认为这是cin的效率不及scanf的错,甚至还上升到C语言和C++语言的执行效率层面的无聊争论.其实像上文所说, ...

  9. POJ1328贪心

    题意:如今我们位于沿海地区,需要安装大炮,使得火力可以覆盖整个区域.海岸线可以视为是无限长的直线.陆地位于海岸线的一侧,海洋位于另一侧.海洋里有若干个岛屿,每个小岛可以视为海洋中的一个点.我们需要在海 ...

  10. JSR 303 进行后台数据校验

    一.JSR 303 1.什么是 JSR 303? JSR 是 Java Specification Requests 的缩写,即 Java 规范提案. 存在各种各样的 JSR,简单的理解为 JSR 是 ...