application.properties獲取屬性值引起的思考

最近在寫一個測試類的時候，發現我寫下劃線的時候，對應的屬性值是加載不出來的，寫中劃線的時候，對應的屬性值能夠加載出來。當時沒有管太多。後來測試類寫完了以後，還有點時間，就想把application.properties加載和解析的原理看一下。模糊中記得好像能不能用下劃線，應該跟Spring Boot的策略有關,後來找到是org.springframework.boot.bind.RelaxedNames這個類。

找到這個類以後，確實能夠看到鬆散綁定相關的邏輯。

既然有這個類，我就用這個類，反向查找，找到了一開始加載的地方，而後再來看看他默認的配置。

根據org.springframework.boot.bind.RelaxedNames找到最開始的源頭：

而後咱們在看一下Spring Boot的啓動過程：

咱們從run方法一步一步跟進去，能夠看到這一點，

而後咱們看一下ApplicationListener有哪些實現類：

其中一個就是ConfigFileApplicaitonListener類，這個類就是加載配置文件的。

正好這個就和上面的那個對應了，監聽事件開始調用而後加載配置文件。

這是整個調用過程，而後我打斷點跟了跟整個過程。

仍是感受不對勁，這個好像並無說不能用下劃線，我把項目裏面用中劃線的改爲了下劃線，mvn clean install以後，從新運行，發現是能夠的。見鬼了，試了幾回，都是正常的。忽然發現一開始出現的那個問題我復現不了了，彷彿歷來不存在通常。不過至少我也有複習到，並且加深了對策略的印象。

知道答案以後，我挺開心的，跟朋友分享完這個以後，把問題爲了一個大佬，大佬跟我說了4句，

SpringBoot 配置文件須要劃重點，配置中 key不能帶下劃線,value能夠。好比經典的mybatis開啓駝峯法命名轉換，能夠經過mybatis.configuration.map-underscore-to-camel-case=true進行駝峯命名法和下劃線風格轉換。 原理你能夠看一下springboot源碼，application.properties加載和解析的部分。

org.springframework.boot.env.PropertiesPropertySourceLoader

org.springframework.boot.context.config.ConfigFileApplicationListener
建議看一下官方文檔，也不能說徹底不能帶下劃線。Spring Boot Reference Guide 

我按照大佬的建議，看了官方文檔，找了幾篇文章，好好地跟了跟源碼。

看完這個，我更加肯定application.properties是沒問題的。而後讓我好幾個朋友在他們電腦上試了試，他們都說能夠。

原本這個應該到這兒，也就沒什麼了，而後週五的時候，老大說了技術需求池的事，我當時以爲頗有意思，並無作任何思考，直接把這2個問題問了下朋友，第二個問題跟這篇主題無關，說一下第一個問題我朋友當時給個人答案，他提了2種方案：

第一種：

implements ApplicationListener<ApplicationReadyEvent>

第二種：

implements CommandLineRunner 

說實話，當時看到這2種方案以後，個人第一感受就是特別打臉，我都很差意思說我本身前兩天剛看了Spring Boot的啓動過程。

而後，我寫了個demo項目，把這兩種方案都試了試，效果是出來了。我又打開官網（我看的就是公司使用的版本），搜索了下關於這2個類的，

第一種的官網位置：

https://docs.spring.io/spring-boot/docs/1.5.4.RELEASE/reference/html/boot-features-spring-application.html#boot-features-application-events-and-listeners

第二種的官網位置：

https://docs.spring.io/spring-boot/docs/1.5.4.RELEASE/reference/html/boot-features-spring-application.html#boot-features-command-line-runner

其實都在很近的位置，徹底能夠把SpringApplication這一部分的官方文檔都看完。我也是在看完這些文檔以後，纔開始本身思考，首先，這2種方式，只是保證了bean加載完成了，並且若是是僅僅打印日誌，那徹底是沒有必要用這2種方式實現的，我直接在

