浅谈循环依赖

说明

• 循环依赖是一个大家讨论很多的话题，它更多是一个工程上的问题而不是技术问题，我们需要首先有一定的认知：
  
  
  
  • 如同两个人相互帮忙，两个类之间你调用我的，我调用你的是很正常也很自然的需求模型。
    
  • 单一依赖确实有好处，改动一个最顶层类时不需要在意对底部类的影响，但是从本来就自然的模型非要理顺的话就需要额外付出代价，例如额外的拆分类。
    
  
  
• 循环依赖可以分这几种：
  
  
  
  • 从小的来说是类之间的相互引用。
    
  • 再大一点的来说是同一个项目下不同模块之间的引用。
    
  • 再再大一点的来说涉及到微服务或不同类库之间引用。
    
  对于微服务级别或是模块级别的引用来说解决循环依赖是有必要的，因为这可能牵扯到不同人分工协作的问题，而类之间尤其是同一模块下的类之间是否禁止循环依赖实际上是有争议的，本文只讨论同一模块下的类之间的循环引用。
  
  
• 一些解决循环依赖的方法类似@Lazy、getBean等实际上解决的不是循环依赖，而是解决的springboot启动时的循环依赖检测，但本质上它们还是相互引用，所以这里不讨论这些方法，只讨论拆分类的方法。
  
• 个人目前比较认同的是同一个人写的同一个模块下的功能是可以循环依赖的，增加额外的拆分类反而会增加复杂度及影响效率，但springboot 2.6版本之后默认禁止了循环依赖，所以个人也在思考，如果想要拆分的化要怎么拆分，目前总结了如下两种不同类型的循环引用拆分示例。
  

示例

情形一

• 最常见的老师、学生这种或是主表、子表相互关联的：
  1. @Component
  2. public class Teacher {
  3.     @Autowired
  4.     private Student student;
  5.    
  6.     public void method() {
  7.         //获取某教师下学生类别
  8.         List<String> students = student.getStudentsByTeacher("xxx");
  9.         System.out.println(students);
  10.     }
  11. }

  复制代码
  1. @Component
  2. public class Student {
  3.     @Autowired
  4.     private Teacher teacher;
  5.    
  6.     public void method() {
  7.         //获取学生归属的教师
  8.         String teacherStr = teacher.getTeacherByStudent("xxx");
  9.         System.out.println(teacherStr);
  10.     }
  11. }

  复制代码
• 这种拆分比较简单，类似数据库多对多的中间表，我们也创建一个中间类，然后Teacher和Student类不要依赖彼此，直接抽取方法到中间类中或是都引用中间类：
  1. @Component
  2. public class TeacherStudent {
  3.     @Autowired
  4.     private Teacher teacher;
  5.     @Autowired
  6.     private Student student;
  7.    
  8.      public void method1() {
  9.         //获取某教师下学生类别
  10.         List<String> students = student.getStudentsByTeacher("xxx");
  11.         System.out.println(students);
  12.     }
  13.    
  14.     public void method2() {
  15.         //获取学生归属的教师
  16.         String teacherStr = teacher.getTeacherByStudent("xxx");
  17.         System.out.println(teacherStr);
  18.     }
  19. }

  复制代码

情形二

• 另一种常用的场景是引用第三方类库A，然后在配置类B中用@Bean来实例化，而类A是通过读取数据库中的配置（通过类C）来组装参数，而当数据库配置变更时（类C中更新），由于参数变化同时也要重置类A实例，我们在集成微信、钉钉等SDK时会经常遇到此情况，如果直接按照此逻辑写的话，就是下述的代码：
  1. //B本身是个配置类
  2. @Configuration
  3. class B {
  4.     @Autowired
  5.     private C c;
  7.     @Bean
  8.     public A init(){
  9.         A a = new A();
  10.         //引用c的数据库中数据来组装成A实例
  11.         a.setProp(c.getProp());
  12.         return a;
  13.     }
  14. }

  复制代码
  1. @Component
  2. class C {
  3.     @Autowired
  4.     private A a;
  6.     public void update(){
  7.         //修改数据库相关后，又来重置A实例
  8.         a.reset();
  9.     }
  10. }

  复制代码
• 此情况下最主要的耦合就是类A需要类C的数据来作为配置项，所以把这个耦合独立出来，而类B中去除类C的引用，仅仅是生成类A的bean：
  1. //用@PostConstruct
  2. @Component
  3. public class D {
  4.     @Autowired
  5.     private A a;
  6.     @Autowired
  7.     private C c;
  8.    
  9.     @PostConstruct
  10.     public void init(){
  11.         a.setProp(c.getProp());
  12.     }
  13. }
  14. //或是@Autowired注解到方法上
  15. @Component
  16. public class D {
  17.     @Autowired
  18.     public void init(A a, C c) {
  19.         a.setProp(c.getProp());
  20.     }
  21. }

  复制代码
• 虽然从需求上类A依赖类C，但本质上类A并不需要依赖任何类，和第一种情况不同的是类A是一个第三方的类库，我们无法修改其引用及方法，而其本身并不是个bean，需要我们额外去操作。
  

结果

• 上述的情况都是额外增加一个拆分类来处理，这样无形中增加了代码量，尤其是第一种情形太常见了，除非是项目初始时就规定好禁止service层互相调用，而是单独再划分一层来处理（类似阿里的manager层），否则的话个人宁愿用@Lazy来解决掉循环依赖的报错。
  
• 解决循环依赖上述同模块内的相对简单些，只是增加代码量而已，当涉及到模块或微服务时，则完全不一样，要考虑业务逻辑及架构等一系列问题，感觉很是麻烦。
  
• 以上只是个人见解，有更好的观点可发到评论区一起讨论下。
  

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！