某天，開發(fā)的代碼在 CI 階段遇上了這樣一個看似比較「怪異」的問題：

代碼在 CI 時，有一個步驟會跑去單元測試。因為依賴了遠程的配置中心，所以有兩份配置存在，一個在配置中心，一個是本地的 yml 文件。這兩份配置里使用的是兩個不同的數(shù)據(jù)庫。

一般情況下，本地開發(fā)可以方便在 yml 里設(shè)置需要的屬性做測試，再把不同環(huán)境下的配置加到配置中心，相當(dāng)于不同的 profile。

而這個怪異問題是在跑單測階段，在兩個不同的數(shù)據(jù)庫上跳來跳去，某個測試數(shù)據(jù)寫在A，其它測試可能寫在 B。

憑直覺就是配置加載的不對，但具體什么時候使用的是哪個配置，還不確定。而 CI 的機器是個公共的容器，沒有權(quán)限登錄。

我最先想到 JMX MBean 上可能會有這些信息。只要 JConsole 連接上去就能查看了，本地簡單試了一下，沒啥問題。

通過 org.springframework.cloud.context.environment:name=environmentManager,type=EnvironmentManager這個 ObjectName，是可以拿到 Env 的對象，進而可以操作 setProperty 和 getProperty 的操作的，像這樣。

在操作里可以選擇 getProperty,然后把 property 名稱寫進去點按鈕即可。

不過無奈遠程機器沒開放 JMX 連接，開始想其它辦法。

一番折騰之后，發(fā)現(xiàn)機器所在平臺上有個網(wǎng)頁版的命令，支持部分 Arthas 命令，可以在頁面選擇命令，輸入框里自己定義參數(shù)值，發(fā)送到遠端服務(wù)器上執(zhí)行。之前研究過一些 Arthas 的使用和實現(xiàn)原理(阿里監(jiān)控診斷工具 Arthas 源碼原理分析)，感覺這或許可以派上用場。畢竟 Agent 在 Attach 到 JVM 上之后，通過 JVMTI 能干的事就太多了。

網(wǎng)上的文章，基本介紹都是通過 tt 的命令來實現(xiàn)拿到 ApplicationContext，再執(zhí)行其他想要的操作。

查了下 Arthas 的文檔，提供的命令里， watch 和 tt 這兩個命令能拿到入?yún)?，返回值，target 等等，還支持 Ognl 表達式，不過前面說的頁面平臺不支持 tt，那只能通過迂回的使用 watch 來查看了。

折騰一番，給頁面發(fā)送的命令加了個轉(zhuǎn)義，在 watch 中通過 target 對象再執(zhí)行額外的操作，終于實現(xiàn)了需要的功能。

通過 watch 命令執(zhí)行即可，如果你需要在本地執(zhí)行，那兩個轉(zhuǎn)義符需要去掉。

org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter 
invokeHandlerMethod 
'{target.getApplicationContext().getEnvironment().getProperty(\"app.name\"),returnObj}' 
-x 2

除了拿 env 里的屬性值這種功能之外，b e s f 這幾個選項，能夠在方法執(zhí)行的不同時期進行觀察，此外，也可以再增加過濾表達式，對入值增加條件，像這樣：

可以靈活組合應(yīng)用在分析問題的場景中。

折騰之后，能查看加載的配置文件，但具體跑單測時為什么會來回的變換配置呢? 一個同學(xué) Debug 發(fā)現(xiàn)，原來是在一些測試類里加了個 @TestProperty 的注解，一些沒寫。這個注解重寫了一個配置中心 namespace 的屬性，導(dǎo)致拉遠程配置中心配置失敗，直接使用了本地的 yml 的配置，和 yml 配置和遠程配置中心又不一致，所以就出現(xiàn)了看似怪異的問題。 

如果你也有需要排查的問題，可以試試 Arthas 或者相關(guān)閱讀里的其它幾個工具。