用 Arthas 定位 Spring Boot 接口的超時問題，讓應用起飛！

2024-06-04 10:37:06

最近在優(yōu)化接口的響應時間，優(yōu)化了代碼之后，但是時間還是達不到要求；有一個詭異的100ms左右的耗時問題，在接口中打印了請求處理時間后，和調用方的響應時間還有差了100ms左右。比如程序里記錄150ms，但是調用方等待時間卻為250ms左右。

背景

公司有個渠道系統(tǒng)，專門對接三方渠道使用，沒有什么業(yè)務邏輯，主要是轉換報文和參數(shù)校驗之類的工作，起著一個承上啟下的作用。

下面記錄下當時詳細的定位&解決流程（其實解決很簡單，關鍵在于怎么定位并找到解決問題的方法）。

定位過程

分析代碼

渠道系統(tǒng)是一個常見的spring-boot web工程，使用了集成的tomcat。分析了代碼之后，發(fā)現(xiàn)并沒有特殊的地方，沒有特殊的過濾器或者攔截器，所以初步排除是業(yè)務代碼問題。

分析調用流程

出現(xiàn)這個問題之后，首先確認了下接口的調用流程。由于是內(nèi)部測試，所以調用流程較少。

Nginx -反向代理-> 渠道系統(tǒng)

公司是云服務器，網(wǎng)絡走的也是云的內(nèi)網(wǎng)。由于不明確問題的原因，所以用排除法，首先確認服務器網(wǎng)絡是否有問題。

先確認發(fā)送端到Nginx Host是否有問題：

[jboss@VM_0_139_centos ~]$ ping 10.0.0.139
PING 10.0.0.139 (10.0.0.139) 56(84) bytes of data.
64 bytes from 10.0.0.139: icmp_seq=1 ttl=64 time=0.029 ms
64 bytes from 10.0.0.139: icmp_seq=2 ttl=64 time=0.041 ms
64 bytes from 10.0.0.139: icmp_seq=3 ttl=64 time=0.040 ms
64 bytes from 10.0.0.139: icmp_seq=4 ttl=64 time=0.040 ms

從ping結果上看，發(fā)送端到Nginx主機的延遲是無問題的，接下來查看Nginx到渠道系統(tǒng)的網(wǎng)絡。

# 由于日志是沒問題的，這里直接復制上面日志了
[jboss@VM_0_139_centos ~]$ ping 10.0.0.139
PING 10.0.0.139 (10.0.0.139) 56(84) bytes of data.
64 bytes from 10.0.0.139: icmp_seq=1 ttl=64 time=0.029 ms
64 bytes from 10.0.0.139: icmp_seq=2 ttl=64 time=0.041 ms
64 bytes from 10.0.0.139: icmp_seq=3 ttl=64 time=0.040 ms
64 bytes from 10.0.0.139: icmp_seq=4 ttl=64 time=0.040 ms

從ping結果上看，Nginx到渠道系統(tǒng)服務器網(wǎng)絡延遲也是沒問題的

既然網(wǎng)絡看似沒問題，那么可以繼續(xù)排除法，砍掉Nginx，客戶端直接再渠道系統(tǒng)的服務器上，通過回環(huán)地址（localhost）直連，避免經(jīng)過網(wǎng)卡/dns，縮小問題范圍看看能否復現(xiàn)（這個應用和地址是我后期模擬的，測試的是一個空接口）：

[jboss@VM_10_91_centos tmp]$ curl -w "@curl-time.txt" http://127.0.0.1:7744/send
success
              http: 200
               dns: 0.001s
          redirect: 0.000s
      time_connect: 0.001s
   time_appconnect: 0.000s
  time_pretransfer: 0.001s
time_starttransfer: 0.073s
     size_download: 7bytes
    speed_download: 95.000B/s
                  ----------
        time_total: 0.073s 請求總耗時

從curl日志上看，通過回環(huán)地址調用一個空接口耗時也有73ms。這就奇怪了，跳過了中間所有調用節(jié)點（包括過濾器&攔截器之類），直接請求應用一個空接口，都有73ms的耗時，再請求一次看看：

