Java 應用效能調優最強實踐指南！

作者：張俊城, 郭理勇, 劉建

Java 應用效能最佳化是一個老生常談的話題，典型的效能問題如頁面響應慢、介面超時，伺服器負載高、併發數低，資料庫頻繁死鎖等。尤其是在“糙快猛”的網際網路開發模式大行其道的今天，隨著系統訪問量的日益增加和程式碼的臃腫，各種效能問題開始紛至沓來。

Java 應用效能的瓶頸點非常多，比如磁碟、記憶體、網路 I/O 等系統因素，Java 應用程式碼，JVM GC，資料庫，快取等。筆者根據個人經驗，將 Java 效能最佳化分為 4 個層級：應用層、資料庫層、框架層、JVM 層，如圖 1 所示。

圖 1.Java 效能最佳化分層模型

每層最佳化難度逐級增加，涉及的知識和解決的問題也會不同。比如應用層需要理解程式碼邏輯，透過 Java 執行緒棧定位有問題程式碼行等；資料庫層面需要分析 SQL、定位死鎖等；框架層需要懂原始碼，理解框架機制；JVM 層需要對 GC 的型別和工作機制有深入瞭解，對各種 JVM 引數作用瞭然於胸。

圍繞 Java 效能最佳化，有兩種最基本的分析方法：現場分析法和事後分析法。

現場分析法透過保留現場，再採用診斷工具分析定位。現場分析對線上影響較大，部分場景（特別是涉及到使用者關鍵的線上業務時）不太合適。

事後分析法需要儘可能多收集現場資料，然後立即恢復服務，同時針對收集的現場資料進行事後分析和復現。下面我們從效能診斷工具出發，分享一些案例與實踐。

效能診斷一種是針對已經確定有效能問題的系統和程式碼進行診斷，還有一種是對預上線系統提前效能測試，確定效能是否符合上線要求。

本文主要針對前者，後者可以用各種效能壓測工具（例如 JMeter）進行測試，不在本文討論範圍內。

針對 Java 應用，效能診斷工具主要分為兩層：OS 層面和 Java 應用層面（包括應用程式碼診斷和 GC 診斷）。

OS 診斷

OS 的診斷主要關注的是 CPU、Memory、I/O 三個方面。

對於 CPU 主要關注平均負載（Load Average），CPU 使用率，上下文切換次數（Context Switch）。

透過 top 命令可以檢視系統平均負載和 CPU 使用率，圖 2 為透過 top 命令檢視某系統的狀態。

圖 2.top 命令示例

平均負載有三個數字：63.66，58.39，57.18，分別表示過去 1 分鐘、5 分鐘、15 分鐘機器的負載。按照經驗，若數值小於 0.7*CPU 個數，則系統工作正常；若超過這個值，甚至達到 CPU 核數的四五倍，則系統的負載就明顯偏高。

圖 2 中 15 分鐘負載已經高達 57.18，1 分鐘負載是 63.66（系統為 16 核），說明系統出現負載問題，且存在進一步升高趨勢，需要定位具體原因了。

透過 vmstat 命令可以檢視 CPU 的上下文切換次數，如圖 3 所示：

圖 3.vmstat 命令示例

上下文切換次數發生的場景主要有如下幾種：

• 1）時間片用完，CPU 正常排程下一個任務；

• 2）被其它優先順序更高的任務搶佔；

• 3）執行任務碰到 I/O 阻塞，掛起當前任務，切換到下一個任務；

• 4）使用者程式碼主動掛起當前任務讓出 CPU；

• 5）多工搶佔資源，由於沒有搶到被掛起；

• 6）硬體中斷。

Java 執行緒上下文切換主要來自共享資源的競爭。一般單個物件加鎖很少成為系統瓶頸，除非鎖粒度過大。但在一個訪問頻度高，對多個物件連續加鎖的程式碼塊中就可能出現大量上下文切換，成為系統瓶頸。

比如在我們系統中就曾出現 log4j 1.x 在較大併發下大量列印日誌，出現頻繁上下文切換，大量執行緒阻塞，導致系統吞吐量大降的情況，其相關程式碼如清單 1 所示，升級到 log4j 2.x 才解決這個問題。

