1、調優原則

JVM調優聽起來很高大上，但是要認識到，JVM調優應該是Java性能優化的最后一顆子彈，

比較認可廖雪峰老師的觀點，要認識到JVM調優不是常規手段，性能問題一般第一選擇是優化程式，最后的選擇才是進行JVM調優，

JVM的自動記憶體管理本來就是為了將開發人員從記憶體管理的泥潭里拉出來，即使不得不進行JVM調優，也絕對不能拍腦門就去調整引數，一定要全面監控，詳細分析性能資料，

2、JVM調優的時機

不得不考慮進行JVM調優的是那些情況呢？

• Heap記憶體（老年代）持續上漲達到設定的最大記憶體值；
• Full GC 次數頻繁；
• GC 停頓時間過長（超過1秒）；
• 應用出現OutOfMemory 等記憶體例外；
• 應用中有使用本地快取且占用大量記憶體空間；
• 系統吞吐量與回應性能不高或下降，

3、JVM調優的目標

吞吐量、延遲、記憶體占用三者類似CAP，構成了一個不可能三角，只能選擇其中兩個進行調優，不可三者兼得，

• 延遲：GC低停頓和GC低頻率；
• 低記憶體占用；
• 高吞吐量;

選擇了其中兩個，必然會會以犧牲另一個為代價，

下面展示了一些JVM調優的量化目標參考實體：

• Heap 記憶體使用率 <= 70%;
• Old generation記憶體使用率<= 70%;
• avgpause <= 1秒;
• Full gc 次數0 或 avg pause interval >= 24小時 ;

注意：不同應用的JVM調優量化目標是不一樣的，

4、JVM調優的步驟

一般情況下，JVM調優可通過以下步驟進行：

• 分析系統系統運行情況：分析GC日志及dump檔案，判斷是否需要優化，確定瓶頸問題點；
• 確定JVM調優量化目標；
• 確定JVM調優引數（根據歷史JVM引數來調整）；
• 依次確定調優記憶體、延遲、吞吐量等指標；
• 對比觀察調優前后的差異；
• 不斷的分析和調整，直到找到合適的JVM引數配置；
• 找到最合適的引數，將這些引數應用到所有服務器，并進行后續跟蹤，

以上操作步驟中，某些步驟是需要多次不斷迭代完成的，一般是從滿足程式的記憶體使用需求開始的，之后是時間延遲的要求，最后才是吞吐量的要求，要基于這個步驟來不斷優化，每一個步驟都是進行下一步的基礎，不可逆行，

5、JVM引數

下面來看一下JDK的JVM引數，

5.1、基本引數

Jdk7版本的主要引數

Jdk8版本的重要特有引數

5.2、并行收集器相關引數

5.3、CMS相關引數

5.4、輔助資訊

6、主要工具

6.1、JDK工具

JDK自帶了很多性能監控工具，我們可以用這些工具來監測系統和排查記憶體性能問題，

6.2、Linux 命令列工具

進行性能監控和問題排查的時候，常常是結合作業系統本身的命令列工具來進行，

其它還有一些第三方的監控工具，同樣是性能分析和故障排查的利器，如MAT、GChisto、JProfiler、arthas，

7、常用調優策略

這里還是要提一下，及時確定要進行JVM調優，也不要陷入“知見障”，進行分析之后，發現可以通過優化程式提升性能，仍然首選優化程式，

7.1、選擇合適的垃圾回收器

CPU單核，那么毫無疑問Serial 垃圾收集器是你唯一的選擇，

CPU多核，關注吞吐量 ，那么選擇PS+PO組合，

CPU多核，關注用戶停頓時間，JDK版本1.6或者1.7，那么選擇CMS，

CPU多核，關注用戶停頓時間，JDK1.8及以上，JVM可用記憶體6G以上，那么選擇G1，

引數配置：

 //設定Serial垃圾收集器（新生代）
 開啟：-XX:+UseSerialGC
 ?
 //設定PS+PO,新生代使用功能Parallel Scavenge 老年代將會使用Parallel Old收集器
 開啟 -XX:+UseParallelOldGC
 ?
 //CMS垃圾收集器（老年代）
 開啟 -XX:+UseConcMarkSweepGC
 ?
 //設定G1垃圾收集器
 開啟 -XX:+UseG1GC

