對dubbo啟動時檢查check屬性的一些個人理解

2021-08-12 00:25:36 字數 2428 閱讀 8978

對於dubbo框架,對服務引用啟動時檢查的check配置,官方文件的描述是這樣的:

dubbo 缺省會在啟動時檢查依賴的服務是否可用,不可用時會丟擲異常,阻止 spring 初始化完成,以便上線時,能及早發現問題,預設check="true"

可以通過check="false"關閉檢查,比如,測試時,有些服務不關心,或者出現了迴圈依賴,必須有一方先啟動。

另外,如果你的 spring 容器是懶載入的,或者通過 api 程式設計延遲引用服務,請關閉 check,否則服務臨時不可用時,會丟擲異常,拿到 null 引用,如果check="false",總是會返回引用,當服務恢復時,能自動連上。

嗯,總結一下,可以解決迴圈依賴問題,如果配置為true,則開始載入spring容器時會拋異常出來,如果容器懶載入,則需要關閉check以保證應用啟動時對可能被懶載入引用的dubbo服務bean不要被檢查。

這些訊息很容易把部分開發者的理解引向:dubbo的check如果為true則永遠在容器初始化時檢查,而懶載入所載入的bean注入的多是容器啟動時還未初始化完成的dubbo服務,所以為了讓懶載入的bean在載入時能夠注入已經初始化完成的服務,check需設定成false來避開容器初始化時的檢查,以防bean還未載入,在應用啟動時就先報錯了。而如果非懶載入的bean注入了確定在當前應用啟動後才會初始化的服務,即便引用此服務時配置了check=false,也僅僅是在應用啟動時不會丟擲異常,在使用時依然無法連上服務,因為並沒有使用懶載入為其延遲出初始化的時間。

這也會產生乙個理解誤區:想要引用在當前應用之後初始化的服務,則需要使用懶載入策略延遲出服務初始化的時間,而check=false這個配置屬性則只是為了配合懶載入避過容器初始化時的檢查報錯而已。

我們假定乙個應用場景,a應用與b應用的beana與beanb同時注入了servicec,但servicec需要等a應用與b應用都啟動後才可以去初始化,beana為lazy-init模式,beanb則是立即載入,那這個時候beana與beanb該怎麼初始化呢?

這個時候一定會引發思考:嘿,這還不簡單,設定check為false解決迴圈依賴,beana是懶載入的,check為true的話應用a啟動容器載入時就會檢查,但這個時候servicec一定是沒有初始化好的,如果報錯的話,那到了beana載入的時候,servicec就注不進去了吧,我把它設定成false,這樣等beana初始化的時候就可以讓已經初始化好了的servicec正常載入了。beanb是立即載入的,如果配置check=false,雖然應用啟動不會報錯了,但容器上來就注入沒初始化好的servicec豈不是還注不進去?那這個check=false對於beanb來說有什麼用呢,check=false只是為了和懶載入一起解決迴圈依賴存在的東西麼?beanb又該如何正常載入服務呢?

起碼比較笨的我當時是這樣想的。於是我進行了測試:

實際在我測試時,對於懶載入的bean所注入的服務引用,無論check配置值為true或為false,都不會影響spring容器的載入。check配置為false對於懶載入及立即載入的bean並沒有差異,都可以在服務初始化完成後繼續連上。差異產生於check為true時。

那麼檢查是在**進行的?這步操作實際是根據bean的初始化時機進行的,對於非懶載入的bean,bean初始化的時候等同於容器初始化的時候,如有未初始化完成的服務,check=true則會阻止容器的啟動,讓應用在啟動時就報錯,讓開發者在應用啟動時就知道:我有未初始化好的服務引用正在注入,使用時會出現問題,從而及時加以調整。

對於懶載入的bean而言,bean初始化的時候並非是容器初始化的時候,這種條件下check=true會導致在使用這個bean時才執行檢查,如果這個時候bean所注入的服務引用還未初始化完成,則檢查機制會丟擲異常,並注入null引用,這時容器已經載入完成,應用也已啟動,除非應用重啟,否則使用時不會再次連上服務,null引用會導致nullpoint異常的產生,為了避免這種情況,對於懶載入的bean,應將check設定為false,並非是要避免應用啟動時的異常,而是要避免bean的異常初始化導致的錯誤bean產生。這是配置check=false對於懶載入bean所注入服務引用的必要性真正所在。

再次總結,根據官方文件的描述,理解不到位的開發者難免會將迴圈依賴問題與懶載入和check=false的配置連起來思考,這樣難免會陷入死結,最後理解為配置check=false來幫助懶載入解決迴圈依賴的問題。

首先check的配置在立即載入的環境下可以來檢查是否有服務未初始化,設定為true,如容器初始化時有未初始化的服務被注入可丟擲異常讓應用初始化無法完成,設定為false則可以不影響應用的啟動,後續服務初始化完成後依然可以正常連上。也就是說check=false的配置本身可以解決迴圈依賴的問題。

懶載入是一種bean載入策略,並非和dubbo有直接的聯絡,也並非直接為了解決服務的迴圈依賴而存在,這種載入方式主要作用在於節約資源,提公升效能,亦可以解決迴圈依賴的問題,只是如有載入了dubbo服務引用的bean要應用懶載入策略,需要check設為false來防止出現未完全裝配的bean影響應用的正常執行。

開啟dubbo之旅 啟動時檢查

正經學徒,佛系記錄,不搞事情 基於上文 官方解釋 dubbo 缺省會在啟動時檢查依賴的服務是否可用,不可用時會丟擲異常,阻止 spring 初始化完成,以便上線時,能及早發現問題。啟動時檢查分為兩類 另外乙個值得注意的地方是 如果使用的是啟動時檢查,一開始專案啟動報錯,後面服務恢復的時候,系統還是反...

啟動時檢查

dubbo 缺省會在啟動時檢查依賴的服務是否可用,不可用時會丟擲異常,阻止 spring 初始化完成,以便上線時,能及早發現問題,預設check true 可以通過check false 關閉檢查,比如,測試時,有些服務不關心,或者出現了迴圈依賴,必須有一方先啟動。另外,如果你的 spring 容器...

servlet啟動時載入

servlet預設是在第一次訪問的時候建立的物件。servlet啟動時載入,就是讓 tomcat 伺服器啟動的時候建立servlet的物件 servlet物件是第一次被訪問的時候會被建立的,init方法就會執行。假設在init方法中做了一些比較耗時的操作 比如 載入了一些配置檔案並且解析可能需要花費...