for(Category c = this; c != null; c=c.parent) {
 // Protected against simultaneous call to addAppender, removeAppender,…
 synchronized(c) {
 if (c.aai != null) {
 write += c.aai.appendLoopAppenders(event);
 }
 …
 }
}

從作業系統角度，記憶體關注應用程式是否足夠，可以使用 free –m 命令檢視記憶體的使用情況。

透過 top 命令可以檢視程式使用的虛擬記憶體 VIRT 和實體記憶體 RES，根據公式 VIRT = SWAP + RES 可以推算出具體應用使用的交換分割槽（Swap）情況，使用交換分割槽過大會影響 Java 應用效能，可以將 swappiness 值調到儘可能小。

因為對於 Java 應用來說，佔用太多交換分割槽可能會影響效能，畢竟磁碟效能比記憶體慢太多。

I/O 包括磁碟 I/O 和網路 I/O，一般情況下磁碟更容易出現 I/O 瓶頸。透過 iostat 可以檢視磁碟的讀寫情況，透過 CPU 的 I/O wait 可以看出磁碟 I/O 是否正常。

如果磁碟 I/O 一直處於很高的狀態，說明磁碟太慢或故障，成為了效能瓶頸，需要進行應用最佳化或者磁碟更換。

除了常用的 top、 ps、vmstat、iostat 等命令，還有其他 Linux 工具可以診斷系統問題，如 mpstat、tcpdump、netstat、pidstat、sar 等。Brendan 總結列出了 Linux 不同裝置型別的效能診斷工具，如圖 4 所示，可供參考。

圖 4.Linux 效能觀測工具

應用程式碼效能問題是相對好解決的一類效能問題。透過一些應用層面監控報警，如果確定有問題的功能和程式碼，直接透過程式碼就可以定位；或者透過 top+jstack，找出有問題的執行緒棧，定位到問題執行緒的程式碼上，也可以發現問題。對於更復雜，邏輯更多的程式碼段，透過 Stopwatch 列印效能日誌往往也可以定位大多數應用程式碼效能問題。

常用的 Java 應用診斷包括執行緒、堆疊、GC 等方面的診斷。

jstack

jstack 命令通常配合 top 使用，透過 top -H -p pid 定位 Java 程式和執行緒，再利用 jstack -l pid 匯出執行緒棧。由於執行緒棧是瞬態的，因此需要多次 dump，一般 3 次 dump，一般每次隔 5s 就行。將 top 定位的 Java 執行緒 pid 轉成 16 進位制，得到 Java 執行緒棧中的 nid，可以找到對應的問題執行緒棧。

圖 5. 透過 top –H -p 檢視執行時間較長 Java 執行緒

如圖 5 所示，其中的執行緒 24985 執行時間較長，可能存在問題，轉成 16 進位制後，透過 Java 執行緒棧找到對應執行緒 0x6199 的棧如下，從而定位問題點，如圖 6 所示。

圖 6.jstack 檢視執行緒堆疊

JProfiler

JProfiler 可對 CPU、堆、記憶體進行分析，功能強大，如圖 7 所示。同時結合壓測工具，可以對程式碼耗時取樣統計。

圖 7. 透過 JProfiler 進行記憶體分析

Java GC 解決了程式設計師管理記憶體的風險，但 GC 引起的應用暫停成了另一個需要解決的問題。JDK 提供了一系列工具來定位 GC 問題，比較常用的有 jstat、jmap，還有第三方工具 MAT 等。

jstat

jstat 命令可列印 GC 詳細資訊，Young GC 和 Full GC 次數，堆資訊等。其命令格式為

jstat –gcxxx -t pid <interval> <count>，如圖 8 所示。

圖 8.jstat 命令示例

jmap

jmap 列印 Java 程式堆資訊 jmap –heap pid。透過 jmap –dump:file=xxx pid 可 dump 堆到檔案，然後透過其它工具進一步分析其堆使用情況

MAT

MAT 是 Java 堆的分析利器，提供了直觀的診斷報告，內建的 OQL 允許對堆進行類 SQL 查詢，功能強大，outgoing reference 和 incoming reference 可以對物件引用追根溯源。

圖 9.MAT 示例

圖 9 是 MAT 使用示例，MAT 有兩列顯示物件大小，分別是 Shallow size 和 Retained size，前者表示物件本身佔用記憶體的大小，不包含其引用的物件，後者是物件自己及其直接或間接引用的物件的 Shallow size 之和，即該物件被回收後 GC 釋放的記憶體大小，一般說來關注後者大小即可。

