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

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

一般情況下，本地開發可以方便在 yml 里設置需要的屬性做測試，再把不同環境下的配置加到配置中心，相當于不同的 profile。

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

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

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

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

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

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

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

網上的文章，基本介紹都是通過 tt 的命令來實現拿到 ApplicationContext，再執行其他想要的操作。

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

折騰一番，給頁面發送的命令加了個轉義，在 watch 中通過 target 對象再執行額外的操作，終于實現了需要的功能。

通過 watch 命令執行即可，如果你需要在本地執行，那兩個轉義符需要去掉。

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

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

可以靈活組合應用在分析問題的場景中。

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

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