![頭圖.png](https://ucc.alicdn.com/pic/developer-ecology/018bc3a9231c4f08bff3d1630d67811e.png)

作者 | 王瑞顯  掌門教育基礎架構部研發工程師
來源[|阿里巴巴雲原生公眾號](https://mp.weixin.qq.com/s/RuqltkN9VdVQ1K3GKuJ-Gw)

# 背景

接收到公司業務部門的開發反饋，應用在升級公司內部框架後，UAT（預生產）環境介面效能壓測不達標。
升級前壓測報告：

![1.png](https://ucc.alicdn.com/pic/developer-ecology/0267655a42ff4693a17fd22d7b21b940.png)

升級後壓測報告：

![2.png](https://ucc.alicdn.com/pic/developer-ecology/f15d8da9431c478b829747f6c92dbc8f.png)

在機器配置（1C4G）相同的情況下，吞吐量從原來的 53.9/s 下降到了 6.4/s，且 CPU 負載較高。

並且開發反饋從公司全鏈路監控系統 SkyWalking 中查詢到的鏈路資訊可以得知大部分請求 Feign 呼叫的耗時不太正常（390ms），而實際被呼叫的下游服務響應速度很快（3ms）。

![3.png](https://ucc.alicdn.com/pic/developer-ecology/9575c6a756ae4abb995262ac074329c9.png)

# 定位問題

在接收到反饋以後，我立即申請了相應機器的許可權，並往相應機器上傳了 Arthas（version 3.4.3）。

讓業務方保持壓測，開始問題定位。

## 1. 執行 profiler 命令對 CPU 進行效能分析

```
[arthas@17962]$ profiler start -d 30 -f /tmp/arthas/1.txt
```

等待 30s 後，開啟 1.txt，檢視 CPU 效能分析結果，開頭部分示例如下：

```
--- 1630160766 ns (4.24%), 141 samples
  ......
  [14] org.springframework.boot.loader.LaunchedURLClassLoader.definePackageIfNecessary
  [15] org.springframework.boot.loader.LaunchedURLClassLoader.loadClass
  [16] java.lang.ClassLoader.loadClass
  [17] java.lang.Class.forName0
  [18] java.lang.Class.forName
  [19] org.springframework.util.ClassUtils.forName
  [20] org.springframework.http.converter.json.Jackson2ObjectMapperBuilder.registerWellKnownModulesIfAvailable
  [21] org.springframework.http.converter.json.Jackson2ObjectMapperBuilder.configure
  [22] org.springframework.http.converter.json.Jackson2ObjectMapperBuilder.build
  [23] org.springframework.web.servlet.config.annotation.WebMvcConfigurationSupport.addDefaultHttpMessageConverters
  [24] org.springframework.web.servlet.config.annotation.WebMvcConfigurationSupport.getMessageConverters
  [25] org.springframework.boot.autoconfigure.http.HttpMessageConverters$1.defaultMessageConverters
  [26] org.springframework.boot.autoconfigure.http.HttpMessageConverters.getDefaultConverters
  [27] org.springframework.boot.autoconfigure.http.HttpMessageConverters.<init>
  [28] org.springframework.boot.autoconfigure.http.HttpMessageConverters.<init>
  [29] org.springframework.boot.autoconfigure.http.HttpMessageConverters.<init>
  [30] com.zhangmen.xxx.DefaultFeignConfig.lambda$feignDecoder$0
  [31] com.zhangmen.xxx.DefaultFeignConfig$$Lambda$704.256909008.getObject
  [32] org.springframework.cloud.openfeign.support.SpringDecoder.decode
  [33] org.springframework.cloud.openfeign.support.ResponseEntityDecoder.decode
 ......
```

## 2. 對可疑的方法執行 trace 命令輸出方法路徑上每個節點的耗時

分析上一步得到的 CPU 效能分析結果，可以發現最佔用 CPU 的棧中，確實有 Feign 相關的棧幀。

並且發現 Feign 相關的棧幀周圍出現了 com.zhangmen 相關的棧幀：com.zhangmen.xxx.DefaultFeignConfig$$Lambda$704.256909008.getObject 和 com.zhangmen.xxx.DefaultFeignConfig.lambda$feignDecoder$0。

在 1.txt 中搜尋 com.zhangmen.xxx.DefaultFeignConfig，發現有 340 次命中，因此認為這是一個非常可疑的方法。

執行 trace 命令輸出該方法路徑上每個節點的耗時：

```
[arthas@17962]$ trace com.zhangmen.xxx.DefaultFeignConfig * '#cost>200' -n 3
`---[603.999323ms] com.zhangmen.xxx.DefaultFeignConfig:lambda$feignEncoder$1()
    `---[603.856565ms] org.springframework.boot.autoconfigure.http.HttpMessageConverters:<init>() #42
```

發現 org.springframework.boot.autoconfigure.http.HttpMessageConverters:<init>() 比較耗時，並繼續一層層 trace 追蹤下去：

```
[arthas@17962]$ trace org.springframework.boot.autoconfigure.http.HttpMessageConverters <init> '#cost>200' -n 3
......
[arthas@17962]$ trace org.springframework.http.converter.json.Jackson2ObjectMapperBuilder registerWellKnownModulesIfAvailable '#cost>200' -n 3
```

![4.png](https://ucc.alicdn.com/pic/developer-ecology/b2992019bee744e98f345bdec31f8231.png)

最終發現 org.springframework.util.ClassUtils:forName() 比較耗時，並且丟擲了異常。

使用 watch 命令檢視具體的異常：

```
[arthas@17962]$ watch org.springframework.util.ClassUtils forName -e "throwExp" -n 
```

![5.png](https://ucc.alicdn.com/pic/developer-ecology/c3dbd57b603845c8ac01d29edf455122.png)

# 解決問題

將定位到的問題，反饋給相關業務開發，並建議引入 jackson-datatype-joda 依賴。

引入依賴後壓測報告：

![6.png](https://ucc.alicdn.com/pic/developer-ecology/100143dd93ec498c980e795a69974f14.png)

吞吐量從原來的 6.4/s 提升到了 69.3/s，比升級框架前的 53.9/s 還要高。

這時候相關業務開發反饋，這個問題是程式碼中自定義了 Feign 的編解碼器（下圖所示）導致的，並且這個編解碼器在升級框架前也是一直存在的。

![7.png](https://ucc.alicdn.com/pic/developer-ecology/7cfecd85a362422789006f0f4e4b64e8.png)

於是，對升級框架前的程式碼進行壓測並在壓測過程中使用 Arthas 執行以下命令：

![8.png](https://ucc.alicdn.com/pic/developer-ecology/6fc4fe2bbfbd498793476da4830292ef.png)

發現同樣有這個異常。引入 jackson-datatype-joda 依賴，再次進行壓測，壓測報告如下：

![9.png](https://ucc.alicdn.com/pic/developer-ecology/e33b7e28f4b64e68bc4ae7c41a138f32.png)

彙總前面的壓測結果：

![10.png](https://ucc.alicdn.com/pic/developer-ecology/af58d0d2938a43e2a5056931c0509bd6.png)

可以發現一個新的問題：為什麼新舊版本同時不引入依賴，吞吐量相差近 8 倍，新舊版本同時引入依賴，吞吐量相差近 1 倍？

# 進一步定位問題

根據上一步中發現的新問題，接下來對 未升級框架並引入依賴的版本 和 升級框架並引入依賴的版本 分別進行壓測，並在壓測過程中使用 Arthas 的 profiler 命令取樣 CPU 效能分析資料，得到樣本 1 和樣本 2 。並從樣本 1 和樣本 2 中找到相似棧進行對比：

![11.png](https://ucc.alicdn.com/pic/developer-ecology/7fba1704703a4dddab57ab225a793c14.png)

透過對比可以發現，兩個樣本的相似棧的前 17 行有所不同。並對樣本 2 中的可疑棧幀進行 trace 追蹤：

```
[arthas@10561]$ trace org.apache.catalina.loader.WebappClassLoaderBase$CombinedEnumeration * '#cost>100' -n 3
`---[171.744137ms] org.apache.catalina.loader.WebappClassLoaderBase$CombinedEnumeration:hasMoreElements()
    `---[171.736943ms] org.apache.catalina.loader.WebappClassLoaderBase$CombinedEnumeration:inc() #2685
        `---[171.724546ms] org.apache.catalina.loader.WebappClassLoaderBase$CombinedEnumeration:inc()
```

發現升級框架後，在類載入器這部分存在比較耗時的情況。

而對樣本 1 中這部分進行 trace 追蹤沒有出現耗時大於 100ms 的情況。

又進一步使用 profiler 命令，分別生成兩個版本在壓測場景下的火焰圖，並找到相似棧進行對比：

```
[arthas@10561]$ profiler start -d 30 -f /tmp/arthas/1.svg
```

![12.png](https://ucc.alicdn.com/pic/developer-ecology/7c711442e97b45e98add450c708c3baa.png)

發現 升級框架並引入依賴的版本 還多出了一些 org/springframework/boot/loader/ 相關的棧。

# 進一步解決問題

將新的發現反饋給相關業務開發。

他們反映此次除了框架升級外，還有 Spring Boot war to jar 部署的調整。從使用獨立的 Tomcat war 部署，改造成用 Spring Boot 內嵌 Tomcat java -jar 部署。故懷疑兩種部署方式在類載入器上存在效能差異。
相關業務開發在我上一步定位問題期間，根據我最初定位到的問題，在 Google 搜尋 feign com.fasterxml.jackson.datatype.joda.JodaModule，找到了一篇相關的文章[《loadClass 導致線上服務卡頓分析》](https://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247500621&idx=2&sn=5c947dbad1b4dd884cf5f3096c86bff1&chksm=fae6c882cd9141946b026950efb1b38606d8c8f870fc28ce0fa234c9f462861513b79f34a938&token=51147729&lang=zh_CN)。

文章中的作者，遇到的問題與我們基本相似。

看了這篇文章後，我又 Debug 了部分原始碼，最後瞭解到問題產生的根本原因是：SpringEncoder / SpringDecoder 在每次編碼 / 解碼時都會呼叫 ObjectFactory<httpmessageconverters>.getObject()).getConverters() 獲取 HttpMessageConverters。而我們自定義的 DefaultFeignConfig 中配置的ObjectFactory<httpmessageconverters> 的實現是每次都 new 一個新的 HttpMessageConverters 物件。

HttpMessageConverters 的構造方法又預設會執行 getDefaultConverters 方法獲取預設的 HttpMessageConverter 集合，並初始化這些預設的 HttpMessageConverter。其中的 MappingJackson2HttpMessageConverter（有兩個，見下圖） 每次初始化時都會載入不在 classpath 中的 com.fasterxml.jackson.datatype.joda.JodaModule和 com.fasterxml.jackson.datatype.joda$JodaModule（org.springframework.util.ClassUtils 載入不到類時，會嘗試再載入一下內部類），並丟擲 ClassNotFoundException，且該異常最後被生吞。

而部分和 XML 相關的預設的 HttpMessageConverter，SourceHttpMessageConverter 和 Jaxb2RootElementHttpMessageConverter（各有兩個，見下圖）每次初始化時，會執行 TransformerFactory.newInstance()，執行過程中會使用 SPI 掃描 classpath 下的 META-INF / services 目錄獲取具體的實現，並且每次掃描完也沒有獲取到具體的實現，最終使用預設指定的 com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl作為實現。

最終導致每一次 Feign 呼叫（包含編碼和解碼），都會載入 4 次不在 classpath 中的 com.fasterxml.jackson.datatype.joda.JodaModule 和 com.fasterxml.jackson.datatype.joda$JodaModule（共8次），且 8 次使用 SPI 掃描 classpath 下的 META-INF / services 目錄獲取查詢不到的實現，而 war to jar 後，類載入器在頻繁查詢和載入資源上的效能有所下降，最終導致嚴重影響介面效能。

預設的 HttpMessageConverter 集合：

![13.png](https://ucc.alicdn.com/pic/developer-ecology/fa1e60e899ae476fa17d629e43d1b8aa.png)

部分關鍵程式碼如下。

org/springframework/boot/autoconfigure/http/HttpMessageConverters.<init>：

![14.png](https://ucc.alicdn.com/pic/developer-ecology/963a39c4fe0e45fd88ac661e2a83f1e6.png)

org/springframework/http/converter/json/Jackson2ObjectMapperBuilder.registerWellKnownModulesIfAvailable：

![15.png](https://ucc.alicdn.com/pic/developer-ecology/6da5e9e6eadd43dc8d38c5db71f44f64.png)

org/springframework/util.ClassUtils.forName：

![16.png](https://ucc.alicdn.com/pic/developer-ecology/071e2af5502e4fc9a1adb5da7de9d6c4.png)

org/springframework/http/converter/xml/SourceHttpMessageConverter：

![17.png](https://ucc.alicdn.com/pic/developer-ecology/1b8a0a5a290444e19bd6db520cd29c73.png)

javax/xml/transform/FactoryFinder.find：

![18.png](https://ucc.alicdn.com/pic/developer-ecology/85087cc604a24a6a89ca528e97a45aff.png)

文章中對於這個問題還提供了兩種解決方法：

**第一種方法**，就是我最初建議的引入 jackson-datatype-joda 依賴，避免每次初始化預設的 MappingJackson2HttpMessageConverter 時 ClassLoader 反覆載入不在 classpath 中的 com.fasterxml.jackson.datatype.joda.JodaModule 和 com.fasterxml.jackson.datatype.joda$JodaModule。

**第二種方法**，不初始化預設的 HttpMessageConverter。由於我們此處只需要使用自定義的 FastJsonHttpMessageConverter 來執行編解碼，完全可以避免執行 getDefaultConverters 方法，重複初始化許多用不到的預設的 HttpMessageConverter。因此在 new HttpMessageConverters 物件時 ，可以將 addDefaultConverters 引數設定為 false。

```
ObjectFactory<httpmessageconverters> objectFactory = () -> new HttpMessageConverters(false, new HttpMessageConverter[] { (HttpMessageConverter)fastJsonHttpMessageConverter });
```

實際上，我們還可以修改 DefaultFeignConfig 中 ObjectFactory<httpmessageconverters> 的實現，避免每次都 new 一個新的 HttpMessageConverters 物件（重複初始化 HttpMessageConverters），實現進一步最佳化。
故建議相關業務開發，將 DefaultFeignConfig 修改成如下程式碼：

![19.png](https://ucc.alicdn.com/pic/developer-ecology/6c1d0c9e71a64226a78e430de6268ac0.png)

在相關業務開發將新舊版本程式碼中的 DefaultFeignConfig 都進行改進並部署到 FAT（測試）環境以後，我在自己本機用 JMeter 對 FAT 環境進行了模擬壓測。

舊版改進後壓測結果：

![20.png](https://ucc.alicdn.com/pic/developer-ecology/5714599e73dd41729bb1507e6f8938d9.png)

新版改進後壓測結果：

![21.png](https://ucc.alicdn.com/pic/developer-ecology/06fae09d58b34e709374cab82170d7bc.png)

發現此時，兩個版本的介面效能已經基本相同。

最終測試人員在 UAT 環境，對升級框架並改進 DefaultFeignConfig 後的程式碼再次進行壓測，壓測結果如下：

![22.png](https://ucc.alicdn.com/pic/developer-ecology/38b8368325cf40b6b24b0199e981d967.png)

吞吐量從最初不達標的 6.4/s，提升到了160.4/s。

那為什麼 war to jar 部署的調整，會導致類載入器在頻繁查詢和載入資源時效能有所下降呢？

在對 SpringBoot 可執行 jar 的原理做了一番瞭解以後。懷疑和 Spring Boot 為了做到能夠以一個 fat jar 來啟動，從而擴充套件了 JDK 的 JarFile URL 協議，並定製了自己的 ClassLoader 和 jar 檔案協議的 Hander，實現了 jar in jar、jar in directory 的載入方式有關。

對 SpringBoot 可執行 jar 原理感興趣的朋友可以參考：[《可執行 jar 包》](https://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247500621&idx=2&sn=5c947dbad1b4dd884cf5f3096c86bff1&chksm=fae6c882cd9141946b026950efb1b38606d8c8f870fc28ce0fa234c9f462861513b79f34a938&token=51147729&lang=zh_CN)。

# War2Jar 類載入器效能下降根因探究

為了驗證自己的猜測，我在自己本機搭建了一個簡單的 Demo。

Demo 中有兩個服務，A 和 B。將 A 和 B 都註冊到 Eureka 註冊中心，並且 A 透過 Feign 呼叫 B。

接下來使用 Jmeter 在相同的配置下對各種場景進行壓測，並在壓測過程中使用 Arthas 的 profiler 命令生成各種場景下的火焰圖。

壓測結果如下（-Xms512m -Xmx512m）：

![23.png](https://ucc.alicdn.com/pic/developer-ecology/7578d9cc375242fea914da1712c3ac26.png)

透過對比表格三和表格四可以得知，程式碼最佳化後，是否引入依賴，對吞吐量幾乎沒有影響。

透過表格三和表格四可以得知，程式碼最佳化後，在不會頻繁查詢和載入不存在的資源時，三種部署方式的吞吐量基本一致。

透過表格二可以得知，在頻繁使用 SPI 獲取 classpath 下查詢不到的實現時，Tomcat war 部署效能更好。

透過表格一可以得知，在頻繁載入不存在的類時，將 jar 包解壓後透過 JarLauncher 啟動效能更好。

對比表格一中 ③ 和 ② 相似棧的火焰圖：

![24.png](https://ucc.alicdn.com/pic/developer-ecology/411d6ed998e949afa69dba8665753add.png)

可以發現兩者在 org/springframework/boot/loader/LaunchedURLClassLoader.loadClass 載入類時，存在差異。

② 不僅會執行 java/lang/ClassLoader.loadClass，還會執行 org/springframework/boot/loader/LaunchedURLClassLoader.definePackageIfNecessary。

檢視 org/springframework/boot/loader/LaunchedURLClassLoader.loadClass 的原始碼：

![25.png](https://ucc.alicdn.com/pic/developer-ecology/dd10344d367747c787cf039c401ee408.png)

發現存在一個條件分支。

檢視 org/springframework/boot/loader/Launcher.createArchive 的原始碼：

![26.png](https://ucc.alicdn.com/pic/developer-ecology/e0cf752b3e304dbd9dc5fca029b69378.png)

發現這個條件的值與應用是 可執行 jar 檔案 還是 檔案目錄 有關。

對 ② 再次進行壓測，並 trace org/springframework/boot/loader/LaunchedURLClassLoader.definePackageIfNecessary：

```
`---[165.770773ms] org.springframework.boot.loader.LaunchedURLClassLoader:definePackageIfNecessary()
    +---[0.00347ms] org.springframework.boot.loader.LaunchedURLClassLoader:getPackage() #197
    `---[165.761244ms] org.springframework.boot.loader.LaunchedURLClassLoader:definePackage() #199
```

發現這個地方確實存在比較耗時的情況。

閱讀該部分原始碼，從註釋中即可得知，definePackageIfNecessary 主要是為了在呼叫 findClass 之前嘗試根據類名去定義類所在的 package，確保 jar 檔案巢狀 jar 包裡的 manifest 能夠和 package 關聯起來。

![27.png](https://ucc.alicdn.com/pic/developer-ecology/7477d362a01a472f9d2cb93414d0f2bf.png)

Debug definePackageIfNecessary 這部分程式碼，發現在 definePackage 時，會遍歷 BOOT-INF/lib/ 下所有的 jar 包 以及 BOOT-INF/classes/。如果發現這些資源中存在指定的類，就繼續呼叫 definePackage 方法，否則遍歷完直接返回 null。

![28.png](https://ucc.alicdn.com/pic/developer-ecology/a939f1ad8afc4308abaa86f3c4f31fb9.png)

![29.png](https://ucc.alicdn.com/pic/developer-ecology/680c576aae8348f4bda78a445fd09472.png)

前面說過，每一次 Feign 呼叫都會載入 4 次不在 classpath 中的 com.fasterxml.jackson.datatype.joda.JodaModule 和 com.fasterxml.jackson.datatype.joda$JodaModule （共8次）。而我這個簡單的 Demo 應用依賴的 jar 有 117 個（實際企業級專案將會更多）。那麼每一次 Feign 呼叫，就會執行 8 * (117 + 1)，總計 944 次迴圈裡的邏輯。而邏輯中的 org.springframework.boot.loader.jar.Handler.openConnection 方法在執行過程中又會涉及到比較耗時的 IO 操作，最終導致嚴重影響介面效能。從生成的火焰圖中，也可以看到這部分處理邏輯。

![30.png](https://ucc.alicdn.com/pic/developer-ecology/1fd16a7efa0b49e8af060b7fc299e264.png)

至此，已經可以確認 war to jar 部署的調整，導致類載入器在頻繁查詢和載入資源時效能有所下降的根因就是：Spring Boot 為了做到能夠以一個 fat jar 來啟動，增加了一些定製的處理邏輯，而這部分定製的處理邏輯在頻繁執行時，會對程式效能產生較大影響。

至於 [為什麼在頻繁載入不存在的類時，將 jar 包解壓後透過 JarLauncher 啟動比 Tomcat war 部署效能更好？] 、[在頻繁使用 SPI 獲取 classpath 下查詢不到的實現時，Tomcat war 部署又比將 jar 包解壓後透過 JarLauncher 啟動效能更好？] ，受限於篇幅，就不在本文中繼續展開了。感興趣的朋友可以按照本文中介紹的方法，再結合相關原始碼進行進一步探究。

# 總結

大家在自定義 Feign 的編解碼器時，如果用到了 SpringEncoder / SpringDecoder，應避免 HttpMessageConverters 的重複初始化。如果不需要使用那些預設的 HttpMessageConverter，可以在初始化 HttpMessageConverters 時將第一個入參設定為 false，從而不初始化那些預設的 HttpMessageConverter。

另外，應該瞭解不同的部署方式在類載入器頻繁查詢和載入資源時是存在效能差異的。

我們在寫程式碼時，也應該要避免重複初始化，以及反覆查詢和載入不存在的資源。

最後，善用[SkyWalking ](https://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247500621&idx=2&sn=5c947dbad1b4dd884cf5f3096c86bff1&chksm=fae6c882cd9141946b026950efb1b38606d8c8f870fc28ce0fa234c9f462861513b79f34a938&token=51147729&lang=zh_CN)和[Arthas ](https://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247500621&idx=2&sn=5c947dbad1b4dd884cf5f3096c86bff1&chksm=fae6c882cd9141946b026950efb1b38606d8c8f870fc28ce0fa234c9f462861513b79f34a938&token=51147729&lang=zh_CN)可以幫助我們更加高效地排查程式錯誤和效能瓶頸。

# 彩蛋

如果應用使用了 SkyWalking Agent，再使用 Arthas，可能會遇到 Arthas 部分命令（trace、watch 等會對類進行增強的命令）不能正常工作的問題。

解決方案：[https://github.com/apache/skywalking/blob/master/docs/en/FAQ/Compatible-with-other-javaagent-bytecode-processing.md](https://github.com/apache/skywalking/blob/master/docs/en/FAQ/Compatible-with-other-javaagent-bytecode-processing.md)

而當 Arthas 可以正常工作以後，我們對於 SkyWalking Agent 已經增強過的類的方法執行 trace 等命令時，最好在方法名後面加上一個 * 符號進行模糊匹配。Arthas 最終會將所有匹配1方法的 trace 追蹤結果進行彙總展示。

方法名不加 * 進行 trace：

![31.png](https://ucc.alicdn.com/pic/developer-ecology/38f65124b52449ebbe76325b4424d568.png)

方法名加上 * 進行trace：

![32.png](https://ucc.alicdn.com/pic/developer-ecology/491b14072b274dc6a44e70a089ba9431.png)

可以看到方法名加上 * 以後，trace 得到的結果才是我們理想的結果。

這是由於 SkyWalking Agent 使用了 ByteBuddy 做位元組碼增強。而 ByteBuddy 每增強一個方法，都會為該方法生成一個輔助內部類（HelloController$auxiliary$jiu2bTqU），並且會對當前類（HelloController）中的原方法（test1）進行重新命名（test1$original$lyu0XDob），並生成一個與原方法同名的方法（test1）和一個不同名但僅供輔助內部類呼叫的方法（test1$original$lyu0XDob$accessor$8F82ImAF）。

使用同事開發的 [Java 反編譯工具](https://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247500621&idx=2&sn=5c947dbad1b4dd884cf5f3096c86bff1&chksm=fae6c882cd9141946b026950efb1b38606d8c8f870fc28ce0fa234c9f462861513b79f34a938&token=51147729&lang=zh_CN)可以直觀地看到相關程式碼：

![33.png](https://ucc.alicdn.com/pic/developer-ecology/0d1a5972922349b5808a0b976dddf1cb.png)

![34.png](https://ucc.alicdn.com/pic/developer-ecology/316e44e3312345fd90fc79422a130960.png)

另外，在使用 Arthas 的時候，建議選擇最新的版本。比如，3.4.2 以前的版本 trace 追蹤大方法時就可能會導致 JVM Metaspace OOM。詳情見：[《記一次由 Arthas 引起的 Metaspace OOM 問題》](https://mp.weixin.qq.com/s?__biz=MzU4MDUxOTI5NA==&mid=2247486510&idx=1&sn=739bc7aa867d9483a123fdc18f102c89&scene=21#wechat_redirect)。

如果你想要基於 Arthas 打造企業級線上診斷平臺，可以參考[《工商銀行打造線上診斷平臺的探索與實踐》](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247495091&idx=1&sn=d2eae0c02b90357fd9d7d49007ee0629&chksm=fae6e67ccd916f6a0925038d183a4c66c9640e93b685cc0707d2a0c7e8022d870df44d348907&scene=21#wechat_redirect)。

### **作者簡介**

**王瑞顯**，開源愛好者，現任掌門教育基礎架構部研發工程師，主要負責公司全鏈路監控系統和應用診斷平臺的研發。

**歡迎登陸 start.aliyun.com 知行動手實驗室體驗 Arthas 57 個動手實驗：[https://start.aliyun.com/handson-lab/#!category=arthas](https://start.aliyun.com/handson-lab/#!category=arthas)**

![35.gif](https://ucc.alicdn.com/pic/developer-ecology/c4db0acb61974c268be2bb5a30860fd2.gif)

Arthas 實驗預覽

為了讓更多開發者開始用上 Arthas 這個 Java 診斷神器，Arthas 社群聯合 JetBrains 推出 [Arthas 有獎徵文活動](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247489867&idx=1&sn=1e52e16f370541de77f84d4a3b100a2d&chksm=fae51284cd929b926bbed215cd609da749ba265693ebc08b1af1f027bf8a1b0e0d9aa682d99b&token=1321663756&lang=zh_CN&scene=21#wechat_redirect)：**聊聊這些年你和 Arthas 之間的那些事兒。**活動仍在火熱進行中，[點選即可參與](http://alibabacloud.mikecrm.com/9khcRrs)，歡迎大家踴躍投稿，參與即有可能獲獎！</httpmessageconverters></httpmessageconverters></init></httpmessageconverters></httpmessageconverters></init></init></init></init></init></init>

Spring Boot 微服務效能下降九成！使用 Arthas 定位根因

相關文章