背景

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

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

下面記錄下當(dāng)時(shí)詳細(xì)的定位&解決流程（其實(shí)解決很簡單，關(guān)鍵在于怎么定位并找到解決問題的方法）

定位過程

分析代碼

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

分析調(diào)用流程

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

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

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

先確認(rèn)發(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結(jié)果上看，發(fā)送端到Nginx主機(jī)的延遲是無問題的，接下來查看Nginx到渠道系統(tǒng)的網(wǎng)絡(luò)。

# 由于日志是沒問題的，這里直接復(fù)制上面日志了
[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結(jié)果上看，Nginx到渠道系統(tǒng)服務(wù)器網(wǎng)絡(luò)延遲也是沒問題的。

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

[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 請求總耗時(shí)

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

[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

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

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

從這個現(xiàn)象猜想，可能是某些緩存機(jī)制導(dǎo)致的，連續(xù)請求因?yàn)橛芯彺妫运俣瓤?，時(shí)間長緩存失效后導(dǎo)致時(shí)間長。

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

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

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

這時(shí)候可以祭出神器Arthas了

Arthas分析問題

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

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

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

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

有了神器，那么該追蹤什么方法呢？由于我對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

本次調(diào)用，調(diào)用端時(shí)間花費(fèi)115ms，但是從arthas trace上看，spring mvc只消耗了18ms，那么剩下的97ms去哪了呢？

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

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

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

stack 輸出當(dāng)前方法被調(diào)用的調(diào)用路徑。

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

圖片

圖片

圖片

圖片

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

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

圖片

圖片

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

打問題點(diǎn)找到了，那怎么定位是什么導(dǎo)致的問題呢，又如何解決呢？

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

圖片

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

圖片

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

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

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

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里。

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

不著急定位問題，試著通過Arthas最終定位問題細(xì)節(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)到j(luò)dk源碼了，這時(shí)候來看一下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文件名，如果能得到文件名這種關(guān)鍵信息，就可以直接定位問題了；還是通過Arthas，使用watch命令，動態(tài)監(jiān)測方法調(diào)用數(shù)據(jù)

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

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

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

圖片

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

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

<!--pom 里刪除這兩個引用，這兩個包時(shí)國內(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會導(dǎo)致請求耗時(shí)呢，為什么每次請求偶讀會加載swagger內(nèi)部的靜態(tài)資源呢？

其實(shí)這是tomcat-embed的一個bug吧，下面詳細(xì)介紹一下該Bug

Tomcat embed Bug分析&解決

源碼分析過程實(shí)在太漫長，而且也不是本文的重點(diǎn)，所以就不介紹了， 下面直接介紹下分析結(jié)果

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

圖片

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

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

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

因?yàn)門omcat對于這種靜態(tài)資源的解析是有緩存的，優(yōu)先從緩存查找，緩存過期后再重新解析。具體參考o(jì)rg.apache.catalina.webresources.Cache，默認(rèn)過期時(shí)間ttl是5000ms。

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

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

如何解決

升級tomcat-embed版本即可

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

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

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

通過替換springboot pom properties方式

如果項(xiàng)目是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升級至該版本及以上版本就可以解決此問題