Golang 中的 io 包詳解：組合接口
io.ReadWriter// ReadWriter is the interface that groups the basic Read and Write methods.type ReadWriter interface { Reader Writer}是對Reader和Writer接口的組合，
公司有個渠道系統，專門對接三方渠道使用，沒有什么業務邏輯，主要是轉換報文和參數校驗之類的工作，起著一個承上啟下的作用。
最近在優化接口的響應時間，優化了代碼之后，但是時間還是達不到要求；有一個詭異的100ms左右的耗時問題，在接口中打印了請求處理時間后，和調用方的響應時間還有差了100ms左右。比如程序里記錄150ms，但是調用方等待時間卻為250ms左右。
下面記錄下當時詳細的定位&解決流程（其實解決很簡單，關鍵在于怎么定位并找到解決問題的方法）。
渠道系統是一個常見的spring-boot web工程，使用了集成的tomcat。分析了代碼之后，發現并沒有特殊的地方，沒有特殊的過濾器或者攔截器，所以初步排除是業務代碼問題。
出現這個問題之后，首先確認了下接口的調用流程。由于是內部測試，所以調用流程較少。
Nginx -反向代理-> 渠道系統公司是云服務器，網絡走的也是云的內網。由于不明確問題的原因，所以用排除法，首先確認服務器網絡是否有問題。
先確認發送端到Nginx Host是否有問題：
[jboss@VM_0_139_centos ~]$ ping 10.0.0.139PING 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 ms64 bytes from 10.0.0.139: icmp_seq=2 ttl=64 time=0.041 ms64 bytes from 10.0.0.139: icmp_seq=3 ttl=64 time=0.040 ms64 bytes from 10.0.0.139: icmp_seq=4 ttl=64 time=0.040 ms從ping結果上看，發送端到Nginx主機的延遲是無問題的，接下來查看Nginx到渠道系統的網絡。
# 由于日志是沒問題的，這里直接復制上面日志了[jboss@VM_0_139_centos ~]$ ping 10.0.0.139PING 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 ms64 bytes from 10.0.0.139: icmp_seq=2 ttl=64 time=0.041 ms64 bytes from 10.0.0.139: icmp_seq=3 ttl=64 time=0.040 ms64 bytes from 10.0.0.139: icmp_seq=4 ttl=64 time=0.040 ms從ping結果上看，Nginx到渠道系統服務器網絡延遲也是沒問題的
既然網絡看似沒問題，那么可以繼續排除法，砍掉Nginx，客戶端直接再渠道系統的服務器上，通過回環地址（localhost）直連，避免經過網卡/dns，縮小問題范圍看看能否復現（這個應用和地址是我后期模擬的，測試的是一個空接口）：
[jboss@VM_10_91_centos tmp]$ curl -w "@curl-time.txt" http://127.0.0.1:7744/sendsuccess http: 200 dns: 0.001s redirect: 0.000s time_connect: 0.001s time_appconnect: 0.000s time_pretransfer: 0.001stime_starttransfer: 0.073s size_download: 7bytes speed_download: 95.000B/s ---------- time_total: 0.073s 請求總耗時從curl日志上看，通過回環地址調用一個空接口耗時也有73ms。這就奇怪了，跳過了中間所有調用節點（包括過濾器&攔截器之類），直接請求應用一個空接口，都有73ms的耗時，再請求一次看看：
[jboss@VM_10_91_centos tmp]$ curl -w "@curl-time.txt" http://127.0.0.1:7744/sendsuccess http: 200 dns: 0.001s redirect: 0.000s time_connect: 0.001s time_appconnect: 0.000s time_pretransfer: 0.001stime_starttransfer: 0.003s size_download: 7bytes speed_download: 2611.000B/s ---------- time_total: 0.003s更奇怪的是，第二次請求耗時就正常了，變成了3ms。經查閱資料，linux curl是默認開啟http keep-alive的。就算不開啟keep-alive，每次重新handshake，也不至于需要70ms。
經過不斷分析測試發現，連續請求的話時間就會很短，每次請求只需要幾毫秒，但是如果隔一段時間再請求，就會花費70ms以上。
從這個現象猜想，可能是某些緩存機制導致的，連續請求因為有緩存，所以速度快，時間長緩存失效后導致時間長。
那么這個問題點到底在哪一層呢？tomcat層還是spring-webmvc呢？
光猜想定位不了問題，還是得實際測試一下，把渠道系統的代碼放到本地ide里啟動測試能否復現。
但是導入本地Ide后，在Ide中啟動后并不能復現問題，并沒有70+ms的延遲問題。這下頭疼了，本地無法復現，不能Debug，由于問題點不在業務代碼，也不能通過加日志的方式來Debug。
這時候可以祭出神器Arthas了。
Arthas 是Alibaba開源的Java診斷工具，深受開發者喜愛。當你遇到以下類似問題而束手無策時，Arthas可以幫助你解決：
上面是Arthas的官方簡介，這次我只需要用他的一個小功能trace。動態計算方法調用路徑和時間，這樣我就可以定位時間在哪個地方被消耗了。
有了神器，那么該追蹤什么方法呢？由于我對Tomcat源碼不是很熟，所以只能從spring mvc下手，先來trace一下spring mvc的入口：
圖片
圖片
圖片
[jboss@VM_10_91_centos tmp]$ curl -w "@curl-time.txt" http://127.0.0.1:7744/sendsuccess http: 200 dns: 0.001s redirect: 0.000s time_connect: 0.001s time_appconnect: 0.000s time_pretransfer: 0.001stime_starttransfer: 0.115s size_download: 7bytes speed_download: 60.000B/s ---------- time_total: 0.115s本次調用，調用端時間花費115ms，但是從arthas trace上看，spring mvc只消耗了18ms，那么剩下的97ms去哪了呢？
本地測試后已經可以排除spring mvc的問題了，最后也是唯一可能出問題的點就是tomcat。
可是本人并不熟悉tomcat中的源碼，就連請求入口都不清楚，tomcat里需要trace的類都不好找......
不過沒關系，有神器Arthas，可以通過stack命令來反向查找調用路徑，以org.springframework.web.servlet.DispatcherServlet作為參數：
stack 輸出當前方法被調用的調用路徑。
很多時候我們都知道一個方法被執行，但這個方法被執行的路徑非常多，或者你根本就不知道這個方法是從那里被執行了，此時你需要的是 stack 命令。
圖片
圖片
圖片
圖片
從stack日志上可以很直觀的看出DispatchServlet的調用棧，那么這么長的路徑，該trace哪個類呢（這里跳過spring mvc中的過濾器的trace過程，實際排查的時候也trace了一遍，但這詭異的時間消耗不是由這里過濾器產生的）？
有一定經驗的老司機從名字上大概也能猜出來從哪里下手比較好，那就是org.apache.coyote.http11.Http11Processor.service，從名字上看，http1.1處理器，這可能是一個比較好的切入點。下面來trace一下：
圖片
圖片
日志里有一個129ms的耗時點（時間比沒開arthas的時候更長是因為arthas本身帶來的性能消耗，所以生產環境小心使用），這個就是要找的問題點。
打問題點找到了，那怎么定位是什么導致的問題呢，又如何解決呢？
繼續trace吧，細化到具體的代碼塊或者內容。trace由于性能考慮，不會展示所有的調用路徑，如果調用路徑過深，只有手動深入trace，原則就是trace耗時長的那個方法：
圖片
一段無聊的手動深入trace之后……
圖片
發現了一個值得暫停思考的點：
+---[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包內的某些資源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包內META-INF/，META-INF/MANIFEST的資源，這是一個子類，更多的功能在父類JarInputStream里。
其實看到這里大概也能猜到問題了，tomcat加載jar包內META-INF/，META-INF/MANIFEST的資源導致的耗時，至于為什么連續請求不會耗時，應該是tomcat的緩存機制（下面介紹源碼分析）。
不著急定位問題，試著通過Arthas最終定位問題細節，繼續手動深入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日志，刪減了剩下的從方法名上看，還是加載資源之類的意思。都已經到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參數，從注釋上看，是jar/zip文件名，如果能得到文件名這種關鍵信息，就可以直接定位問題了；還是通過Arthas，使用watch命令，動態監測方法調用數據。
讓你能方便的觀察到指定方法的調用情況。能觀察到的范圍為：返回值、拋出異常、入參，通過編寫 OGNL 表達式進行對應變量的查看。
這下直接看到了具體加載的資源名，這么熟悉的名字：swagger-ui，一個國外的rest接口文檔工具，又有國內開發者基于swagger-ui做了一套spring mvc的集成工具，通過注解就可以自動生成swagger-ui需要的接口定義json文件，用起來還比較方便，就是侵入性較強。
刪除swagger的jar包后問題，詭異的70+ms就消失了。
<!--pom 里刪除這兩個引用，這兩個包時國內開發者封裝的，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內部的靜態資源呢？
其實這是tomcat-embed的一個bug吧，下面詳細介紹一下該Bug。
源碼分析過程實在太漫長，而且也不是本文的重點，所以就不介紹了， 下面直接介紹下分析結果：
順便貼一張tomcat處理請求的核心類圖：
圖片
關鍵在于org.apache.catalina.mapper.Mapper#internalMapWrapper這個方法，該版本下處理請求的方式有問題，導致每次都校驗靜態資源。
因為Tomcat對于這種靜態資源的解析是有緩存的，優先從緩存查找，緩存過期后再重新解析。具體參考org.apache.catalina.webresources.Cache，默認過期時間ttl是5000ms。
其實確切的說，是通過spring-boot打包插件后不能復現。由于啟動方式的不同，tomcat使用了不同的類去處理靜態資源，所以沒問題。
升級tomcat-embed版本即可；
當前出現Bug的版本為：
spring-boot:2.0.2.RELEASE，內置的tomcat embed版本為8.5.31；
升級tomcat embed版本至8.5.40+即可解決此問題，新版本已經修復了。
如果項目是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>springboot 2.1.0.RELEASE中的tomcat embed版本已經大于8.5.31了，所以直接將springboot升級至該版本及以上版本就可以解決此問題。
本文鏈接：http://www.tebozhan.com/showinfo-26-92138-0.html用 Arthas 定位 Spring Boot 接口的超時問題，讓應用起飛！
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號