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

程式零世界發表於2020-07-19

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

相關文章