Spring當中循環依賴不多有人講，今天一塊兒來學習！

時間  2020-12-02
標籤 java 面試 算法 spring 數據庫 設計模式 緩存 數據結構 多線程 併發 欄目 Spring 简体版
原文   原文鏈接

網上關於Spring循環依賴的博客太多了，有不少都分析的很深刻，寫的很用心，甚至還畫了時序圖、流程圖幫助讀者理解，我看了後，感受本身是懂了，可是閉上眼睛，總以爲尚未徹底理解，總以爲還有一兩個坎過不去，對我這種有點笨的人來講，真的好難。當時，我就在想，若是哪一天，我理解了Spring循環依賴，必定要用本身的方式寫篇博客，幫助你們更好的理解，等我理解後，一直在構思，到底怎麼應該寫，才能更通俗易懂，就在前幾天，我想通了，這麼寫應該更通俗易懂。在寫本篇博客以前，我翻閱了好多關於Spring循環依賴的博客，網上應該尚未像我這樣講解的，如今就讓咱們開始把。java

什麼是循環依賴

一言以蔽之：二者相互依賴。面試

在開發中，可能常常出現這種狀況，只是咱們平時並無注意到原來咱們寫的兩個類、甚至多個類相互依賴了，爲何注意不到呢？固然是由於沒有報錯，並且一點問題都木有，若是報錯了，或者產生了問題，咱們還會注意不到嗎？這一切都是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

file

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程