7.2、調整記憶體大小

現象：垃圾收集頻率非常頻繁，

原因：如果記憶體太小，就會導致頻繁的需要進行垃圾收集才能釋放出足夠的空間來創建新的物件，所以增加堆記憶體大小的效果是非常顯而易見的，

注意：如果垃圾收集次數非常頻繁，但是每次能回收的物件非常少，那么這個時候并非記憶體太小，而可能是記憶體泄露導致物件無法回收，從而造成頻繁GC，

引數配置：

 //設定堆初始值
 指令1：-Xms2g
 指令2：-XX:InitialHeapSize=2048m
 ?
 //設定堆區最大值
 指令1：`-Xmx2g` 
 指令2： -XX:MaxHeapSize=2048m
 ?
 //新生代記憶體配置
 指令1：-Xmn512m
 指令2：-XX:MaxNewSize=512m

7.3、設定符合預期的停頓時間

現象：程式間接性的卡頓

原因：如果沒有確切的停頓時間設定，垃圾收集器以吞吐量為主，那么垃圾收集時間就會不穩定，

注意：不要設定不切實際的停頓時間，單次時間越短也意味著需要更多的GC次數才能回收完原有數量的垃圾.

引數配置：

 //GC停頓時間，垃圾收集器會嘗試用各種手段達到這個時間
 -XX:MaxGCPauseMillis 

7.4、調整記憶體區域大小比率

現象：某一個區域的GC頻繁，其他都正常，

原因：如果對應區域空間不足，導致需要頻繁GC來釋放空間，在JVM堆記憶體無法增加的情況下，可以調整對應區域的大小比率，

注意：也許并非空間不足，而是因為記憶體泄造成記憶體無法回收，從而導致GC頻繁，

引數配置：

 //survivor區和Eden區大小比率
 指令：-XX:SurvivorRatio=6  //S區和Eden區占新生代比率為1:6,兩個S區2:6
 ?
 //新生代和老年代的占比
 -XX:NewRatio=4  //表示新生代:老年代 = 1:4 即老年代占整個堆的4/5；默認值=2

7.5、調整物件升老年代的年齡

現象：老年代頻繁GC，每次回收的物件很多，

原因：如果升代年齡小，新生代的物件很快就進入老年代了，導致老年代物件變多，而這些物件其實在隨后的很短時間內就可以回收，這時候可以調整物件的升級代年齡，讓物件不那么容易進入老年代解決老年代空間不足頻繁GC問題，

注意：增加了年齡之后，這些物件在新生代的時間會變長可能導致新生代的GC頻率增加，并且頻繁復制這些物件新生的GC時間也可能變長，

配置引數：

//進入老年代最小的GC年齡,年輕代物件轉換為老年代物件最小年齡值，默認值7
 -XX:InitialTenuringThreshol=7 

7.6、調整大物件的標準

現象：老年代頻繁GC，每次回收的物件很多,而且單個物件的體積都比較大，

原因：如果大量的大物件直接分配到老年代，導致老年代容易被填滿而造成頻繁GC，可設定物件直接進入老年代的標準，

注意：這些大物件進入新生代后可能會使新生代的GC頻率和時間增加，

配置引數：

 //新生代可容納的最大物件,大于則直接會分配到老年代，0代表沒有限制，
  -XX:PretenureSizeThreshold=1000000 

7.7、調整GC的觸發時機

現象：CMS，G1 經常 Full GC，程式卡頓嚴重，

原因：G1和CMS 部分GC階段是并發進行的，業務執行緒和垃圾收集執行緒一起作業，也就說明垃圾收集的程序中業務執行緒會生成新的物件，所以在GC的時候需要預留一部分記憶體空間來容納新產生的物件，如果這個時候記憶體空間不足以容納新產生的物件，那么JVM就會停止并發收集暫停所有業務執行緒（STW）來保證垃圾收集的正常運行，這個時候可以調整GC觸發的時機（比如在老年代占用60%就觸發GC），這樣就可以預留足夠的空間來讓業務執行緒創建的物件有足夠的空間分配，

注意：提早觸發GC會增加老年代GC的頻率，

