JVM調優引數、方法、工具以及案例總結

等不到的口琴發表於2021-02-08

這種文章挺難寫的,一是JVM引數巨多,二是內容枯燥乏味,但是想理解JVM調優又是沒法避開的環節,本文主要用來總結梳理便於以後翻閱,主要圍繞四個大的方面展開,分別是JVM調優引數、JVM調優方法(流程)、JVM調優工具、JVM調優案例,調優案例目前正在分析,會在將來補上。

垃圾回收有關引數

引數部分,這兒只是做一個總結,更詳細更新的內容請參考Oracle官網:JVM的命令列引數參考

處理器組合引數

關於JVM垃圾處理器區別,參考:JVM調優之垃圾定位、垃圾回收演算法、垃圾處理器對比

-XX:+UseSerialGC = Serial New (DefNew) + Serial Old

適用於小型程式。預設情況下不會是這種選項，HotSpot會根據計算及配置和JDK版本自動選擇收集器

-XX:+UseParNewGC = ParNew + SerialOld

這個組合已經很少用（在某些版本中已經廢棄）,詳情參考:Why Remove support for ParNew+SerialOld and DefNew+CMS in the future？

-XX:+UseConc(urrent)MarkSweepGC = ParNew + CMS + Serial Old

-XX:+UseParallelGC = Parallel Scavenge + Parallel Old (1.8預設) 【PS + SerialOld】

-XX:+UseParallelOldGC = Parallel Scavenge + Parallel Old

-XX:+UseG1GC = G1

Linux中沒找到預設GC的檢視方法，而windows中會列印UseParallelGC

java +XX:+PrintCommandLineFlags -version
通過GC的日誌來分辨

Linux下1.8版本預設的垃圾回收器到底是什麼？

1.8.0_181 預設（看不出來）Copy MarkCompact
1.8.0_222 預設 PS + PO

虛擬機器引數

引數名稱	含義	預設值	解釋說明
-Xms	初始堆大小	實體記憶體的1/64(<1GB)	預設(MinHeapFreeRatio引數可以調整)空餘堆記憶體小於40%時，JVM就會增大堆直到-Xmx的最大限制.
-Xmx	最大堆大小	實體記憶體的1/4(<1GB)	預設(MaxHeapFreeRatio引數可以調整)空餘堆記憶體大於70%時，JVM會減少堆直到 -Xms的最小限制
-Xmn	年輕代大小(1.4or lator)		注意：此處的大小是（eden+ 2 survivor space).與jmap -heap中顯示的New gen是不同的。整個堆大小=年輕代大小 + 年老代大小 + 持久代大小. 增大年輕代後,將會減小年老代大小.此值對系統效能影響較大,Sun官方推薦配置為整個堆的3/8
-XX:NewSize	設定年輕代大小(for 1.3/1.4)
-XX:MaxNewSize	年輕代最大值(for 1.3/1.4)
-XX:PermSize	設定持久代(perm gen)初始值	實體記憶體的1/64
-XX:MaxPermSize	設定持久代最大值	實體記憶體的1/4
-Xss	每個執行緒的堆疊大小		JDK5.0以後每個執行緒堆疊大小為1M,以前每個執行緒堆疊大小為256K.更具應用的執行緒所需記憶體大小進行調整.在相同實體記憶體下,減小這個值能生成更多的執行緒.但是作業系統對一個程式內的執行緒數還是有限制的,不能無限生成,經驗值在3000~5000左右一般小的應用，如果棧不是很深，應該是128k夠用的大的應用建議使用256k。這個選項對效能影響比較大，需要嚴格的測試。和threadstacksize選項解釋很類似,官方文件似乎沒有解釋,在論壇中有這樣一句話:"” -Xss is translated in a VM flag named ThreadStackSize” 一般設定這個值就可以了。
-XX:ThreadStackSize	Thread Stack Size		(0 means use default stack size) [Sparc: 512; Solaris x86: 320 (was 256 prior in 5.0 and earlier); Sparc 64 bit: 1024; Linux amd64: 1024 (was 0 in 5.0 and earlier); all others 0.]
-XX:NewRatio	年輕代(包括Eden和兩個Survivor區)與年老代的比值(除去持久代)		-XX:NewRatio=4表示年輕代與年老代所佔比值為1:4,年輕代佔整個堆疊的1/5 Xms=Xmx並且設定了Xmn的情況下，該引數不需要進行設定。
-XX:SurvivorRatio	Eden區與Survivor區的大小比值		設定為8,則兩個Survivor區與一個Eden區的比值為2:8,一個Survivor區佔整個年輕代的1/10
-XX:LargePageSizeInBytes	記憶體頁的大小不可設定過大，會影響Perm的大小		=128m
-XX:+UseFastAccessorMethods	原始型別的快速優化
-XX:+DisableExplicitGC	關閉System.gc()		這個引數需要嚴格的測試
-XX:MaxTenuringThreshold	垃圾最大年齡		如果設定為0的話,則年輕代物件不經過Survivor區,直接進入年老代. 對於年老代比較多的應用,可以提高效率.如果將此值設定為一個較大值,則年輕代物件會在Survivor區進行多次複製,這樣可以增加物件再年輕代的存活時間,增加在年輕代即被回收的概率該引數只有在序列GC時才有效.
-XX:+AggressiveOpts	加快編譯
-XX:+UseBiasedLocking	鎖機制的效能改善
-Xnoclassgc	禁用垃圾回收
-XX:SoftRefLRUPolicyMSPerMB	每兆堆空閒空間中SoftReference的存活時間	1s	softly reachable objects will remain alive for some amount of time after the last time they were referenced. The default value is one second of lifetime per free megabyte in the heap
-XX:PretenureSizeThreshold	物件超過多大是直接在舊生代分配	0	單位位元組新生代採用Parallel Scavenge GC時無效另一種直接在舊生代分配的情況是大的陣列物件,且陣列中無外部引用物件.
-XX:TLABWasteTargetPercent	TLAB佔eden區的百分比	1%
-XX:+CollectGen0First	FullGC時是否先YGC	false

