Spring當中迴圈依賴很少有人講，今天一起來學習！

来源:https://www.cnblogs.com/MonsterJ/archive/2020/07/19/13341084.html
-Advertisement-
Play Games

網上關於Spring迴圈依賴的博客太多了，有很多都分析的很深入，寫的很用心，甚至還畫了時序圖、流程圖幫助讀者理解，我看了後，感覺自己是懂了，但是閉上眼睛，總覺得還沒有完全理解，總覺得還有一兩個坎過不去，對我這種有點笨的人來說，真的好難。當時，我就在想，如果哪一天，我理解了Spring迴圈依賴，一定要 ...


網上關於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

file


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • 對 mvvm 架構的理解
    使用Mvvm 架構目的 一 ：為了使開發快速，界面設計和界面交互可以同時進行。 二： 為了方便測試，交互功能的測試可以完全脫離wpf控制項。 Wpf mvvm 架構如下： 在wpf 中 ,V界面數據更改後，直接修改M,那樣VM 就可以直接從M 中獲取到最新值。當 V界面觸發事件如（保存，修改等），VM ...
  • 面向過程與面向對象
    《Java編程思想》是一本好書，但同時也是晦澀難懂，其一是知識本身的難度，其二這本書是翻譯過來的，而且是直譯。我也是嘗試了好多次才又拿起了這本書啃，沒想到今天突然感覺發現了寶藏。 接下來我就羅列一下今晚的收穫吧： Sun對Java的設計目標：為程式員減少複雜性。（雖然Sun被收購了，還是謝謝Sun， ...
  • 解決IDEA/pycharm提示Untrusted Server's certificate 證書不可用（ Server's certificate is not trusted )
    解決IDEA/pycharm提示Untrusted Server's certificate 證書不可用（ Server's certificate is not trusted ) ...
  • Go Protobuf 參考教程
    官方參考文檔： go install google.golang.org/protobuf/cmd/protoc-gen-go 安裝protobuf go 插件 https://developers.google.com/protocol-buffers/docs/reference/go-gene ...
  • 23種設計模式之代理模式（靜態代理）
    一：為什麼學習代理模式： 代理模式實際上是SpringAOP的底層！ 【SpringAOP 和 SpringMVC （面試必問）】 二：代理模式（基本概念）： 基本概念：代理模式的核心作用就是通過代理，控制對對象的訪問。這跟實際中是一樣的，例如說我們租房子時遇到的中介，這就是一個代理，比如有人要找中 ...
  • Swoole 中使用 Atomic 實現進程間無鎖計數器
    使用示例： $atomic = new Swoole\Atomic(); $serv = new Swoole\Server('127.0.0.1', '9501'); $serv->set([ 'worker_num' => 1, 'log_file' => '/dev/null' ]); // ...
  • 架構師都該懂的 CAP 定理
    面對可能出現的網路延遲，不可預估的請求流量等情況，設計一個分散式系統，我們通常圍繞系統高可用，數據一致性的目標去規劃和實現，想要完全實現這個目標，卻並非易事。由此，分散式系統領域誕生了一個基本定理，即 CAP 定理，用於指導分散式系統的設計，從系統高可用，數據一致性，網路容錯三個角度將分散式系統的特 ...
  • python迭代器、可迭代對象
    在已知的可直接作用於for迴圈的數據類型有以下幾種 第一類 list tuple dict set str 第二類 generator 可直接作用於for迴圈的對象統稱為可迭代對象：Iterable 可利用 isinstance() 判斷一個對象是否是 Iterable 對象 from collec ...