SpringApplication.run以後，打印一條日誌，不是更簡單。

看了一眼控制檯，再瞅一眼，每個啓動完的Spring Boot項目，都有一個啓動用了多長時間的日誌，

那既然這樣，打印日誌都是沒有必要的，直接用別人打印的日誌就行了，獲取這一行的日誌，有的話，就啓動成功了，豈不是更好。可是這樣的話，每個服務都要改。並且，並非每個服務都是Spring Boot項目的。

顯然這個也是行不通的，忽然以爲這個是能夠跟運維溝通一下的，而後我問了下運維同事，他給我說了下他的想法：作一個專門用來健康檢測的頁面的，固定url，這個就是看大家程序了，程序啓動完成，在一個能夠訪問的頁面寫入信息，咱們這邊請求這個頁面，若是內容是符合需求，則判斷啓動成功。

這種解決方案，也是須要改全部服務的。我比較好奇有沒有能夠在不改變現有服務的前提下實現這個或者有沒有其餘的想法，準備週末的時候，找找相關的資料。

 

這件事，我挺有感觸的。

首先是我給本身的任務排期有誤，致使時間有點多，而後我纔會想說，有時間我就好好看看application.properties的加載和解析過程。若是時間很少，十有八九我壓根不會看這個，因此，之後若是遇到什麼以爲有意思的，即便當時不看，要把現象記下來，任什麼時候間，看一看緣由和原理，就是一波很好的學習。

其實一開始我也不知道究竟是哪一個類，我只知道有個相似的好像是什麼策略的，我只記得好像有個駝峯，而後我用camel找了很久找到了這個類RelaxedNames，而後反向推的整個過程，看完整個過程，大概跟了一下Spring Boot的啓動流程。接着就是得意洋洋的炫耀了一下我本身的收穫，要不說分享是一件頗有意思的是呢？我朋友說了句，你找到這個類的速度快嗎，我感受若是是我，我不會用這個思路去找緣由，我會直接看application.properties的加載過程，要不你試試問幾我的，看看別人的思路。我把這個問題貼給了一個大佬，他說的思路就是上面那4句話。並且，他還讓我試了試@ConfigurationProperties和@Value的區別。若是這就是結局，也沒什麼大的感觸，但是並非，那個大佬當天就寫了總結文章，而且再次複習了Spring Boot相關的學習筆記，還給我貼了一堆連接讓我看。若是問一個問題，別人解決問題的熱情和對待問題的態度都比本身還要好不少，其實很很差意思的。至少這篇文章我是沒有作到當天就寫出來的，我也沒有去想說把Spring Boot的相關知識都當即好好複習複習，及時性很不夠。並且，爲何我會去寫這篇文章，仍是由於老大說一個月要有一篇原創，我記得這件事說，這個月我須要寫什麼，因此纔回去留心一些事情的本質。

再而後就是今天我朋友提出的方案，我學東西，作不到立馬運用到，他若是不說這2種方案，爲何個人大腦作不到條件反射有這些思路在。固然，最最重要的是，問問題以前，我竟然沒有先本身思考。好在比較有進步的是，至少在朋友給出方案以後，我本身先試了，而後緊接着去看了官方文檔，而後表達了個人疑惑和個人見解，至少是除了提問，跟朋友之間，對這個問題，還有在進行溝通，再而後才考慮去百度相關方案，而不是一開始就各類百度。終於開始思考了，開始帶着方案、大概思路或者各類疑惑去跟別人溝通，這種感受仍是挺好的。

最後，就是以爲，經常跟周圍的朋友們交流收穫，其實沒準能夠一不當心有更多意想不到的收穫。

 

最後貼幾個連接，以爲還不錯，能夠看看

https://mp.weixin.qq.com/s/iFHNspaGBlwPOnjuxQw9Eg

https://mp.weixin.qq.com/s/PciAigrwwJTjsfyd-jPf4A

https://www.jianshu.com/p/a1fbfc4f9e12