並行收集器相關引數

引數名稱	含義	預設值	解釋說明
-XX:+UseParallelGC	Full GC採用parallel MSC (此項待驗證)		選擇垃圾收集器為並行收集器.此配置僅對年輕代有效.即上述配置下,年輕代使用併發收集,而年老代仍舊使用序列收集.(此項待驗證)
-XX:+UseParNewGC	設定年輕代為並行收集		可與CMS收集同時使用 JDK5.0以上,JVM會根據系統配置自行設定,所以無需再設定此值
-XX:ParallelGCThreads	並行收集器的執行緒數		此值最好配置與處理器數目相等同樣適用於CMS
-XX:+UseParallelOldGC	年老代垃圾收集方式為並行收集(Parallel Compacting)		這個是JAVA 6出現的引數選項
-XX:MaxGCPauseMillis	每次年輕代垃圾回收的最長時間(最大暫停時間)		如果無法滿足此時間,JVM會自動調整年輕代大小,以滿足此值.
-XX:+UseAdaptiveSizePolicy	自動選擇年輕代區大小和相應的Survivor區比例		設定此選項後,並行收集器會自動選擇年輕代區大小和相應的Survivor區比例,以達到目標系統規定的最低相應時間或者收集頻率等,此值建議使用並行收集器時,一直開啟.
-XX:GCTimeRatio	設定垃圾回收時間佔程式執行時間的百分比		公式為1/(1+n)
-XX:+ScavengeBeforeFullGC	Full GC前呼叫YGC	true	Do young generation GC prior to a full GC. (Introduced in 1.4.1.)

CMS處理器引數設定

引數名稱	含義	預設值	解釋說明
-XX:+UseConcMarkSweepGC	使用CMS記憶體收集		測試中配置這個以後,-XX:NewRatio=4的配置失效了,原因不明.所以,此時年輕代大小最好用-Xmn設定.???
-XX:+AggressiveHeap			試圖是使用大量的實體記憶體長時間大記憶體使用的優化，能檢查計算資源（記憶體，處理器數量）至少需要256MB記憶體大量的CPU／記憶體，（在1.4.1在4CPU的機器上已經顯示有提升）
-XX:CMSFullGCsBeforeCompaction	多少次後進行記憶體壓縮		由於併發收集器不對記憶體空間進行壓縮,整理,所以執行一段時間以後會產生"碎片",使得執行效率降低.此值設定執行多少次GC以後對記憶體空間進行壓縮,整理.
-XX:+CMSParallelRemarkEnabled	降低標記停頓
-XX+UseCMSCompactAtFullCollection	在FULL GC的時候，對年老代的壓縮		CMS是不會移動記憶體的，因此，這個非常容易產生碎片，導致記憶體不夠用，因此，記憶體的壓縮這個時候就會被啟用。增加這個引數是個好習慣。可能會影響效能,但是可以消除碎片
-XX:+UseCMSInitiatingOccupancyOnly	使用手動定義初始化定義開始CMS收集		禁止hostspot自行觸發CMS GC
-XX:CMSInitiatingOccupancyFraction=70	使用cms作為垃圾回收使用70％後開始CMS收集	92	為了保證不出現promotion failed(見下面介紹)錯誤,該值的設定需要滿足以下公式CMSInitiatingOccupancyFraction計算公式
-XX:CMSInitiatingPermOccupancyFraction	設定Perm Gen使用到達多少比率時觸發	92
-XX:+CMSIncrementalMode	設定為增量模式		用於單CPU情況
-XX:+CMSClassUnloadingEnabled

JVM輔助資訊引數設定

引數名稱	含義	解釋說明
-XX:+PrintGC		輸出形式:[GC 118250K->113543K(130112K), 0.0094143 secs] [Full GC 121376K->10414K(130112K), 0.0650971 secs]
-XX:+PrintGCDetails		輸出形式:[GC [DefNew: 8614K->781K(9088K), 0.0123035 secs] 118250K->113543K(130112K), 0.0124633 secs] [GC [DefNew: 8614K->8614K(9088K), 0.0000665 secs][Tenured: 112761K->10414K(121024K), 0.0433488 secs] 121376K->10414K(130112K), 0.0436268 secs]
-XX:+PrintGCTimeStamps
-XX:+PrintGC:PrintGCTimeStamps		可與-XX:+PrintGC -XX:+PrintGCDetails混合使用輸出形式:11.851: [GC 98328K->93620K(130112K), 0.0082960 secs]
-XX:+PrintGCApplicationStoppedTime	列印垃圾回收期間程式暫停的時間.可與上面混合使用	輸出形式:Total time for which application threads were stopped: 0.0468229 seconds
-XX:+PrintGCApplicationConcurrentTime	列印每次垃圾回收前,程式未中斷的執行時間.可與上面混合使用	輸出形式:Application time: 0.5291524 seconds
-XX:+PrintHeapAtGC	列印GC前後的詳細堆疊資訊
-Xloggc:filename	把相關日誌資訊記錄到檔案以便分析. 與上面幾個配合使用
-XX:+PrintClassHistogram	garbage collects before printing the histogram.
-XX:+PrintTLAB	檢視TLAB空間的使用情況
XX:+PrintTenuringDistribution	檢視每次minor GC後新的存活週期的閾值	Desired survivor size 1048576 bytes, new threshold 7 (max 15) new threshold 7即標識新的存活週期的閾值為7。