對於有些大堆 (幾十 G) 的 Java 應用，需要較大記憶體才能開啟 MAT。

通常本地開發機記憶體過小，是無法開啟的，建議線上下伺服器端安裝圖形環境和 MAT，遠端開啟檢視。或者執行 mat 命令生成堆索引，複製索引到本地，不過這種方式看到的堆資訊有限。

為了診斷 GC 問題，建議在 JVM 引數中加上-XX:+PrintGCDateStamps。常用的 GC 引數如圖 10 所示。

圖 10. 常用 GC 引數

對於 Java 應用，透過 top+jstack+jmap+MAT 可以定位大多數應用和記憶體問題，可謂必備工具。有些時候，Java 應用診斷需要參考 OS 相關資訊，可使用一些更全面的診斷工具，比如 Zabbix（整合了 OS 和 JVM 監控）等。在分散式環境中，分散式跟蹤系統等基礎設施也對應用效能診斷提供了有力支援。

在介紹了一些常用的效能診斷工具後，下面將結合我們在 Java 應用調優中的一些實踐，從 JVM 層、應用程式碼層以及資料庫層進行案例分享。

JVM 調優：GC 之痛

XX商業平臺某系統重構時選擇 RMI 作為內部遠端呼叫協議，系統上線後開始出現週期性的服務停止響應，暫停時間由數秒到數十秒不等。透過觀察 GC 日誌，發現服務自啟動後每小時會出現一次 Full GC。由於系統堆設定較大，Full GC 一次暫停應用時間會較長，這對線上實時服務影響較大。

經過分析，在重構前系統沒有出現定期 Full GC 的情況，因此懷疑是 RMI 框架層面的問題。透過公開資料，發現 RMI 的 GDC（Distributed Garbage Collection，分散式垃圾收集）會啟動守護執行緒定期執行 Full GC 來回收遠端物件，清單 2 中展示了其守護執行緒程式碼。

清單 2.DGC 守護執行緒原始碼

private static class Daemon extends Thread {
 public void run() {
 for (;;) { 
     //…
 long d = maxObjectInspectionAge();
 if (d >= l) {
    System.gc(); 
 d = 0;
 }
 //…
 }
     }
}

定位問題後解決起來就比較容易了。一種是透過增加-XX:+DisableExplicitGC 引數，直接禁用系統 GC 的顯示呼叫，但對使用 NIO 的系統，會有堆外記憶體溢位的風險。

另一種方式是透過調大 -Dsun.rmi.dgc.server.gcInterval 和-Dsun.rmi.dgc.client.gcInterval 引數，增加 Full GC 間隔，同時增加引數-XX:+ExplicitGCInvokesConcurrent，將一次完全 Stop-The-World 的 Full GC 調整為一次併發 GC 週期，減少應用暫停時間，同時對 NIO 應用也不會造成影響。

從圖 11 可知，調整之後的 Full GC 次數 在 3 月之後明顯減少。

圖 11.Full GC 監控統計

GC 調優對高併發大資料量互動的應用還是很有必要的，尤其是預設 JVM 引數通常不滿足業務需求，需要進行專門調優。GC 日誌的解讀有很多公開的資料，本文不再贅述。

GC 調優目標基本有三個思路：降低 GC 頻率，可以透過增大堆空間，減少不必要物件生成；降低 GC 暫停時間，可以透過減少堆空間，使用 CMS GC 演算法實現；避免 Full GC，調整 CMS 觸發比例，避免 Promotion Failure 和 Concurrent mode failure（老年代分配更多空間，增加 GC 執行緒數加快回收速度），減少大物件生成等。

應用層調優：嗅到程式碼的壞味道

從應用層程式碼調優入手，剖析程式碼效率下降的根源，無疑是提高 Java 應用效能的很好的手段之一。

某商業廣告系統（採用 Nginx 進行負載均衡）某次日常上線後，其中有幾臺機器負載急劇升高，CPU 使用率迅速打滿。我們對線上進行了緊急回滾，並透過 jmap 和 jstack 對其中某臺伺服器的現場進行儲存。

圖 12. 透過 MAT 分析堆疊現場

