网上对于 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