JVM GC垃圾回收器引數設定

JVM給出了3種選擇：序列收集器、並行收集器、併發收集器。序列收集器只適用於小資料量的情況，所以生產環境的選擇主要是並行收集器和併發收集器。預設情況下JDK5.0以前都是使用序列收集器，如果想使用其他收集器需要在啟動時加入相應引數。JDK5.0以後，JVM會根據當前系統配置進行智慧判斷。

序列收集器
-XX:+UseSerialGC：設定序列收集器。

並行收集器（吞吐量優先）
-XX:+UseParallelGC：設定為並行收集器。此配置僅對年輕代有效。即年輕代使用並行收集，而年老代仍使用序列收集。

-XX:ParallelGCThreads=20：配置並行收集器的執行緒數，即：同時有多少個執行緒一起進行垃圾回收。此值建議配置與CPU數目相等。

-XX:+UseParallelOldGC：配置年老代垃圾收集方式為並行收集。JDK6.0開始支援對年老代並行收集。

-XX:MaxGCPauseMillis=100：設定每次年輕代垃圾回收的最長時間（單位毫秒）。如果無法滿足此時間，JVM會自動調整年輕代大小，以滿足此時間。

-XX:+UseAdaptiveSizePolicy：設定此選項後，並行收集器會自動調整年輕代Eden區大小和Survivor區大小的比例，以達成目標系統規定的最低響應時間或者收集頻率等指標。此引數建議在使用並行收集器時，一直開啟。
併發收集器（響應時間優先）

並行收集器

-XX:+UseConcMarkSweepGC：即CMS收集，設定年老代為併發收集。CMS收集是JDK1.4後期版本開始引入的新GC演算法。它的主要適合場景是對響應時間的重要性需求大於對吞吐量的需求，能夠承受垃圾回收執行緒和應用執行緒共享CPU資源，並且應用中存在比較多的長生命週期物件。CMS收集的目標是儘量減少應用的暫停時間，減少Full GC發生的機率，利用和應用程式執行緒併發的垃圾回收執行緒來標記清除年老代記憶體。

-XX:+UseParNewGC：設定年輕代為併發收集。可與CMS收集同時使用。JDK5.0以上，JVM會根據系統配置自行設定，所以無需再設定此引數。

-XX:CMSFullGCsBeforeCompaction=0：由於併發收集器不對記憶體空間進行壓縮和整理，所以執行一段時間並行收集以後會產生記憶體碎片，記憶體使用效率降低。此引數設定執行0次Full GC後對記憶體空間進行壓縮和整理，即每次Full GC後立刻開始壓縮和整理記憶體。

-XX:+UseCMSCompactAtFullCollection：開啟記憶體空間的壓縮和整理，在Full GC後執行。可能會影響效能，但可以消除記憶體碎片。

-XX:+CMSIncrementalMode：設定為增量收集模式。一般適用於單CPU情況。

-XX:CMSInitiatingOccupancyFraction=70：表示年老代記憶體空間使用到70%時就開始執行CMS收集，以確保年老代有足夠的空間接納來自年輕代的物件，避免Full GC的發生。

其它垃圾回收引數

-XX:+ScavengeBeforeFullGC：年輕代GC優於Full GC執行。

-XX:-DisableExplicitGC：不響應 System.gc() 程式碼。

-XX:+UseThreadPriorities：啟用本地執行緒優先順序API。即使 java.lang.Thread.setPriority() 生效，不啟用則無效。

-XX:SoftRefLRUPolicyMSPerMB=0：軟引用物件在最後一次被訪問後能存活0毫秒（JVM預設為1000毫秒）。

-XX:TargetSurvivorRatio=90：允許90%的Survivor區被佔用（JVM預設為50%）。提高對於Survivor區的使用率。

JVM引數優先順序

-Xmn，-XX:NewSize/-XX:MaxNewSize，-XX:NewRatio 3組引數都可以影響年輕代的大小，混合使用的情況下，優先順序是什麼？

答案如下：

高優先順序：-XX:NewSize/-XX:MaxNewSize
中優先順序：-Xmn（預設等效 -Xmn=-XX:NewSize=-XX:MaxNewSize=?）
低優先順序：-XX:NewRatio

推薦使用-Xmn引數，原因是這個引數簡潔，相當於一次設定 NewSize/MaxNewSIze，而且兩者相等，適用於生產環境。-Xmn 配合 -Xms/-Xmx，即可將堆記憶體佈局完成。

-Xmn引數是在JDK 1.4 開始支援。

下面用一些小案例加深理解:

