分享Debug設置斷點學習分析堆棧信息，判斷錯誤方位的經歷

描述錯誤:服務啓動後無法讀取Nacos上對應的默認服務配置即${applicationname}.yaml配置

 

查找錯誤開始之初以爲是框架問題，或者引用依賴問題導致。因爲通過日誌發現僅有幾個新增的服務模塊啓動時無法讀取默認名稱的服務配置。

如下是正常情況，當服務啓動時會預先加載兩個共享的配置文件，然後(這裏是我的猜測，並沒有看Nacos很多文檔,但是後面堆棧調用分析證實了我的猜測)再加載每個應用的默認的配置文件。問題就出現在紅框的配置文件無法讀取/讀取不到

如下是出錯時的日誌文件，會發現無法讀取blade-tps-epcs.yaml文件，或者應該是沒有讀取到日誌文件導致的沒有該行日誌產生。所以找到該日誌打印的方法就可以判斷出問題所在了。

這種情況非常詭異，因爲該文件按理說是默認Nacos都會加載的。上面blade.yaml和blade-test.yaml是通過配置spring.cloud.nacos.config.shared-dataids設置的共享配置文件。

該問題找了一天，也找了該框架社區開發人員均無法找到答案。當晚上靜下心來的時候(其實是絕望了)，就想着那就通過打斷點一步一步走來找到錯誤方位。

斷電調試找出錯誤

下面言簡意賅的講，多爲圖

下面是堆棧信息

爲什麼我會在這裏打斷點是因爲上面的圖片中加載配置的日誌信息是從NacosPropertySourceBuilder的類中打印出來的日誌信息，所以打印該日誌的方法一定是在該類中，並且當看到下面方法中的log.info更加深了我的肯定。而且當看到if判斷時就大概明白是什麼情況了。應該是blade-tps-epcs.yaml讀取不到配置數據導致data爲null，跳過了該IF方法纔會出現該情況。索性斷電不能白打又爲了瞭解流程我又通過往上翻堆棧在名字爲NacosPropertySourceLocator中設置斷點(如何找到，通過分析堆棧中的名稱命名該類爲nacos配置源加載類，又或者堆棧不深可以一個一個點分析對應的參數)

來到讀取配置方法的上一級之後發現該配置先讀取的共享文件(loadSharedConfiguration)、再讀取擴展文件(loadExtConfiguration)、最後纔是默認的加載的應用配置(loadApplicationConfiguration),dataIdPrefix就是該配置文件的文件名前綴(後綴根據設置有.yaml和properties)。當然這段是擴展，因爲我也是第一次分析堆棧比較好奇。就往前看了一下流程，爲什麼先有之前預先設置的纔有默認的加載畢竟不想每次都點兩次通過，因爲bladex.yaml和bladex-test.yaml兩個是有數據的，我只想驗證最後bladex-tps-epcs.yaml是否是因爲未讀取到數據才導致的該問題。

 

經過上面的分析，我就將斷點打到了NacosPropertySourceLocator中的第61行。當斷點到時，再將斷點打到NacosPropertySourceBuilder的63行，來分析看爲什麼會不走if內的語句(其實已經猜到了是未讀取配置文件，因爲第61行不可能不走，就算沒走情況也是報異常纔對，到第63行沒進if就說明獲取到的data爲null，這時就有兩種情況一種爲命名錯誤(忽略的原因是我對了好幾遍)，一種爲配置文件讀取不到)。下圖爲印證我的猜想。

 

爲了更加確認，我在nacos上新建了命名空間和對應配置的文件。發現新增配置文件的均無法讀取到，那些共享的配置也讀取不到了。更加說明框架是沒有問題的，問題出在Nacos上(連續運行五個月未停過，按理說這種東西配置新增都是熱加載纔對，而且之前都是可以的，就沒有將懷疑往該工具上想)

 

最後重啓Nacos，配置文件可以讀取到！錯誤解決！但是還是建議不要使用Nacos1.1.3版本更換1.1.4以上的版本使用。 

(不知道是否是因爲連接服務很多的原因Nacos每天產生的日誌多達1G。重啓的時候看了一眼日誌文件竟然有77G的日誌嚇死人了。記得每天清理日誌不知道這也是1.1.3版本的問題不是)