作者：凡勇
什麼是壓測
壓測，即壓力測試，是確立系統穩定性的一種測試方法，通常在系統正常運作範圍之外進行，以考察其功能極限和和可能存在的隱患。
壓測主要用於檢測服務器的承受能力，包括用戶承受能力，即多少用戶同時使用系統時基本不影響質量、流量承受等。另外，通過諸如疲勞測試還能發現系統一些穩定性的問題，比如是否存在連接池中的連接被耗盡，內存被耗盡，線程池被耗盡，這些只能通過疲勞測試來進行發現定位。
爲什麼要壓測
壓測的目的就是通過模擬真實用戶的行爲，測算出機器的性能(單臺機器的 QPS、TPS)，從而推算出系統在承受指定用戶數(100 W)時，需要多少機器能支撐得住。因此在進行壓測時一定要事先設定壓測目標值，這個值不能太小，也不能太大，按照目前業務預估的增長量來做一個合理的評估。壓測是在上線前爲了應對未來可能達到的用戶數量的一次預估(提前演練)，壓測以後通過優化程序的性能或準備充足的機器，來保證用戶的體驗。壓測還能探測應用系統在出現交易洪峯時穩定性情況，以及可能出現的一些問題，發現應用系統薄弱一環，從而更有針對性地進行加強。
壓測分類
這幾種測試可以穿插進行，一般會在壓力測試性能指標達標後，再安排耐久性測試。
壓測名詞解釋
常見的壓測工具
ab
ApacheBench 是 Apache 服務器自帶的一個 web 壓力測試工具，簡稱 ab。ab 又是一個命令行工具，對發起負載的本機要求很低，根據 ab 命令可以創建很多的併發訪問線程，模擬多個訪問者同時對某一 URL 地址進行訪問，因此可以用來測試目標服務器的負載壓力。總的來說 ab 工具小巧簡單，上手學習較快，可以提供需要的基本性能指標，但是沒有圖形化結果，不能監控。
Jmeter
Apache JMeter 是 Apache 組織開發的基於 Java 的壓力測試工具。用於對軟件做壓力測試，它最初被設計用於 Web 應用測試，但後來擴展到其他測試領域。
JMeter 能夠對應用程序做功能/迴歸測試，通過創建帶有斷言的腳本來驗證你的程序返回了你期望的結果。
JMeter 的功能過於強大，這裏暫時不介紹用法，可以查詢相關文檔使用(參考文獻中有推薦的教程文檔)
LoadRunner
LoadRunner 是 HP(Mercury)公司出品的一個性能測試工具，功能非常強大，很多企業級客戶都在使用，具體請參考官網鏈接。
阿里雲PTS
性能測試 PTS（Performance Testing Service）是一款性能測試工具。支持按需發起壓測任務，可提供百萬併發、千萬 TPS 流量發起能力，100% 兼容 JMeter。提供的場景編排、API 調試、流量定製、流量錄製等功能，可快速創建業務壓測腳本，精準模擬不同量級用戶訪問業務系統，幫助業務快速提升系統性能和穩定性。
作爲阿里內部使用多年的性能測試工具，PTS 具備如下特性：
- 免運維、開箱即用。SaaS化施壓、最大支持百萬級併發、千萬級TPS流量自助發起能力。
- 支持多協議HTTP1.1/HTTP2/JDBC/MQTT/Kafka/RokectMq/Redis/Websocket/RMTP/HLS/TCP/UDP/SpringCloud/Dubbo/Grpc 等主流協議。
- 支持流量定製。全球施壓地域定製/運營商流量定製/IPv6 流量定製。
- 穩定、安全。阿里自研引擎、多年雙十一場景打磨、支持 VPC 網絡壓測。
- 性能壓測一站式解決方案。** 0 編碼構建複雜壓測場景，覆蓋壓測場景構建、壓測模型設定、發起壓力、分析定位問題、出壓測報告完整的壓測生命週期。
- 100% 兼容開源 JMeter。
- 提供安全、無侵入的生產環境寫壓測解決方案。
壓測工具的比較
如何選擇壓測工具
這個世界上沒有最好的工具，只有最適合的工具，工具千千萬，選擇一款適合你的纔是最重要的，在實際使用中有各種場景，讀者可以結合壓測步驟來確定適合自己的工具：
- 確定性能壓測目標：性能壓測目標可能源於項目計劃、業務方需求等
- 確定性能壓測環境：爲了儘可能發揮性能壓測作用，性能壓測環境應當儘可能同線上環境一致
- 確定性能壓測通過標準：針對性能壓測目標以及選取的性能壓測環境，制定性能壓測通過標準，對於不同於線上環境的性能壓測環境，通過標準也應當適度放寬
- 設計性能壓測：編排壓測鏈路，構造性能壓測數據，儘可能模擬真實的請求鏈路以及請求負載
- 執行性能壓測：藉助性能壓測工具，按照設計執行性能壓測
- 分析性能壓測結果報告：分析解讀性能壓測結果報告，判定性能壓測是否達到預期目標，若不滿足，要基於性能壓測結果報告分析原因
由上述步驟可知，一次成功的性能壓測涉及到多個環節，從場景設計到施壓再到分析，缺一不可。工欲善其事，必先利其器，而一款合適的性能工具意味着我們能夠在儘可能短的時間內完成一次合理的性能壓測，達到事半功倍的效果。
JAVA 應用性能問題排查指南
問題分類
問題形形色色，各種各樣的問題都會有。對其進行抽象和分類是非常必要的。這裏將從兩個維度來對性能問題進行分類。第一個維度是資源維度，第二個維度是頻率維度。
資源維度類的問題：CPU 衝高，內存使用不當，網絡過載。
頻率維度類的問題：交易持續性緩慢，交易偶發性緩慢。
對於每一類問題都有相應的解決辦法，方法或者工具使用不當，會導致不能快速而且精準地排查定位問題。
壓測性能問題定位調優是一門需要多方面綜合能力結合的一種技術工作，需要憑藉個人的技術能力、經驗、有時候還需要一些直覺和靈感，還需要一定的溝通能力，因爲有時候問題並不是由定位問題的人發現的，所以需要通過不斷地溝通來發現一些蛛絲馬跡。涉及的技術知識面遠不僅限於程序語言本身，還可能需要紮實的技術基本功，比如操作系統原理、網絡、編譯原理、JVM 等知識，決不只是簡單的瞭解，而是真正的掌握，比如 TCP/IP，必須得深入掌握。JVM 得深入掌握內存組成，內存模型，深入掌握 GC 的一些算法等。這也是一些初中級技術人員在一遇到性能問題就傻眼，完全不知道如何從哪裏下手。如果擁有紮實的技術基本功，再加上一些實戰經驗然後形成一套屬於自己的打法，在遇到問題後才能心中不亂，快速撥開迷霧，最終找到問題的癥結。
本文筆者還帶來了實際工作中定位和排查出來的一些典型的性能問題的案例，每個案例都會介紹問題發生的相關背景，一線人員提供的問題現象和初步排查定位結論，且在筆者介入後看到的問題現象，再配合一些常用的問題定位工具，介紹發現和定位問題的整個過程，問題發生的根本原因等。
分析思路框架
遇到一個性能問題，首先要從各種表象和一些簡單工具將問題進行定義和分類，然後再做進一步的定位分析，可以參考一下圖 1 作者總結出來的一個決策圖，這張圖是筆者從近幾個金融行業 ToB 項目中做性能定位調優過程的一個總結提練，不一定適合所有的問題，但至少覆蓋到了近幾個項目中遇到的性能問題的排查過程。在接下來的大篇幅中將對每一類問題進行展開，並附上一些真實的經典案例，這些案例都是真真實實發生的，有一定的代表性，且很多都是客戶定位了很長時間都沒發現問題根本原因的問題。其中 GC 類問題在此文不做過多分析，對於 GC 這一類問題後續有空寫一篇專門的文章來進行展開。
內存溢出
內存溢出問題按照問題發生頻率又可進一步分爲堆內存溢出、棧內存溢出、Metaspace 內存溢出以及 Native 內存溢出，下面對每種溢出情況進行詳細分析。
- 堆內存溢出
相信這類問題大家多多少少都接觸過，問題發生的根本原因就是應用申請的堆內存超過了 Xmx 參數設置的值，進而導致 JVM 基本處於一個不可用的狀態。如圖 2 所示，示例代碼模擬了堆內存溢出，運行時設置堆大小爲 1MB，運行後結果如圖3所示，拋出了一個 OutOfMemoryError 的錯誤異常，相應的 Message 是 Java heap space，代表溢出的部分是堆內存。
- 棧內存溢出
這類問題主要是由於方法調用深度太深，或者不正確的遞歸方法調用，又或者是 Xss 參數設置不當都會引發這個問題，如圖 4 所示，一個簡單的無限遞歸調用就會引發棧內存溢出，出錯結果如圖5所示，將會拋一個 StackOverflowError 的錯誤異常。Xss 參數可以設置每個線程棧內存最大大小，JDK8 的默認大小爲 1MB，正常情況下一般不需要去修改該參數，如果遇到 StackOverflowError 的報錯，那麼就需要留意了，需要查證是程序的問題還是參數設置的問題，如果確實是方法調用深度很深，默認的 1MB 不夠用，那麼就需要調高 Xss 參數。
- Native內存溢出
這種溢出發生在 JVM 使用堆外內存時，且超過一個進程所支持的最大的內存上限，或者堆外內存超過 MaxDirectMemorySize 參數指定的值時即會引發 Native 內存溢出。如圖 6 所示，需要配置 MaxDirectMemorySize 參數，如果不配置這個參數估計很難模擬出這個問題，作者的機器的 64 位的機器，堆外內存的大小可想而知了。運行該程序得到的運行結果如圖 7 所示，拋出來的異常也是 OutOfMemoryError，這個跟堆內存異常類似，但是 Message 是 Direct buffer memory，這個跟堆內存溢出的 Message 是不一樣的，請特別留意這條 Message，這對精準定位問題是非常重要的。
- Metaspace內存溢出
Metaspace 是在 JDK8 中才出現的，之前的版本中都叫 Perm 空間，大概用途都相差不大。模擬 Metaspace 溢出的方式很簡單，如圖 8 所示通過 cglib 不斷動態創建類並加載到 JVM，這些類信息就是保存在 Metaspace 內存裏面的，在這裏爲了快速模擬出問題，將 MaxMetaspaceSize 設置爲 10MB。執行結果如圖 9 所示，依然是拋出 OutOfMemoryError 的錯誤異常，但是 Message 變成了 Metaspace。
JVM 的內存溢出最常見的就這四種，如果能知道每一種內存溢出出現的原因，那麼就能快速而精準地進行定位。下面對一些遇到的真實的經典案例進行分析。
- 案例：堆外內存溢出
這種問題也比較好查，前提是在堆內存發生溢出時必須自動轉儲堆內存到文件中，如果壓測過程中通過 kill -3 或者 jmap 命令觸發堆內存轉儲。然後通過一些堆內存分析工具比如 IBM 的 Heap Analyzer 等工具找出是哪種對象佔用內存最多，最終可以把問題原因揪出來。
如果需要在發生 OOM 時自動轉儲堆內存，那麼需要在啓動參數中加入如下參數：
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/usr/local/oom
如果需要手工獲取線程轉儲或者內存轉儲，那麼請使用 kill -3 命令，或者使用 jstack 和 jmap 命令。
jstack -l pid > stackinfo，這條命令可以把線程信息轉儲到文本文件，把文件下載到本地然後用諸如 IBM Core file analyze 工具進行分析。
jmap -dump:format=b,file=./jmap.hprof pid，這條命令可以把堆內存信息到當前目錄的 jmap.hprof 文件中，下載到本地，然後用諸如 IBM Heap Analyze 等堆內存分析工具進行分析，根據二八定律，找準最耗內存的對象就可以解決 80% 的問題。
圖 10 就是一個真實發生的案例，該問題的發生現象是這樣的，壓測開始後，前十分鐘一切正常，但是在經歷大約十分鐘後，TPS 逐漸下降，直到後面客戶端的 TCP 連接都建不上去，客戶一度認爲是服務端Linux的網絡棧的參數設置有問題，導致 TCP 無法建連，給出的證據是，服務端存在大量的 TIME_WAIT 狀態的連接，然後要求調整Linux內核網絡參數，減少 TIME_WAIT 狀態的連接數。什麼是 TIME_WAIT？在這個時候就不得不祭出祖傳 TCP 狀態機的那張圖了，如圖 11 所示。對照這個圖就能知道 TIME_WAIT 的來朧去脈了，TIME_WAIT 主要出現在主動關閉連接方，當然了，如果雙方剛好同時關閉連接的時候，那麼雙方都會出現 TIME_WAIT 狀態。在進行關閉連接四路握手協議時，最後的 ACK 是由主動關閉端發出的，如果這個最終的 ACK 丟失，服務器將重發最終的 FIN，因此客戶端必須維護狀態信息以允許它重發最終的 ACK。如果不維持這個狀態信息，那麼客戶端將響應 RST 分節，服務器將此分節解釋成一個錯誤（在 java 中會拋出 connection reset的SocketException)。因而，要實現 TCP 全雙工連接的正常終止，必須處理終止序列四個分節中任何一個分節的丟失情況，主動關閉的客戶端必須維持狀態信息進入 TIME_WAIT 狀態。
圖 10 真實堆內存溢出案例一
圖 11 TCP 狀態機
順着客戶提供的這些信息，查了一下壓測客戶端，採用的是 HTTP 協議，keep-alive 爲開，而且採用的是連接池的方式與服務端進行交互，理論上在服務器端不應該出現如此之多的 TIME_WAIT 連接，猜測一種可能性是由於客戶側剛開始壓測的時候 TPS 比較高，佔用連接數多，後續性能下來後，連接數空閒且來不及跟服務端進行保活處理，導致連接被服務端給主動關閉掉了，但這也僅限於是猜測了。
爲了更精準地定位問題，決定去一線現場看下情況，在 TPS 嚴重往下掉的時候，通過 top、vmstat 等命令進行初步探測，發現 cpu 佔比並不十分高，大約 70% 左右。但是 JVM 佔用的內存已經快接近 Xmx 參數配置的值了，然後用 jstat -gcutil -h10 pid 5s 100 命令看一下 GC 情況，不查不知道一查嚇一跳，如圖 12 所示，初看這就是一份不太正常的 GC 數據，首先老年代佔比直逼 100%，然後 5 秒內居然進行了 7 次 FullGC，eden 區佔比 100%，因爲老年代已經滿了，年輕代的 GC 都已經停滯了，這明顯不正常，趁 JVM 還活着，趕緊執行 jmap -dump:format=b,file=./jmap.hprof pid，把整個堆文件快照拿下來，整整 5 個 G。取下來後通過 IBM 的 HeapAnalyzer 工具分析堆文件，結果如圖 10 所示，經過一番查找，發現某個對象佔比特別大，佔比達 98%，繼續追蹤持有對象，最終定位出問題，申請了某個資源，但是一直沒有釋放，修改後問題得到完美解決，後續再經過長達 8 個小時的耐久性測，沒能再發現問題，TPS 一直非常穩定。
圖 12 GC 情況統計分析
再來看看爲何會出現那麼多的 TIME_WAIT 連接，跟開始的猜測是一致的，由於大量的閒置連接被服務端主動關閉掉，所以纔會出現那麼多的 TIME_WAIT 狀態的連接。
CPU高
- 案例
某金融銀行客戶在壓測過程中發現一個問題，導致 TPS 極低，交易響應時長甚至接近驚人的 30S，嚴重不達票，服務響應時間如圖 23 所示，這是應用打的 tracer log，顯示的耗時很不樂觀。應用採用 SOFA 構建，部署在專有云容器上面，容器規格爲 4C8G，使用 OceanBase 數據庫。交易緩慢過程中客戶在相應容器裏面用 top、vmstat 命令獲取 OS 信息，發現內存使用正常，但是 CPU 接近 100%，通過 jstack 命令取線程轉儲文件，如圖 22 所示，客戶發現大量的線程都卡在了獲取數據庫連接上面，再上應用日誌中也報了大量的獲取 DB 連接失敗的錯誤日誌，這讓客戶以爲是連接池中的連接數不夠，所以不斷繼續加大 MaxActive 這個參數，DB 連接池使用的是 Druid，在加大參數後，性能沒有任何改善，且獲取不到連接的問題依舊。客戶在排查該問題大概兩週且沒有任何實質性進展後，開始向阿里 GTS 的同學求助。
筆者剛好在客戶現場，介入該性能問題的定位工作。跟客戶一番溝通，並查閱了了歷史定位信息記錄後，根據以往的經驗，這個問題肯定不是由於連接池中的最大連接數不夠的原因導致的，因爲這個時候客戶已經把 MaxActive 的參數已經調到了恐怖的 500，但問題依舊，在圖 22 中還能看到一些有用的信息，比如正在 Waiting 的線程高達 908 個，Runnable 的線程高達 295 個，都是很恐怖的數字，大量的線程處於 Runnable 狀態，CPU 忙着進行線程上下文的切換，CPU 呼呼地轉，但實際並沒有幹多少有實際有意義的事。後經詢問，客戶將 SOFA 的業務處理線程數調到了 1000，默認是 200。
圖 22 線程卡在獲取 DB 連接池中的連接
圖 23 交易緩慢截圖
查到這裏基本可以斷定客戶陷入了“頭痛醫頭，腳痛醫腳”，“治標不治本”的窘境，進一步跟客戶溝通後，果然如此。剛開始的時候，是由於 SOFA 報了線程池滿的錯誤，然後客戶不斷加碼 SOFA 業務線程池中最大線程數，最後加到了 1000，性能提升不明顯，然後報了一個獲取不到數據庫連接的錯誤，客戶又認爲這是數據庫連接不夠了，調高 Druid 的 MaxActive 參數，最後無論怎麼調性能也都上不來，甚至到後面把內存都快要壓爆了，如圖 24 所示，內存中被一些業務 DO 對象給填滿了，後面客戶一度以爲存在內存泄露。對於這類問題，只要像是出現了數據庫連接池不夠用、或者從連接池中獲取連接超時，又或者是線程池耗盡這類問題，只要參數設置是在合理的範圍，那麼十有八九就是交易本身處理太慢了。後面經過進一步的排查最終定位是某個 SQL 語句和內部的一些處理不當導致的交易緩慢。修正後，TPS 正常，最後把線程池最大大小參數、DB 連接池的參數都往回調成最佳實踐中推薦的值，再次壓測後，TPS 依然保持正常水平，問題得到最終解決。
圖 24 內存填滿了業務領域對象
這個案例一雖說是因爲 CPU 衝高且交易持續緩慢的這一類典型問題，但其實就這個案例所述的那樣，在定位和調優的時候很容易陷進一種治標不治本的困境，很容易被一些表象所迷惑。如何撥開雲霧見月明，筆者的看法是 5 分看經驗，1 分看靈感和運氣，還有 4 分得靠不斷分析。如果沒經驗怎麼辦？那就只能沉下心來分析相關性能文件，無論是線程轉儲文件還是 JFR，又或者其他採集工具採集到性能信息，反正不要放過任何蛛絲馬跡，最後實在沒轍了再請求經驗豐富的專家的協助排查解決。
- 使用 JMC+JFR 定位問題
如果超長問題偶然發生，這裏介紹一個比較簡單且非常實用的方法，使用 JMC+JFR，可以參考鏈接進行使用。但是使用前必須開啓 JMX 和 JFR 特性，需要在啓動修改啓動參數，具體參數如下，該參數不要帶入生產，另外如果將容器所屬宿主機的端口也暴露成跟 jmxremote.port 一樣的端口，如下示例爲 32433，那麼還可以使用 JConsole 或者 JVisualvm 工具實時觀察虛擬機的狀況，這裏不再做詳細介紹。
-Dcom.sun.management.jmxremote.port=32433
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.
authenticate=false
-XX:+UnlockCommercialFeatures -XX:+FlightRecorder
下面以一個實際的 JFR 實例爲例。
首先要開啓 JMX 和 JFR 功能，需要在啓動參數中加 JMX 開啓參數和 JFR 開啓參數，如上面所述，然後在容器裏面執行下述命令，執行後顯示“Started recording pid. The result will be written to xxxx”，即表示已經開始錄製，這個時候開始進行壓測，下述命令中的 duration 是 90 秒，也就表示會錄製 90S 後纔會停止錄製，錄製完後將文件下載到本地，用 jmc 工具進行分析，如果沒有這個工具，也可以使用 IDEA 進行分析。
jcmd pid JFR.start name=test duration=90s filename=output.jfr
通過分析火焰圖，具體怎麼看火焰圖請參考鏈接。通過這個圖可以看到主要的耗時是在哪個方法上面，給我們分析問題提供了很大的便利。
還可以查看 call tree，也能看出耗時主要發生在哪裏。
JMC 工具下載地址：JDK Mission Control (JMC) 8 Downloads (oracle.com)
最後再介紹一款工具，阿里巴巴開源的 arthas，也是性能分析和定位的一把利器，具體使用就不在這裏介紹了，可以參考 arthas 官網。
- 如何定位 CPU 耗時過高的線程及方法
首先找到 JAVA 進程的 PID，然後執行 top -H -p pid，這樣可以找到最耗時的線程，如下圖所示。然後使用 printf "%x\n" 17880，將線程號轉成 16 進制，最終通過這個 16 進制值去 jstack 線程轉儲文件中去查找是哪個線程佔用 CPU 最高。
其他問題案例
這類問題在發生的時候，JVM 表現得靜如止水，CPU 和內存的使用都在正常水位，但是交易就是緩慢，對於這一類問題可以參考 CPU 衝高類問題來進行解決，通過使用線程轉儲文件或者使用JFR來錄製一段 JVM 運行記錄。這類問題大概率的原因是由於大部分線程卡在某個 IO 或者被某個鎖個 Block 住了，下面也帶來一個真實的案例。
- 案例一
某金融保險頭部客戶，反應某個交易非常緩慢，經常響應時間在 10S 以上，應用部署在公有云的容器上，容器規格爲 2C4G，數據庫是 OceanBase。問題每次都能重現，通過分佈式鏈路工具只能定位到在某個服務上面慢，並不能精確定是卡在哪個方法上面。在交易緩慢期間，通過 top、vmstat 命令查看 OS 的狀態，CPU 和內存資源都在正常水位。因此，需要看在交易期間的線程的狀態。在交易執行緩慢期間，將交易的線程給轉儲出來，如圖 29 所示，可以定位相應的線程卡在哪個方法上面，案例中的線程卡在了執行 socket 讀數據階段，從堆棧可以斷定是卡在了讀數據庫上面了。如果這個方法依然不好用，那麼還可以藉助抓包方式來進行定位。
圖 29 交易被 hang 住示例圖
- 案例二
某金融銀行客戶壓測過程中發現 TPS 上不去，10TPS 不到，響應時間更是高到令人髮指，在經過一段時間的培訓賦能和磨合，該客戶已經具備些性能定位的能力。給反饋的信息是 SQL 執行時間、CPU 和內存使用一切正常，客戶打了一份線程轉儲文件，發現大多數線程都卡在了使用 RedissionLock 的分佈式鎖上面，如圖 30 所示，後經查是客戶沒有合理使用分佈式鎖導致的問題，解決後，TPS 翻了 20 倍。
圖 30 分佈式鎖使用不當導致的問題示例
這兩個案例其實都不算複雜，也很容易進行排查，放到這裏只是想重述一下排查這類問題的一個整體的思路和方法。如果交易緩慢且資源使用都正常，可以通過分析線程轉儲文件或者 JFR 文件來定位問題，這類問題一般是由於 IO 存在瓶頸，又或者被鎖 Block 住的原因導致的。
總結
問題千千萬，但只要修練了足夠深厚的內功，形成一套屬於自己的排查問題思路和打法，再加上一套支撐問題排查的工具，憑藉已有的經驗還有偶發到來的那一絲絲靈感，相信所有的問題都會迎刃而解。
更多交流，歡迎進釘釘羣溝通，PTS 用戶交流釘釘羣號：11774967。
此外，PTS 近期對售賣方式做了全新升級，基礎版價格直降 50%！5W 併發價格只需 199，免去自運維壓測平臺煩惱！更有新用戶 0.99 體驗版、VPC 壓測專屬版，歡迎大家選購！
點擊此處，前往官網查看更多！