配置引數：

 //使用多少比例的老年代后開始CMS收集，默認是68%，如果頻繁發生SerialOld卡頓，應該調小
 -XX:CMSInitiatingOccupancyFraction
 ?
 //G1混合垃圾回收周期中要包括的舊區域設定占用率閾值，默認占用率為 65%
 -XX:G1MixedGCLiveThresholdPercent=65 

7.8、調整 JVM本地記憶體大小

現象：GC的次數、時間和回收的物件都正常，堆記憶體空間充足，但是報OOM

原因： JVM除了堆記憶體之外還有一塊堆外記憶體，這片記憶體也叫本地記憶體，可是這塊記憶體區域不足了并不會主動觸發GC，只有在堆記憶體區域觸發的時候順帶會把本地記憶體回收了，而一旦本地記憶體分配不足就會直接報OOM例外，

注意： 本地記憶體例外的時候除了上面的現象之外，例外資訊可能是OutOfMemoryError：Direct buffer memory， 解決方式除了調整本地記憶體大小之外，也可以在出現此例外時進行捕獲，手動觸發GC（System.gc()），

配置引數：

 XX:MaxDirectMemorySize

8、JVM調優實體

以下是整理自網路的一些JVM調優實體：

8.1、網站流量瀏覽量暴增后，網站反應頁面響很慢

1、問題推測：在測驗環境測速度比較快，但是一到生產就變慢，所以推測可能是因為垃圾收集導致的業務執行緒停頓，

2、定位：為了確認推測的正確性，在線上通過jstat -gc 指令 看到JVM進行GC 次數頻率非常高，GC所占用的時間非常長，所以基本推斷就是因為GC頻率非常高，所以導致業務執行緒經常停頓，從而造成網頁反應很慢，

3、解決方案：因為網頁訪問量很高，所以物件創建速度非常快，導致堆記憶體容易填滿從而頻繁GC，所以這里問題在于新生代記憶體太小，所以這里可以增加JVM記憶體就行了，所以初步從原來的2G記憶體增加到16G記憶體，

4、第二個問題：增加記憶體后的確平常的請求比較快了，但是又出現了另外一個問題，就是不定期的會間斷性的卡頓，而且單次卡頓的時間要比之前要長很多，

5、問題推測：練習到是之前的優化加大了記憶體，所以推測可能是因為記憶體加大了，從而導致單次GC的時間變長從而導致間接性的卡頓，

6、定位：還是通過jstat -gc 指令 查看到 的確FGC次數并不是很高，但是花費在FGC上的時間是非常高的,根據GC日志 查看到單次FGC的時間有達到幾十秒的，

7、解決方案： 因為JVM默認使用的是PS+PO的組合，PS+PO垃圾標記和收集階段都是STW，所以記憶體加大了之后，需要進行垃圾回收的時間就變長了，所以這里要想避免單次GC時間過長，所以需要更換并發類的收集器，因為當前的JDK版本為1.7，所以最后選擇CMS垃圾收集器，根據之前垃圾收集情況設定了一個預期的停頓的時間，上線后網站再也沒有了卡頓問題，

8.2、后臺匯出資料引發的OOM

**問題描述：**公司的后臺系統，偶發性的引發OOM例外，堆記憶體溢位，

1、因為是偶發性的，所以第一次簡單的認為就是堆記憶體不足導致，所以單方面的加大了堆記憶體從4G調整到8G，

2、但是問題依然沒有解決，只能從堆記憶體資訊下手，通過開啟了-XX:+HeapDumpOnOutOfMemoryError引數 獲得堆記憶體的dump檔案，

3、VisualVM 對 堆dump檔案進行分析，通過VisualVM查看到占用記憶體最大的物件是String物件，本來想跟蹤著String物件找到其參考的地方，但dump檔案太大，跟蹤進去的時候總是卡死，而String物件占用比較多也比較正常，最開始也沒有認定就是這里的問題，于是就從執行緒資訊里面找突破點，

4、通過執行緒進行分析，先找到了幾個正在運行的業務執行緒，然后逐一跟進業務執行緒看了下代碼，發現有個引起我注意的方法，匯出訂單資訊，