堆疊現場如圖 12 所示，根據 MAT 對 dump 資料的分析，發現最多的記憶體物件為 byte[] 和 java.util.HashMap $Entry，且 java.util.HashMap $Entry 物件存在迴圈引用。初步定位在該 HashMap 的 put 過程中有可能出現了死迴圈問題（圖中 java.util.HashMap $Entry 0x2add6d992cb8 和 0x2add6d992ce8 的 next 引用形成迴圈）。

查閱相關文件定位這屬於典型的併發使用的場景錯誤 () ，簡要的說就是 HashMap 本身並不具備多執行緒併發的特性，在多個執行緒同時 put 操作的情況下，內部陣列進行擴容時會導致 HashMap 的內部連結串列形成環形結構，從而出現死迴圈。

針對此次上線，最大的改動在於透過記憶體快取網站資料來提升系統效能，同時使用了懶載入機制，如清單 3 所示。

清單 3. 網站資料懶載入程式碼

private static Map<Long, UnionDomain> domainMap = new HashMap<Long, UnionDomain>();
    private boolean isResetDomains() {
        if (CollectionUtils.isEmpty(domainMap)) {
            // 從遠端 http 介面獲取網站詳情
            List<UnionDomain> newDomains = unionDomainHttpClient
                    .queryAllUnionDomain();
            if (CollectionUtils.isEmpty(domainMap)) {
                domainMap = new HashMap<Long, UnionDomain>();
                for (UnionDomain domain : newDomains) {
                    if (domain != null) {
                        domainMap.put(domain.getSubdomainId(), domain);
                    }
                }
            }
            return true;
        }
        return false;
    }

可以看到此處的 domainMap 為靜態共享資源，它是 HashMap 型別，在多執行緒情況下會導致其內部連結串列形成環形結構，出現死迴圈。

透過對前端 Nginx 的連線和訪問日誌可以看到，由於在系統重啟後 Nginx 積攢了大量的使用者請求，在 Resin 容器啟動，大量使用者請求湧入應用系統，多個使用者同時進行網站資料的請求和初始化工作，導致 HashMap 出現併發問題。在定位故障原因後解決方法則比較簡單，主要的解決方法有：

• （1）採用 ConcurrentHashMap 或者同步塊的方式解決上述併發問題;

• （2）在系統啟動前完成網站快取載入，去除懶載入等；

• （3）採用分散式快取替換本地快取等。

對於壞程式碼的定位，除了常規意義上的程式碼審查外，藉助諸如 MAT 之類的工具也可以在一定程度對系統效能瓶頸點進行快速定位。但是一些與特定場景繫結或者業務資料繫結的情況，卻需要輔助程式碼走查、效能檢測工具、資料模擬甚至線上引流等方式才能最終確認效能問題的出處。以下是我們總結的一些壞程式碼可能的一些特徵，供大家參考：

• （1）程式碼可讀性差，無基本程式設計規範；

• （2）物件生成過多或生成大物件，記憶體洩露等；

• （3）IO 流操作過多，或者忘記關閉；

• （4）資料庫操作過多，事務過長;

• （5）同步使用的場景錯誤;

• （6）迴圈迭代耗時操作等。

資料庫層調優：死鎖噩夢

對於大部分 Java 應用來說，與資料庫進行互動的場景非常普遍，尤其是 OLTP 這種對於資料一致性要求較高的應用，資料庫的效能會直接影響到整個應用的效能。搜狗商業平臺系統作為廣告主的廣告發布和投放平臺，對其物料的實時性和一致性都有極高的要求，我們在關係型資料庫最佳化方面也積累了一定的經驗。

對於廣告物料庫來說，較高的操作頻繁度（特別是透過批次物料工具操作）很極易造成資料庫的死鎖情況發生，其中一個比較典型的場景是廣告物料調價。客戶往往會頻繁的對物料的出價進行調整，從而間接給資料庫系統造成較大的負載壓力，也加劇了死鎖發生的可能性。下面以搜狗商業平臺某廣告系統廣告物料調價的案例進行說明。

某商業廣告系統某天訪問量突增，造成系統負載升高以及資料庫頻繁死鎖，死鎖語句如圖 13 所示。

圖 13. 死鎖語句

其中，groupdomain 表上索引為 idx_groupdomain_accountid (accountid)，idx_groupdomain_groupid(groupid)，primary(groupdomainid) 三個單索引結構，採用 Mysql innodb 引擎。

