欧博app下载:Spring当中循环依赖很少有人讲,今天一起来学习!

admin 4个月前 (07-23) 科技 60 1

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

,

欧博官网

欢迎进入欧博官网(Allbet Game):www.aLLbetgame.us,欧博官网是欧博集团的官方网站。欧博官网开放Allbet注册、Allbe代理、Allbet电脑客户端、Allbet手机版下载等业务。

Allbet欧博官网声明:该文看法仅代表作者自己,与本平台无关。转载请注明:欧博app下载:Spring当中循环依赖很少有人讲,今天一起来学习!

网友评论

  • (*)

最新评论

  • 环球UG注册 2020-07-23 02:10:41 回复

    欧博电脑版欢迎进入欧博电脑版(Allbet Game):www.aLLbetgame.us,欧博官网是欧博集团的官方网站。欧博官网开放Allbet注册、Allbe代理、Allbet电脑客户端、Allbet手机版下载等业务。跟童话一样啊

    1

站点信息

  • 文章总数:716
  • 页面总数:0
  • 分类总数:8
  • 标签总数:1286
  • 评论总数:350
  • 浏览总数:21364