5、因為訂單資訊匯出這個方法可能會有幾萬的資料量，首先要從資料庫里面查詢出來訂單資訊，然后把訂單資訊生成excel，這個程序會產生大量的String物件，

6、為了驗證自己的猜想，于是準備登錄后臺去測驗下，結果在測驗的程序中發現到處訂單的按鈕前端居然沒有做點擊后按鈕置灰互動事件，結果按鈕可以一直點，因為匯出訂單資料本來就非常慢，使用的人員可能發現點擊后很久后頁面都沒反應，結果就一直點，結果就大量的請求進入到后臺，堆記憶體產生了大量的訂單物件和EXCEL物件，而且方法執行非常慢，導致這一段時間內這些物件都無法被回收，所以最終導致記憶體溢位，

7、知道了問題就容易解決了，最終沒有調整任何JVM引數，只是在前端的匯出訂單按鈕上加上了置灰狀態，等后端回應之后按鈕才可以進行點擊，然后減少了查詢訂單資訊的非必要欄位來減少生成物件的體積，然后問題就解決了，

8.3、單個快取資料過大導致的系統CPU飚高

1、系統發布后發現CPU一直飚高到600%，發現這個問題后首先要做的是定位到是哪個應用占用CPU高，通過top 找到了對應的一個java應用占用CPU資源600%，

2、如果是應用的CPU飚高，那么基本上可以定位可能是鎖資源競爭，或者是頻繁GC造成的，

3、所以準備首先從GC的情況排查，如果GC正常的話再從執行緒的角度排查，首先使用jstat -gc PID 指令列印出GC的資訊，結果得到得到的GC 統計資訊有明顯的例外，應用在運行了才幾分鐘的情況下GC的時間就占用了482秒，那么問這很明顯就是頻繁GC導致的CPU飚高，

4、定位到了是GC的問題，那么下一步就是找到頻繁GC的原因了，所以可以從兩方面定位了，可能是哪個地方頻繁創建物件，或者就是有記憶體泄露導致記憶體回收不掉，

5、根據這個思路決定把堆記憶體資訊dump下來看一下，使用jmap -dump 指令把堆記憶體資訊dump下來（堆記憶體空間大的慎用這個指令否則容易導致會影回應用，因為我們的堆記憶體空間才2G所以也就沒考慮這個問題了），

6、把堆記憶體資訊dump下來后，就使用visualVM進行離線分析了，首先從占用記憶體最多的物件中查找，結果排名第三看到一個業務VO占用堆記憶體約10%的空間，很明顯這個物件是有問題的，

7、通過業務物件找到了對應的業務代碼，通過代碼的分析找到了一個可疑之處，這個業務物件是查看新聞資訊資訊生成的物件，由于想提升查詢的效率，所以把新聞資訊保存到了redis快取里面，每次呼叫資訊介面都是從快取里面獲取，

8、把新聞保存到redis快取里面這個方式是沒有問題的，有問題的是新聞的50000多條資料都是保存在一個key里面，這樣就導致每次呼叫查詢新聞介面都會從redis里面把50000多條資料都拿出來，再做篩選分頁拿出10潭訓傳給前端，50000多條資料也就意味著會產生50000多個物件，每個物件280個位元組左右，50000個物件就有13.3M，這就意味著只要查看一次新聞資訊就會產生至少13.3M的物件，那么并發請求量只要到10，那么每秒鐘都會產生133M的物件，而這種大物件會被直接分配到老年代，這樣的話一個2G大小的老年代記憶體，只需要幾秒就會塞滿，從而觸發GC，

9、知道了問題所在后那么就容易解決了，問題是因為單個快取過大造成的，那么只需要把快取減小就行了，這里只需要把快取以頁的粒度進行快取就行了，每個key快取10條作為回傳給前端1頁的資料，這樣的話每次查詢新聞資訊只會從快取拿出10條資料，就避免了此問題的 產生，

8.4、CPU經常100% 問題定位

問題分析：CPU高一定是某個程式長期占用了CPU資源，

1、所以先需要找出那個進行占用CPU高，

 top  列出系統各個行程的資源占用情況，

2、然后根據找到對應進行里哪個執行緒占用CPU高，

 top -Hp 行程ID   列出對應行程里面的執行緒占用資源情況