HelloGC是java程式碼編譯後的一個class檔案,程式碼:

public class T01_HelloGC {
    public static void main(String[] args) {

        for(int i=0; i<10000; i++) {
            byte[] b = new byte[1024 * 1024];
        }
    }
}

java -XX:+PrintCommandLineFlags HelloGC

[root@localhost courage]# java -XX:+PrintCommandLineFlags T01_HelloGC
-XX:InitialHeapSize=61780800 -XX:MaxHeapSize=988492800 -XX:+PrintCommandLineFlags -XX
:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseParallelGC

java -Xmn10M -Xms40M -Xmx60M -XX:+PrintCommandLineFlags -XX:+PrintGC  HelloGC
PrintGCDetails PrintGCTimeStamps PrintGCCauses

結果:

-XX:InitialHeapSize=41943040 -XX:MaxHeapSize=62914560 -XX:MaxNewSize=10485760 -XX:NewSize=10485760 -XX:+PrintCommandLineFlags -XX:+PrintGC -XX:+UseCompressedClassPointers -XX:+UseCompressedOops 
-XX:+UseParallelGC[GC (Allocation Failure)  7839K->392K(39936K), 0.0015452 secs]
[GC (Allocation Failure)  7720K->336K(39936K), 0.0005439 secs]
[GC (Allocation Failure)  7656K->336K(39936K), 0.0005749 secs]
[GC (Allocation Failure)  7659K->368K(39936K), 0.0005095 secs]
[GC (Allocation Failure)  7693K->336K(39936K), 0.0004385 secs]
[GC (Allocation Failure)  7662K->304K(40448K), 0.0028468 secs]
......

命令解釋:

java:表示使用java執行器執行
-Xmn10M :表示設定年輕代值為10M
-Xms40M :表示設定堆記憶體的最小Heap值為40M
-Xmx60M :表示設定堆記憶體的最大Heap值為60M
-XX:+PrintCommandLineFlags:列印顯式隱式引數,就是結果前三行
-XX:+PrintGC : 列印垃圾回收有關資訊
HelloGC :這是需要執行的啟動類
PrintGCDetails :列印GC詳細資訊
PrintGCTimeStamps :列印GC時間戳
PrintGCCauses :列印GC產生的原因

結果解釋:

java -XX:+UseConcMarkSweepGC -XX:+PrintCommandLineFlags HelloGC

表示使用CMS垃圾收集器,同時列印引數
列印結果:

-XX:InitialHeapSize=61780800 
-XX:MaxHeapSize=988492800 
-XX:MaxNewSize=329252864 
-XX:MaxTenuringThreshold=6 
-XX:OldPLABSize=16 
-XX:+PrintCommandLineFlags 
-XX:+UseCompressedClassPointers 
-XX:+UseCompressedOops 
-XX:+UseConcMarkSweepGC 
-XX:+UseParNewGC

java -XX:+PrintFlagsInitial 預設引數值
java -XX:+PrintFlagsFinal 最終引數值
java -XX:+PrintFlagsFinal | grep xxx 找到對應的引數
java -XX:+PrintFlagsFinal -version |grep GC

JVM調優流程

JVM調優,設計到三個大的方面,在伺服器出現問題之前要先根據業務場景選擇合適的垃圾處理器,設定不同的虛擬機器引數,執行中觀察GC日誌,分析效能,分析問題定位問題,虛擬機器排錯等內容,如果伺服器掛掉了,要及時生成日誌檔案便於找到問題所在。

調優前的基礎概念

目前的垃圾處理器中,一類是以吞吐量優先,一類是以響應時間優先:

\[吞吐量 = \frac{使用者程式碼執行時間}{使用者程式碼執行時間+垃圾回收執行時間} \]

響應時間：STW越短，響應時間越好

對吞吐量、響應時間、QPS、併發數相關概念可以參考:吞吐量（TPS）、QPS、併發數、響應時間（RT）概念

所謂調優，首先確定追求什麼,是吞吐量? 還是追求響應時間？還是在滿足一定的響應時間的情況下，要求達到多大的吞吐量,等等。一般情況下追求吞吐量的有以下領域:科學計算、資料探勘等。吞吐量優先的垃圾處理器組合一般為：Parallel Scavenge + Parallel Old （PS + PO）。

而追求響應時間的業務有：網站相關（JDK 1.8之後 G1,之前可以ParNew + CMS + Serial Old）

什麼是調優？

根據需求進行JVM規劃和預調優
優化執行JVM執行環境（慢，卡頓）
解決JVM執行過程中出現的各種問題(OOM)

調優之前的規劃

調優，從業務場景開始，沒有業務場景的調優都是耍流氓
無監控（壓力測試，能看到結果），不調優
步驟：
1. 熟悉業務場景（沒有最好的垃圾回收器，只有最合適的垃圾回收器）
  1. 響應時間、停頓時間 [CMS G1 ZGC] （需要給使用者作響應）
  2. 吞吐量 = 使用者時間 /( 使用者時間 + GC時間) [PS+PO]