一周排行
    -Advertisement-
    Play Games
  • 移動開發（一）：使用.NET MAUI開發第一個安卓APP
    移動開發（一）：使用.NET MAUI開發第一個安卓APP 對於工作多年的C#程式員來說，近來想嘗試開發一款安卓APP，考慮了很久最終選擇使用.NET MAUI這個微軟官方的框架來嘗試體驗開發安卓APP，畢竟是使用Visual Studio開發工具，使用起來也比較的順手，結合微軟官方的教程進行了安卓 ...
  • wpf ToggleButton選中效果和一個登錄界面
    前言 QuestPDF 是一個開源 .NET 庫，用於生成 PDF 文檔。使用了C# Fluent API方式可簡化開發、減少錯誤並提高工作效率。利用它可以輕鬆生成 PDF 報告、發票、導出文件等。 項目介紹 QuestPDF 是一個革命性的開源 .NET 庫，它徹底改變了我們生成 PDF 文檔的方 ...
  • 彈幕樹洞項目功能新增篇
    項目地址 項目後端地址： https://github.com/ZyPLJ/ZYTteeHole 項目前端頁面地址： ZyPLJ/TreeHoleVue (github.com) https://github.com/ZyPLJ/TreeHoleVue 目前項目測試訪問地址： http://tree ...
  • 第27篇 sqlserver2022詳細安裝步驟
    話不多說，直接開乾 一.下載 1.官方鏈接下載： https://www.microsoft.com/zh-cn/sql-server/sql-server-downloads 2.在下載目錄中找到下麵這個小的安裝包 SQL2022-SSEI-Dev.exe，運行開始下載SQL server； 二. ...
  • .NET 開源高性能 MQTT 類庫
    前言 隨著物聯網（IoT）技術的迅猛發展，MQTT（消息隊列遙測傳輸）協議憑藉其輕量級和高效性，已成為眾多物聯網應用的首選通信標準。 MQTTnet 作為一個高性能的 .NET 開源庫，為 .NET 平臺上的 MQTT 客戶端與伺服器開發提供了強大的支持。 本文將全面介紹 MQTTnet 的核心功能 ...
  • Serilog文檔翻譯系列（六） - 可用的接收器、增強器、格式化輸出
    Serilog支持多種接收器用於日誌存儲，增強器用於添加屬性，LogContext管理動態屬性，支持多種輸出格式包括純文本、JSON及ExpressionTemplate。還提供了自定義格式化選項，適用於不同需求。 ...
  • 警惕 Visual Studio 屬性求值副作用導致邏輯不符合預期
    目錄簡介獲取 HTML 文檔解析 HTML 文檔測試參考文章 簡介 動態內容網站使用 JavaScript 腳本動態檢索和渲染數據，爬取信息時需要模擬瀏覽器行為，否則獲取到的源碼基本是空的。 本文使用的爬取步驟如下： 使用 Selenium 獲取渲染後的 HTML 文檔 使用 HtmlAgility ...
  • [使用目前最新版]HybridCLR6.9.0+YooAsset2.2.4實現純C# Unity熱更新方案 (一)
    1.前言 什麼是熱更新 游戲或者軟體更新時，無需重新下載客戶端進行安裝，而是在應用程式啟動的情況下，在內部進行資源或者代碼更新 Unity目前常用熱更新解決方案 HybridCLR，Xlua，ILRuntime等 Unity目前常用資源管理解決方案 AssetBundles，Addressable， ...
  • 在 ASP.NET Core Web API 中使用操作篩選器統一處理通用操作
    本文章主要是在C# ASP.NET Core Web API框架實現向手機發送驗證碼簡訊功能。這裡我選擇是一個互億無線簡訊驗證碼平臺，其實像阿裡雲，騰訊雲上面也可以。 首先我們先去 互億無線 https://www.ihuyi.com/api/sms.html 去註冊一個賬號 註冊完成賬號後，它會送 ...
  • 第28篇 如何.net中實現高效可靠數據同步api
    通過以下方式可以高效，並保證數據同步的可靠性 1.API設計 使用RESTful設計，確保API端點明確，並使用適當的HTTP方法（如POST用於創建，PUT用於更新）。 設計清晰的請求和響應模型，以確保客戶端能夠理解預期格式。 2.數據驗證 在伺服器端進行嚴格的數據驗證，確保接收到的數據符合預期格 ...
所有分類