3、找到對應執行緒ID后，再列印出對應執行緒的堆疊資訊

printf "%x\n"  PID    把執行緒ID轉換為16進制，
 jstack PID 列印出行程的所有執行緒資訊，從列印出來的執行緒資訊中找到上一步轉換為16進制的執行緒ID對應的執行緒資訊，

4、最后根據執行緒的堆疊資訊定位到具體業務方法,從代碼邏輯中找到問題所在，

查看是否有執行緒長時間的watting 或blocked
 如果執行緒長期處于watting狀態下， 關注watting on xxxxxx，說明執行緒在等待這把鎖，然后根據鎖的地址找到持有鎖的執行緒，

8.5、記憶體飚高問題定位

分析： 記憶體飚高如果是發生在java行程上，一般是因為創建了大量物件所導致，持續飚高說明垃圾回收跟不上物件創建的速度，或者記憶體泄露導致物件無法回收，

1、先觀察垃圾回收的情況

jstat -gc PID 1000 查看GC次數，時間等資訊，每隔一秒列印一次，
  
 jmap -histo PID | head -20   查看堆記憶體占用空間最大的前20個物件型別,可初步查看是哪個物件占用了記憶體，

如果每次GC次數頻繁，而且每次回收的記憶體空間也正常，那說明是因為物件創建速度快導致記憶體一直占用很高；如果每次回收的記憶體非常少，那么很可能是因為記憶體泄露導致記憶體一直無法被回收，

2、匯出堆記憶體檔案快照

jmap -dump:live,format=b,file=/home/myheapdump.hprof PID  dump堆記憶體資訊到檔案，

3、使用visualVM對dump檔案進行離線分析,找到占用記憶體高的物件，再找到創建該物件的業務代碼位置，從代碼和業務場景中定位具體問題，

8.6、資料分析平臺系統頻繁 Full GC

平臺主要對用戶在 App 中行為進行定時分析統計，并支持報表匯出，使用 CMS GC 演算法，

資料分析師在使用中發現系統頁面打開經常卡頓，通過 jstat 命令發現系統每次 Young GC 后大約有 10% 的存活物件進入老年代，

原來是因為 Survivor 區空間設定過小，每次 Young GC 后存活物件在 Survivor 區域放不下，提前進入老年代，

通過調大 Survivor 區，使得 Survivor 區可以容納 Young GC 后存活物件，物件在 Survivor 區經歷多次 Young GC 達到年齡閾值才進入老年代，

調整之后每次 Young GC 后進入老年代的存活物件穩定運行時僅幾百 Kb，Full GC 頻率大大降低，

8.7、業務對接網關 OOM

網關主要消費 Kafka 資料，進行資料處理計算然后轉發到另外的 Kafka 佇列，系統運行幾個小時候出現 OOM，重啟系統幾個小時之后又 OOM，

通過 jmap 匯出堆記憶體，在 eclipse MAT 工具分析才找出原因：代碼中將某個業務 Kafka 的 topic 資料進行日志異步列印，該業務資料量較大，大量物件堆積在記憶體中等待被列印，導致 OOM，

8.8、鑒權系統頻繁長時間 Full GC

系統對外提供各種賬號鑒權服務，使用時發現系統經常服務不可用，通過 Zabbix 的監控平臺監控發現系統頻繁發生長時間 Full GC，且觸發時老年代的堆記憶體通常并沒有占滿，發現原來是業務代碼中呼叫了 System.gc()，

參考：

【1】：周志明編著《深入理解Java虛擬機：JVM高級特性與最佳實踐》

【2】：《實戰JAVA虛擬機 JVM故障診斷與性能優化》

【3】：JVM性能調優詳解

【4】：如何合理的規劃一次jvm性能調優

【5】：關于GC原理和性能調優實踐，看這一篇就夠了

【6】：Java 應用性能調優實踐

【7】：JVM實戰：JVM調優策略

【8】：一般的Java專案需要JVM調優嗎？

【9】：Java8 JVM引數解讀

【10】：JVM引數設定-jdk8引數設定

【11】：JVM面試問題系列：JVM 配置常用引數和常用 GC 調優策略

【12】：Java1.8的jvm引數官方網站地址