2. 選擇回收器組合
3. 計算記憶體需求（經驗值 1.5G 16G）
4. 選定CPU（越高越好）
5. 設定年代大小、升級年齡
6. 設定日誌引數
  1. ```
  -Xloggc:/opt/xxx/logs/xxx-xxx-gc-%t.log 
  -XX:+UseGCLogFileRotation 
  -XX:NumberOfGCLogFiles=5 
  -XX:GCLogFileSize=20M 
  -XX:+PrintGCDetails 
  -XX:+PrintGCDateStamps 
  -XX:+PrintGCCause
```
  日誌引數解釋說明:
  
  /opt/xxx/logs/xxx-xxx-gc-%t.log 中XXX表示路徑,%t表示時間戳,意思是給日誌檔案新增一個時間標記,如果不新增的話,也就意味著每次虛擬機器啟動都會使用原來的日誌名,那麼會被重寫。
  
  Rotation中文意思是迴圈、輪流,意味著這個GC日誌會迴圈寫
  
  GCLogFileSize=20M 指定一個日誌大小為20M,太大了不利於分析,太小又會產生過多的日誌檔案
  
  NumberOfGCLogFiles=5 : 指定生成的日誌數目
  
  PrintGCDateStamps :PrintGCDateStamps會列印具體的時間，而PrintGCTimeStamps
  
  主要列印針對JVM啟動的時候的相對時間，相對來說前者更消耗記憶體。
2. 或者每天產生一個日誌檔案
7. 觀察日誌情況
  日誌有分析工具,視覺化分析工具有GCeasy和GCViewer。

CPU高負荷排查流程

系統CPU經常100%，如何調優？(面試高頻) CPU100%那麼一定有執行緒在佔用系統資源，
1. 找出哪個程式cpu高（top）
2. 該程式中的哪個執行緒cpu高（top -Hp）
3. 匯出該執行緒的堆疊 (jstack)
4. 查詢哪個方法（棧幀）消耗時間 (jstack)
5. 工作執行緒佔比高 | 垃圾回收執行緒佔比高
系統記憶體飆高，如何查詢問題？（面試高頻）
1. 匯出堆記憶體 (jmap)
2. 分析 (jhat jvisualvm mat jprofiler ... )
如何監控JVM
1. jstat jvisualvm jprofiler arthas top...

CPU高負荷排查案例

測試程式碼：

import java.math.BigDecimal;
import java.util.ArrayList;
import java.util.Date;
import java.util.List;
import java.util.concurrent.ScheduledThreadPoolExecutor;
import java.util.concurrent.ThreadPoolExecutor;
import java.util.concurrent.TimeUnit;

/**
 * 從資料庫中讀取信用資料，套用模型，並把結果進行記錄和傳輸
 */

public class T15_FullGC_Problem01 {

    private static class CardInfo {
        BigDecimal price = new BigDecimal(0.0);
        String name = "張三";
        int age = 5;
        Date birthdate = new Date();

        public void m() {}
    }

    private static ScheduledThreadPoolExecutor executor = new ScheduledThreadPoolExecutor(50,
            new ThreadPoolExecutor.DiscardOldestPolicy());

    public static void main(String[] args) throws Exception {
        executor.setMaximumPoolSize(50);

        for (;;){
            modelFit();
            Thread.sleep(100);
        }
    }

    private static void modelFit(){
        List<CardInfo> taskList = getAllCardInfo();
        taskList.forEach(info -> {
            // do something
            executor.scheduleWithFixedDelay(() -> {
                //do sth with info
                info.m();

            }, 2, 3, TimeUnit.SECONDS);
        });
    }

    private static List<CardInfo> getAllCardInfo(){
        List<CardInfo> taskList = new ArrayList<>();

        for (int i = 0; i < 100; i++) {
            CardInfo ci = new CardInfo();
            taskList.add(ci);
        }

        return taskList;
    }
}

java -Xms200M -Xmx200M -XX:+PrintGC com.courage.jvm.gc.T15_FullGC_Problem01
收到CPU報警資訊（CPU Memory）

top命令觀察到問題：記憶體不斷增長 CPU佔用率居高不下

[root@localhost ~]# top
top - 22:03:18 up 40 min,  5 users,  load average: 0.09, 0.16, 0.34
Tasks: 210 total,   1 running, 209 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.2 us,  3.0 sy,  0.0 ni, 96.8 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem :  3861300 total,  2355260 free,   904588 used,   601452 buff/cache
KiB Swap:  4063228 total,  4063228 free,        0 used.  2716336 avail Mem 

   PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                 
  3751 root      20   0 3780976  93864  11816 S  42.2  2.4   0:21.00 java
  1868 mysql     20   0 1907600 357452  14744 S   0.7  9.3   0:17.40 mysqld
  3816 root      20   0  162124   2352   1580 R   0.3  0.1   0:00.12 top

top -Hp 觀察程式中的執行緒，哪個執行緒CPU和記憶體佔比高

[root@localhost ~]# top -Hp 3751
top - 22:03:15 up 40 min,  5 users,  load average: 0.09, 0.16, 0.34
Threads:  66 total,   0 running,  66 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.0 us,  2.5 sy,  0.0 ni, 97.5 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem :  3861300 total,  2354800 free,   905048 used,   601452 buff/cache
KiB Swap:  4063228 total,  4063228 free,        0 used.  2715876 avail Mem 

   PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND              
  3801 root      20   0 3780976  93864  11816 S  1.3  2.4   0:00.40 java
  3766 root      20   0 3780976  93864  11816 S  1.0  2.4   0:00.37 java
  3768 root      20   0 3780976  93864  11816 S  1.0  2.4   0:00.36 java
  3770 root      20   0 3780976  93864  11816 S  1.0  2.4   0:00.39 java