[jboss@VM_10_91_centos tmp]$ curl -w "@curl-time.txt" http://127.0.0.1:7744/send
success
              http: 200
               dns: 0.001s
          redirect: 0.000s
      time_connect: 0.001s
   time_appconnect: 0.000s
  time_pretransfer: 0.001s
time_starttransfer: 0.003s
     size_download: 7bytes
    speed_download: 2611.000B/s
                  ----------
        time_total: 0.003s

更奇怪的是，第二次請求耗時就正常了，變成了3ms。經(jīng)查閱資料，linux curl是默認開啟http keep-alive的。就算不開啟keep-alive，每次重新handshake，也不至于需要70ms。

經(jīng)過不斷分析測試發(fā)現(xiàn)，連續(xù)請求的話時間就會很短，每次請求只需要幾毫秒，但是如果隔一段時間再請求，就會花費70ms以上。

從這個現(xiàn)象猜想，可能是某些緩存機制導致的，連續(xù)請求因為有緩存，所以速度快，時間長緩存失效后導致時間長。

那么這個問題點到底在哪一層呢？tomcat層還是spring-webmvc呢？

光猜想定位不了問題，還是得實際測試一下，把渠道系統(tǒng)的代碼放到本地ide里啟動測試能否復現(xiàn)。

但是導入本地Ide后，在Ide中啟動后并不能復現(xiàn)問題，并沒有70+ms的延遲問題。這下頭疼了，本地無法復現(xiàn)，不能Debug，由于問題點不在業(yè)務代碼，也不能通過加日志的方式來Debug。

這時候可以祭出神器Arthas了。

Arthas分析問題

Arthas 是Alibaba開源的Java診斷工具，深受開發(fā)者喜愛。當你遇到以下類似問題而束手無策時，Arthas可以幫助你解決：

這個類從哪個 jar 包加載的？為什么會報各種類相關的 Exception？
我改的代碼為什么沒有執(zhí)行到？難道是我沒 commit？分支搞錯了？
遇到問題無法在線上 debug，難道只能通過加日志再重新發(fā)布嗎？
線上遇到某個用戶的數(shù)據(jù)處理有問題，但線上同樣無法 debug，線下無法重現(xiàn)！
是否有一個全局視角來查看系統(tǒng)的運行狀況？
有什么辦法可以監(jiān)控到JVM的實時運行狀態(tài)？

上面是Arthas的官方簡介，這次我只需要用他的一個小功能trace。動態(tài)計算方法調用路徑和時間，這樣我就可以定位時間在哪個地方被消耗了。

trace 方法內(nèi)部調用路徑，并輸出方法路徑上的每個節(jié)點上耗時
trace 命令能主動搜索 class-pattern／method-pattern
對應的方法調用路徑，渲染和統(tǒng)計整個調用鏈路上的所有性能開銷和追蹤調用鏈路。

有了神器，那么該追蹤什么方法呢？由于我對Tomcat源碼不是很熟，所以只能從spring mvc下手，先來trace一下spring mvc的入口：

圖片

[jboss@VM_10_91_centos tmp]$ curl -w "@curl-time.txt" http://127.0.0.1:7744/send
success
              http: 200
               dns: 0.001s
          redirect: 0.000s
      time_connect: 0.001s
   time_appconnect: 0.000s
  time_pretransfer: 0.001s
time_starttransfer: 0.115s
     size_download: 7bytes
    speed_download: 60.000B/s
                  ----------
        time_total: 0.115s

本次調用，調用端時間花費115ms，但是從arthas trace上看，spring mvc只消耗了18ms，那么剩下的97ms去哪了呢？

本地測試后已經(jīng)可以排除spring mvc的問題了，最后也是唯一可能出問題的點就是tomcat。

可是本人并不熟悉tomcat中的源碼，就連請求入口都不清楚，tomcat里需要trace的類都不好找......

不過沒關系，有神器Arthas，可以通過stack命令來反向查找調用路徑，以org.springframework.web.servlet.DispatcherServlet作為參數(shù)：

stack 輸出當前方法被調用的調用路徑。