此場景發生在更新組出價時，場景中存在著組、組行業（groupindus 表）和組網站（groupdomain 表）。

當更新組出價時，若組行業出價使用組出價（透過 isusegroupprice 標示，若為 1 則使用組出價）。同時若組網站出價使用組行業出價（透過 isuseindusprice 標示，若為 1 則使用組行業出價）時，也需要同時更新其組網站出價。由於每個組下面最大可以有 3000 個網站，因此在更新組出價時會長時間的對相關記錄進行鎖定。

從上面發生死鎖的問題可以看到，事務 1 和事務 2 均選擇了 idx_groupdomain_accountid 的單列索引。根據 Mysql innodb 引擎加鎖的特點，在一次事務中只會選擇一個索引使用，而且如果一旦使用二級索引進行加鎖後，會嘗試將主鍵索引進行加鎖。進一步分析可知事務 1 在請求事務 2 持有的`idx_groupdomain_accountid`二級索引加鎖（加鎖範圍“space id 5726 page no 8658 n bits 824 index”），但是事務 2 已獲得該二級索引 (“space id 5726 page no 8658 n bits 824 index”) 上所加的鎖，在等待請求鎖定主鍵索引 PRIMARY 索引上的鎖。由於事務 2 等待執行時間過長或長時間不釋放鎖，導致事務 1 最終發生回滾。

透過對當天訪問日誌跟蹤可以看到，當天有客戶透過指令碼方式發起大量的修改推廣組出價的操作，導致有大量事務在迴圈等待前一個事務釋放鎖定的主鍵 PRIMARY 索引。該問題的根源實際上在於 Mysql innodb 引擎對於索引利用有限，在 Oracle 資料庫中此問題並不突出。

解決的方式自然是希望單個事務鎖定的記錄數越少越好，這樣產生死鎖的機率也會大大降低。最終使用了（accountid, groupid）的複合索引，縮小了單個事務鎖定的記錄條數，也實現了不同計劃下的推廣組資料記錄的隔離，從而減少該類死鎖的發生機率。

通常來說，對於資料庫層的調優我們基本上會從以下幾個方面出發：

（1）在 SQL 語句層面進行最佳化：慢 SQL 分析、索引分析和調優、事務拆分等；

（2）在資料庫配置層面進行最佳化：比如欄位設計、調整快取大小、磁碟 I/O 等資料庫引數最佳化、資料碎片整理等；

（3）從資料庫結構層面進行最佳化：考慮資料庫的垂直拆分和水平拆分等；

（4）選擇合適的資料庫引擎或者型別適應不同場景，比如考慮引入 NoSQL 等。

效能調優同樣遵循 2-8 原則，80%的效能問題是由 20%的程式碼產生的，因此最佳化關鍵程式碼事半功倍。同時，對效能的最佳化要做到按需最佳化，過度最佳化可能引入更多問題。對於 Java 效能最佳化，不僅要理解系統架構、應用程式碼，同樣需要關注 JVM 層甚至作業系統底層。總結起來主要可以從以下幾點進行考慮：

1）基礎效能的調優

這裡的基礎效能指的是硬體層級或者作業系統層級的升級最佳化，比如網路調優，作業系統版本升級，硬體裝置最佳化等。比如 F5 的使用和 SDD 硬碟的引入，包括新版本 Linux 在 NIO 方面的升級，都可以極大的促進應用的效能提升；

2）資料庫效能最佳化

包括常見的事務拆分，索引調優，SQL 最佳化，NoSQL 引入等，比如在事務拆分時引入非同步化處理，最終達到一致性等做法的引入，包括在針對具體場景引入的各類 NoSQL 資料庫，都可以大大緩解傳統資料庫在高併發下的不足；

3）應用架構最佳化

引入一些新的計算或者儲存框架，利用新特性解決原有叢集計算效能瓶頸等；或者引入分散式策略，在計算和儲存進行水平化，包括提前計算預處理等，利用典型的空間換時間的做法等；都可以在一定程度上降低系統負載；

4）業務層面的最佳化

技術並不是提升系統效能的唯一手段，在很多出現效能問題的場景中，其實可以看到很大一部分都是因為特殊的業務場景引起的，如果能在業務上進行規避或者調整，其實往往是最有效的。