jps定位具體java程式,jstack 定位執行緒狀況

[root@localhost ~]# jstack 3751
2021-02-07 22:03:03
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.271-b09 mixed mode):

"Attach Listener" #59 daemon prio=9 os_prio=0 tid=0x00007f66bc002800 nid=0xf10 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"pool-1-thread-50" #58 prio=5 os_prio=0 tid=0x00007f66fc1de800 nid=0xee7 waiting on condition [0x00007f66e4ecd000]
   java.lang.Thread.State: WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x00000000ff0083a0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
......

需要注意的是,jstack與top -Hp Port匯出的棧埠號存在十六進位制轉換關係,例如jstack匯出的" nid=0xf10 "對應"3801"。
對於上面列印的資訊,重點關注跟Waiting有關的,看看在等待什麼,例如:

WAITING BLOCKED eg. waiting on <0x0000000088ca3310> (a java.lang.Object)

假如有一個程式中100個執行緒，很多執行緒都在waiting on ，一定要找到是哪個執行緒持有這把鎖,怎麼找？搜尋jstack dump的資訊，看哪個執行緒持有這把鎖RUNNABLE。

如果僅僅是看JAVA執行緒,可以使用jps命令重點關注：

[root@localhost ~]# jps
4818 Jps
4746 T15_FullGC_Problem01

為什麼阿里規範裡規定，執行緒的名稱（尤其是執行緒池）都要寫有意義的名稱怎麼樣自定義執行緒池裡的執行緒名稱？（自定義ThreadFactory）

jinfo pid 程式詳細資訊

[root@localhost ~]# jinfo 6741
Attaching to process ID 6741, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.271-b09
Java System Properties:

java.runtime.name = Java(TM) SE Runtime Environment
java.vm.version = 25.271-b09
sun.boot.library.path = /usr/local/java/jdk1.8.0_271/jre/lib/amd64
java.vendor.url = http://java.oracle.com/
java.vm.vendor = Oracle Corporation
path.separator = :
file.encoding.pkg = sun.io
java.vm.name = Java HotSpot(TM) 64-Bit Server VM
sun.os.patch.level = unknown
sun.java.launcher = SUN_STANDARD
user.country = CN
user.dir = /usr/courage/gc/com/courage
java.vm.specification.name = Java Virtual Machine Specification
java.runtime.version = 1.8.0_271-b09
java.awt.graphicsenv = sun.awt.X11GraphicsEnvironment
os.arch = amd64
java.endorsed.dirs = /usr/local/java/jdk1.8.0_271/jre/lib/endorsed
java.io.tmpdir = /tmp
line.separator = 

java.vm.specification.vendor = Oracle Corporation
os.name = Linux
sun.jnu.encoding = UTF-8
java.library.path = /usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/
libjava.specification.name = Java Platform API Specification
java.class.version = 52.0
sun.management.compiler = HotSpot 64-Bit Tiered Compilers
os.version = 3.10.0-1127.el7.x86_64
user.home = /root
user.timezone = 
java.awt.printerjob = sun.print.PSPrinterJob
file.encoding = UTF-8
java.specification.version = 1.8
user.name = root
java.class.path = .
java.vm.specification.version = 1.8
sun.arch.data.model = 64
sun.java.command = T15_FullGC_Problem01
java.home = /usr/local/java/jdk1.8.0_271/jre
user.language = zh
java.specification.vendor = Oracle Corporation
awt.toolkit = sun.awt.X11.XToolkit
java.vm.info = mixed mode
java.version = 1.8.0_271
java.ext.dirs = /usr/local/java/jdk1.8.0_271/jre/lib/ext:/usr/java/packages/l
ib/extsun.boot.class.path = /usr/local/java/jdk1.8.0_271/jre/lib/resources.jar:/usr
/local/java/jdk1.8.0_271/jre/lib/rt.jar:/usr/local/java/jdk1.8.0_271/jre/lib/sunrsasign.jar:/usr/local/java/jdk1.8.0_271/jre/lib/jsse.jar:/usr/local/java/jdk1.8.0_271/jre/lib/jce.jar:/usr/local/java/jdk1.8.0_271/jre/lib/charsets.jar:/usr/local/java/jdk1.8.0_271/jre/lib/jfr.jar:/usr/local/java/jdk1.8.0_271/jre/classesjava.vendor = Oracle Corporation
file.separator = /
java.vendor.url.bug = http://bugreport.sun.com/bugreport/
sun.io.unicode.encoding = UnicodeLittle
sun.cpu.endian = little
sun.cpu.isalist = 

VM Flags:
Non-default VM flags: -XX:CICompilerCount=3 -XX:InitialHeapSize=209715200 -XX
:MaxHeapSize=209715200 -XX:MaxNewSize=69730304 -XX:MinHeapDeltaBytes=524288 -XX:NewSize=69730304 -XX:OldSize=139984896 -XX:+PrintGC -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseFastUnorderedTimeStamps -XX:+UseParallelGC Command line:  -Xms200M -Xmx200M -XX:+PrintGC

jstat -gc 動態觀察gc情況 / 閱讀GC日誌發現頻繁GC / arthas觀察 / jconsole/jvisualVM/ Jprofiler（最好用）

jstat gc 4655 500 : 每500毫秒列印埠4655的GC的情況