很多時候我們都知道一個方法被執(zhí)行，但這個方法被執(zhí)行的路徑非常多，或者你根本就不知道這個方法是從那里被執(zhí)行了，此時你需要的是 stack 命令。

圖片

從stack日志上可以很直觀的看出DispatchServlet的調用棧，那么這么長的路徑，該trace哪個類呢（這里跳過spring mvc中的過濾器的trace過程，實際排查的時候也trace了一遍，但這詭異的時間消耗不是由這里過濾器產(chǎn)生的）？

有一定經(jīng)驗的老司機從名字上大概也能猜出來從哪里下手比較好，那就是org.apache.coyote.http11.Http11Processor.service，從名字上看，http1.1處理器，這可能是一個比較好的切入點。下面來trace一下：

圖片

日志里有一個129ms的耗時點（時間比沒開arthas的時候更長是因為arthas本身帶來的性能消耗，所以生產(chǎn)環(huán)境小心使用），這個就是要找的問題點。

打問題點找到了，那怎么定位是什么導致的問題呢，又如何解決呢？

繼續(xù)trace吧，細化到具體的代碼塊或者內(nèi)容。trace由于性能考慮，不會展示所有的調用路徑，如果調用路徑過深，只有手動深入trace，原則就是trace耗時長的那個方法：

圖片

一段無聊的手動深入trace之后……

圖片

發(fā)現(xiàn)了一個值得暫停思考的點：

+---[min=0.004452ms,max=34.479307ms,total=74.206249ms,count=31] org.apache.catalina.webresources.TomcatJarInputStream:getNextJarEntry() #117

這行代碼加載了31次，一共耗時74ms；從名字上看，應該是tomcat加載jar包時的耗時，那么是加載了31個jar包的耗時，還是加載了jar包內(nèi)的某些資源31次耗時呢？

TomcatJarInputStream這個類源碼的注釋寫到：

The purpose of this sub-class is to obtain references to the JarEntry objects for META-INF/ and META-INF/MANIFEST.MF that are otherwise swallowed by the JarInputStream implementation.

大概意思也就是，獲取jar包內(nèi)META-INF/，META-INF/MANIFEST的資源，這是一個子類，更多的功能在父類JarInputStream里。

其實看到這里大概也能猜到問題了，tomcat加載jar包內(nèi)META-INF/，META-INF/MANIFEST的資源導致的耗時，至于為什么連續(xù)請求不會耗時，應該是tomcat的緩存機制（下面介紹源碼分析）。

不著急定位問題，試著通過Arthas最終定位問題細節(jié)，繼續(xù)手動深入trace：

[arthas@24851]$ trace org.apache.catalina.webresources.TomcatJarInputStream *
Press Q or Ctrl+C to abort.
Affect(class-cnt:1 , method-cnt:4) cost in 44 ms.
`---ts=2019-09-14 21:37:47;thread_name=http-nio-7744-exec-5;id=14;is_daemnotallow=true;priority=5;TCCL=org.springframework.boot.loader.LaunchedURLClassLoader@20ad9418
    `---[0.234952ms] org.apache.catalina.webresources.TomcatJarInputStream:createZipEntry()
        +---[0.039455ms] java.util.jar.JarInputStream:createZipEntry() #43
        `---[0.007827ms] java.lang.String:equals() #44

`---ts=2019-09-14 21:37:47;thread_name=http-nio-7744-exec-5;id=14;is_daemnotallow=true;priority=5;TCCL=org.springframework.boot.loader.LaunchedURLClassLoader@20ad9418
    `---[0.050222ms] org.apache.catalina.webresources.TomcatJarInputStream:createZipEntry()
        +---[0.001889ms] java.util.jar.JarInputStream:createZipEntry() #43
        `---[0.001643ms] java.lang.String:equals() #46
#這里一共31個trace日志，刪減了剩下的

從方法名上看，還是加載資源之類的意思。都已經(jīng)到jdk源碼了，這時候來看一下TomcatJarInputStream這個類的源碼:

/**
 * Creates a new <code>JarEntry</code> (<code>ZipEntry</code>) for the
 * specified JAR file entry name. The manifest attributes of
 * the specified JAR file entry name will be copied to the new
 * <CODE>JarEntry</CODE>.
 *
 * @param name the name of the JAR/ZIP file entry
 * @return the <code>JarEntry</code> object just created
 */
protected ZipEntry createZipEntry(String name) {
    JarEntry e = new JarEntry(name);
    if (man != null) {
        e.attr = man.getAttributes(name);
    }
    return e;
}

這個createZipEntry有個name參數(shù)，從注釋上看，是jar/zip文件名，如果能得到文件名這種關鍵信息，就可以直接定位問題了；還是通過Arthas，使用watch命令，動態(tài)監(jiān)測方法調用數(shù)據(jù)。

watch方法執(zhí)行數(shù)據(jù)觀測

讓你能方便的觀察到指定方法的調用情況。能觀察到的范圍為：返回值、拋出異常、入?yún)ⅲㄟ^編寫 OGNL 表達式進行對應變量的查看。

watch 該方法的入?yún)?/h4>

這下直接看到了具體加載的資源名，這么熟悉的名字：swagger-ui，一個國外的rest接口文檔工具，又有國內(nèi)開發(fā)者基于swagger-ui做了一套spring mvc的集成工具，通過注解就可以自動生成swagger-ui需要的接口定義json文件，用起來還比較方便，就是侵入性較強。

刪除swagger的jar包后問題，詭異的70+ms就消失了。

<!--pom 里刪除這兩個引用，這兩個包時國內(nèi)開發(fā)者封裝的，swagger-ui并沒有提供java spring-mvc的支持包，swagger只是一個瀏覽器端的ui+editor -->
<dependency>
    <groupId>io.springfox</groupId>
    <artifactId>springfox-swagger2</artifactId>
    <version>2.9.2</version>
</dependency>
<dependency>
    <groupId>io.springfox</groupId>
    <artifactId>springfox-swagger-ui</artifactId>
    <version>2.9.2</version>
</dependency>

那么為什么swagger會導致請求耗時呢，為什么每次請求偶讀會加載swagger內(nèi)部的靜態(tài)資源呢？

其實這是tomcat-embed的一個bug吧，下面詳細介紹一下該Bug。

Tomcat embed Bug分析&解決

源碼分析過程實在太漫長，而且也不是本文的重點，所以就不介紹了，下面直接介紹下分析結果：

順便貼一張tomcat處理請求的核心類圖：

圖片

為什么每次請求會加載Jar包內(nèi)的靜態(tài)資源

關鍵在于org.apache.catalina.mapper.Mapper#internalMapWrapper這個方法，該版本下處理請求的方式有問題，導致每次都校驗靜態(tài)資源。

為什么連續(xù)請求不會出現(xiàn)問題

因為Tomcat對于這種靜態(tài)資源的解析是有緩存的，優(yōu)先從緩存查找，緩存過期后再重新解析。具體參考org.apache.catalina.webresources.Cache，默認過期時間ttl是5000ms。

為什么本地不會復現(xiàn)

其實確切的說，是通過spring-boot打包插件后不能復現(xiàn)。由于啟動方式的不同，tomcat使用了不同的類去處理靜態(tài)資源，所以沒問題。

如何解決

升級tomcat-embed版本即可；

當前出現(xiàn)Bug的版本為：

spring-boot:2.0.2.RELEASE，內(nèi)置的tomcat embed版本為8.5.31；

升級tomcat embed版本至8.5.40+即可解決此問題，新版本已經(jīng)修復了。

通過替換springboot pom properties方式

如果項目是maven是繼承的springboot，即parent配置為springboot的，或者dependencyManagement中import spring boot包的；

<parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>2.0.2.RELEASE</version>
        <relativePath/> <!-- lookup parent from repository -->
    </parent>

pom中直接覆蓋properties即可：

<properties>
    <tomcat.version>8.5.40</tomcat.version>
</properties>

升級spring boot版本

springboot 2.1.0.RELEASE中的tomcat embed版本已經(jīng)大于8.5.31了，所以直接將springboot升級至該版本及以上版本就可以解決此問題。

責任編輯：武曉燕來源：碼猿技術專欄