S0C：第一個倖存區的大小
S1C：第二個倖存區的大小
S0U：第一個倖存區的使用大小
S1U：第二個倖存區的使用大小
EC：伊甸園區的大小
EU：伊甸園區的使用大小
OC：老年代大小
OU：老年代使用大小
MC：方法區大小
MU：方法區使用大小
CCSC:壓縮類空間大小
CCSU:壓縮類空間使用大小
YGC：年輕代垃圾回收次數
YGCT：年輕代垃圾回收消耗時間
FGC：老年代垃圾回收次數
FGCT：老年代垃圾回收消耗時間
GCT：垃圾回收消耗總時間

如果面試官問你是怎麼定位OOM問題的？能否用圖形介面（不能!因為圖形介面會影響伺服器效能）
1：已經上線的系統不用圖形介面用什麼？（cmdline arthas）
2：圖形介面到底用在什麼地方？測試！測試的時候進行監控！（壓測觀察）

jmap -histo 6892 | head -10，查詢有多少物件產生

這明顯能看出來是1對應的類創造的例項instances太多了,反過來追蹤程式碼

jmap -dump:format=b,file=xxx pid ：

線上系統，記憶體特別大，jmap執行期間會對程式產生很大影響，甚至卡頓（電商不適合）
1：設定了引數HeapDump，OOM的時候會自動產生堆轉儲檔案
2：很多伺服器備份（高可用），停掉這臺伺服器對其他伺服器不影響
3：線上定位(一般小點兒公司用不到)
```
[root@localhost ~]# jmap -dump:format=b,file=2021_2_8.dump 6892
Dumping heap to /root/2021_2_8.dump ...
Heap dump file created
```
dump檔案存放位置:
java -Xms20M -Xmx20M -XX:+UseParallelGC -XX:+HeapDumpOnOutOfMemoryError com.courage.jvm.gc.T15_FullGC_Problem01
上面的意思是當發生記憶體溢位時自動生成堆轉儲檔案,需要注意的是,如果生成了這個檔案先不要重啟伺服器,將這個檔案儲存好之後再重啟。
使用MAT / jhat /jvisualvm 進行dump檔案分析
```
[root@localhost ~]# jhat -J-Xmx512M 2021_2_8.dump
```
報錯:

原因是設定的堆最大值太小了,將512M設定成1024M重新啟動即可:

```shell
[root@localhost ~]# jhat -J-Xmx1024M 2021_2_8.dump
Reading from 2021_2_8.dump...
Dump file created Mon Feb 08 09:00:56 CST 2021
Snapshot read, resolving...
Resolving 4609885 objects...
Chasing references, expect 921 dots..........................................................
.........................................................................................Eliminating duplicate references.............................................................
......................................................................................Snapshot resolved.
Started HTTP server on port 7000
Server is ready.
```


瀏覽器輸入請求http://192.168.182.130:7000 即可檢視,拉到最後：找到對應連結 可以使用OQL查詢特定問題物件

其他可以參考:白灰——軟體測試

最後找到程式碼的問題

JVM調優工具

jconsole遠端連線

程式啟動加入引數：

java -Djava.rmi.server.hostname=192.168.182.130 
-Dcom.sun.management.jmxremote 
-Dcom.sun.management.jmxremote.port=11111 
-Dcom.sun.management.jmxremote.authenticate=false 
-Dcom.sun.management.jmxremote.ssl=false XXX

如果遭遇 Local host name unknown：XXX的錯誤，修改/etc/hosts檔案，把XXX加入進去

192.168.182.130 basic localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

關閉linux防火牆（實戰中應該開啟對應埠）

service iptables stop
chkconfig iptables off #永久關閉

windows上開啟 jconsole遠端連線 192.168.182.130:11111

jvisualvm遠端連線

這個軟體在JDK8以後版本中移除了,使用的話需要額外下載,並且要在etc/visualvm.conf中修改預設的JDK_Home地址。
參考:使用jvisualvm的jstatd方式遠端監控Java程式

阿里巴巴Arthas

這個直接看官網就行了,純中文:Arthas 使用者文件

JVM調優案例

引數設定之承受海量訪問的動態Web應用

伺服器配置：8 核 CPU, 8G MEM, JDK 1.6.X

引數方案：
-server -Xmx3550m -Xms3550m -Xmn1256m -Xss128k -XX:SurvivorRatio=6 -XX:MaxPermSize=256m -XX:ParallelGCThreads=8 -XX:MaxTenuringThreshold=0 -XX:+UseConcMarkSweepGC

調優說明：
-Xmx 與 -Xms 相同以避免JVM反覆重新申請記憶體。-Xmx 的大小約等於系統記憶體大小的一半，即充分利用系統資源，又給予系統安全執行的空間。
-Xmn1256m 設定年輕代大小為1256MB。此值對系統效能影響較大，Sun官方推薦配置年輕代大小為整個堆的3/8。
-Xss128k 設定較小的執行緒棧以支援建立更多的執行緒，支援海量訪問，並提升系統效能。
-XX:SurvivorRatio=6 設定年輕代中Eden區與Survivor區的比值。系統預設是8，根據經驗設定為6，則2個Survivor區與1個Eden區的比值為2:6，一個Survivor區佔整個年輕代的1/8。
-XX:ParallelGCThreads=8 配置並行收集器的執行緒數，即同時8個執行緒一起進行垃圾回收。此值一般配置為與CPU數目相等。
-XX:MaxTenuringThreshold=0 設定垃圾最大年齡（在年輕代的存活次數）。如果設定為0的話，則年輕代物件不經過Survivor區直接進入年老代。對於年老代比較多的應用，可以提高效率；如果將此值設定為一個較大值，則年輕代物件會在Survivor區進行多次複製，這樣可以增加物件再年輕代的存活時間，增加在年輕代即被回收的概率。根據被海量訪問的動態Web應用之特點，其記憶體要麼被快取起來以減少直接訪問DB，要麼被快速回收以支援高併發海量請求，因此其記憶體物件在年輕代存活多次意義不大，可以直接進入年老代，根據實際應用效果，在這裡設定此值為0。
-XX:+UseConcMarkSweepGC 設定年老代為併發收集。CMS（ConcMarkSweepGC）收集的目標是儘量減少應用的暫停時間，減少Full GC發生的機率，利用和應用程式執行緒併發的垃圾回收執行緒來標記清除年老代記憶體，適用於應用中存在比較多的長生命週期物件的情況。

引數設定之內部整合構建伺服器

高效能資料處理的工具應用
伺服器配置：1 核 CPU, 4G MEM, JDK 1.6.X
引數方案：
-server -XX:PermSize=196m -XX:MaxPermSize=196m -Xmn320m -Xms768m -Xmx1024m
調優說明：
-XX:PermSize=196m -XX:MaxPermSize=196m 根據整合構建的特點，大規模的系統編譯可能需要載入大量的Java類到記憶體中，所以預先分配好大量的持久代記憶體是高效和必要的。
-Xmn320m 遵循年輕代大小為整個堆的3/8原則。
-Xms768m -Xmx1024m 根據系統大致能夠承受的堆記憶體大小設定即可。

案例分析之XXX

分析中,年後再梳理......

問題定位之XXX

分析中,年後再梳理......

虛擬機器排錯之XXX

分析中,年後再梳理......

JVM 引數調優（qbit）
2020-05-11
JVM
JVM常用調優引數
2022-12-21
JVM
【JVM進階之路】十：JVM調優總結
2021-04-11
JVM
JVM引數以及用法
2021-09-09
JVM
常用的 jvm 調優的引數都有哪些
2024-11-09
JVM
JVM 調優命令&工具使用
2020-02-14
JVM
淺談JVM整體架構與調優引數
2024-04-02
JVM架構
調優引數
2024-08-31
檢視JVM預設引數及微調JVM啟動引數
2021-07-24
JVM
JVM調優工具Arthas的使用
2020-07-17
JVM
JVM常用調優工具介紹
2020-11-11
JVM
JVM效能調優的6大步驟，及關鍵調優引數詳解
2022-03-23
JVM
JVM快速調優手冊v1.0之六:JVM引數設定、分析
2018-05-18
JVM
JVM面試問題系列：JVM 配置常用引數和常用 GC 調優策略
2019-03-22
JVM面試GC
mysql 引數調優
2024-06-13
MySql
數倉調優實戰：GUC引數調優
2024-04-07
weblogic執行緒池引數調優配置方法
2020-11-06
Web執行緒
1，Spark引數調優
2021-09-07
Spark
StringTable結構以及基本調優
2020-07-15
JVM調優之JConsole和JVisualVM工具使用
2018-08-08
JVMLVM
跟著練、包會（JVM調優工具）
2021-09-09
JVM
JVM效能調優，記憶體分析工具
2023-02-11
JVM記憶體
JVM調優
2023-12-12
JVM
HBase 核心元件協調及RegionServer JVM引數調優-OLAP商業環境實戰
2018-11-27
元件ServerJVM
一次快速排序引發的jvm調優
2019-02-18
排序JVM
JVM實用引數（一）JVM型別以及編譯器模式
2021-11-28
JVM型別編譯模式
irace package -- 引數調優神器
2021-04-01
Package
JVM 引數調整對 sortx 的影響
2019-10-31
JVM
JVM調優策略
2018-04-18
JVM
JVM故障處理工具，使用總結
2021-01-14
JVM
swoole優化核心引數調整
2022-06-23
優化
tomcat 如何調優，涉及哪些引數
2020-12-22
Tomcat
parallel rollback引數總結
2019-02-28
Parallel
JVM實戰調優(空格引發的服務異常)
2021-03-12
JVM
JVM調優淺談
2018-11-02
JVM
JVM調優推薦
2019-01-02
JVM
掌握JVM調優命令
2024-12-02
JVM
常用JVM引數
2018-04-18
JVM

JVM調優引數、方法、工具以及案例總結

垃圾回收有關引數

處理器組合引數

虛擬機器引數

並行收集器相關引數

CMS處理器引數設定

JVM輔助資訊引數設定

JVM GC垃圾回收器引數設定

JVM引數優先順序

JVM調優流程

調優前的基礎概念

什麼是調優？

調優之前的規劃

CPU高負荷排查流程

CPU高負荷排查案例

JVM調優工具

jconsole遠端連線

jvisualvm遠端連線

阿里巴巴Arthas

JVM調優案例

引數設定之承受海量訪問的動態Web應用

引數設定之內部整合構建伺服器

案例分析之XXX

問題定位之XXX

虛擬機器排錯之XXX

相關文章