這篇文章主要介紹“如何理解JVM調(diào)優(yōu)參數(shù)、方法、工具”，在日常操作中，相信很多人在如何理解JVM調(diào)優(yōu)參數(shù)、方法、工具問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”如何理解JVM調(diào)優(yōu)參數(shù)、方法、工具”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

成都創(chuàng)新互聯(lián)公司是專業(yè)的龍里網(wǎng)站建設公司，龍里接單;提供成都網(wǎng)站設計、網(wǎng)站制作,網(wǎng)頁設計,網(wǎng)站設計,建網(wǎng)站,PHP網(wǎng)站建設等專業(yè)做網(wǎng)站服務;采用PHP框架,可快速的進行龍里網(wǎng)站開發(fā)網(wǎng)頁制作和功能擴展;專業(yè)做搜索引擎喜愛的網(wǎng)站,專業(yè)的做網(wǎng)站團隊,希望更多企業(yè)前來合作!

垃圾回收有關參數(shù)

參數(shù)部分,這兒只是做一個總結,更詳細更新的內(nèi)容請參考Oracle官網(wǎng):JVM的命令行參數(shù)參考

處理器組合參數(shù)

關于JVM垃圾處理器區(qū)別,參考:JVM調(diào)優(yōu)之垃圾定位、垃圾回收算法、垃圾處理器對比

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

適用于小型程序。默認情況下不會是這種選項，HotSpot會根據(jù)計算及配置和JDK版本自動選擇收集器

-XX:+UseParNewGC = ParNew + SerialOld

這個組合已經(jīng)很少用（在某些版本中已經(jīng)廢棄）,詳情參考: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

虛擬機參數(shù)

并行收集器相關參數(shù)

CMS處理器參數(shù)設置

JVM輔助信息參數(shù)設置

JVM GC垃圾回收器參數(shù)設置

JVM給出了3種選擇：串行收集器、并行收集器、并發(fā)收集器。串行收集器只適用于小數(shù)據(jù)量的情況，所以生產(chǎn)環(huán)境的選擇主要是并行收集器和并發(fā)收集器。默認情況下JDK5.0以前都是使用串行收集器，如果想使用其他收集器需要在啟動時加入相應參數(shù)。JDK5.0以后，JVM會根據(jù)當前系統(tǒng)配置進行智能判斷。

串行收集器-XX:+UseSerialGC：設置串行收集器。

并行收集器（吞吐量優(yōu)先）-XX:+UseParallelGC：設置為并行收集器。此配置僅對年輕代有效。即年輕代使用并行收集，而年老代仍使用串行收集。

-XX:ParallelGCThreads=20：配置并行收集器的線程數(shù)，即：同時有多少個線程一起進行垃圾回收。此值建議配置與CPU數(shù)目相等。

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

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

-XX:+UseAdaptiveSizePolicy：設置此選項后，并行收集器會自動調(diào)整年輕代Eden區(qū)大小和Survivor區(qū)大小的比例，以達成目標系統(tǒng)規(guī)定的最低響應時間或者收集頻率等指標。此參數(shù)建議在使用并行收集器時，一直打開。并發(fā)收集器（響應時間優(yōu)先）

并行收集器

-XX:+UseConcMarkSweepGC：即CMS收集，設置年老代為并發(fā)收集。CMS收集是JDK1.4后期版本開始引入的新GC算法。它的主要適合場景是對響應時間的重要性需求大于對吞吐量的需求，能夠承受垃圾回收線程和應用線程共享CPU資源，并且應用中存在比較多的長生命周期對象。CMS收集的目標是盡量減少應用的暫停時間，減少Full GC發(fā)生的幾率，利用和應用程序線程并發(fā)的垃圾回收線程來標記清除年老代內(nèi)存。

-XX:+UseParNewGC：設置年輕代為并發(fā)收集?？膳cCMS收集同時使用。JDK5.0以上，JVM會根據(jù)系統(tǒng)配置自行設置，所以無需再設置此參數(shù)。

-XX:CMSFullGCsBeforeCompaction=0：由于并發(fā)收集器不對內(nèi)存空間進行壓縮和整理，所以運行一段時間并行收集以后會產(chǎn)生內(nèi)存碎片，內(nèi)存使用效率降低。此參數(shù)設置運行0次Full GC后對內(nèi)存空間進行壓縮和整理，即每次Full GC后立刻開始壓縮和整理內(nèi)存。

-XX:+UseCMSCompactAtFullCollection：打開內(nèi)存空間的壓縮和整理，在Full GC后執(zhí)行?？赡軙绊懶阅?，但可以消除內(nèi)存碎片。

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

-XX:CMSInitiatingOccupancyFraction=70：表示年老代內(nèi)存空間使用到70%時就開始執(zhí)行CMS收集，以確保年老代有足夠的空間接納來自年輕代的對象，避免Full GC的發(fā)生。

其它垃圾回收參數(shù)

-XX:+ScavengeBeforeFullGC：年輕代GC優(yōu)于Full GC執(zhí)行。

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

-XX:+UseThreadPriorities：啟用本地線程優(yōu)先級API。即使 java.lang.Thread.setPriority() 生效，不啟用則無效。

-XX:SoftRefLRUPolicyMSPerMB=0：軟引用對象在最后一次被訪問后能存活0毫秒（JVM默認為1000毫秒）。

-XX:TargetSurvivorRatio=90：允許90%的Survivor區(qū)被占用（JVM默認為50%）。提高對于Survivor區(qū)的使用率。

JVM參數(shù)優(yōu)先級

-Xmn，-XX:NewSize/-XX:MaxNewSize，-XX:NewRatio 3組參數(shù)都可以影響年輕代的大小，混合使用的情況下，優(yōu)先級是什么？

答案如下：

高優(yōu)先級：-XX:NewSize/-XX:MaxNewSize 中優(yōu)先級：-Xmn（默認等效 -Xmn=-XX:NewSize=-XX:MaxNewSize=?） 低優(yōu)先級：-XX:NewRatio

推薦使用-Xmn參數(shù)，原因是這個參數(shù)簡潔，相當于一次設定 NewSize/MaxNewSIze，而且兩者相等，適用于生產(chǎn)環(huán)境。-Xmn 配合 -Xms/-Xmx，即可將堆內(nèi)存布局完成。

-Xmn參數(shù)是在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];          }      }  }

  1.  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

2.

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執(zhí)行器執(zhí)行 -Xmn10M :表示設置年輕代值為10M -Xms40M :表示設置堆內(nèi)存的最小Heap值為40M -Xmx60M :表示設置堆內(nèi)存的最大Heap值為60M -XX:+PrintCommandLineFlags:打印顯式隱式參數(shù),就是結果前三行 -XX:+PrintGC : 打印垃圾回收有關信息 HelloGC :這是需要執(zhí)行的啟動類 PrintGCDetails :打印GC詳細信息 PrintGCTimeStamps :打印GC時間戳 PrintGCCauses :打印GC產(chǎn)生的原因

結果解釋:

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

表示使用CMS垃圾收集器,同時打印參數(shù) 打印結果:

-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

  4.  java -XX:+PrintFlagsInitial 默認參數(shù)值

  5.   java -XX:+PrintFlagsFinal 最終參數(shù)值

  6.  java -XX:+PrintFlagsFinal | grep xxx 找到對應的參數(shù)

  7.  java -XX:+PrintFlagsFinal -version |grep GC

JVM調(diào)優(yōu)流程

JVM調(diào)優(yōu),設計到三個大的方面,在服務器出現(xiàn)問題之前要先根據(jù)業(yè)務場景選擇合適的垃圾處理器,設置不同的虛擬機參數(shù),運行中觀察GC日志,分析性能,分析問題定位問題,虛擬機排錯等內(nèi)容,如果服務器掛掉了,要及時生成日志文件便于找到問題所在。

調(diào)優(yōu)前的基礎概念

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

吞吐量=用戶代碼執(zhí)行時間用戶代碼執(zhí)行時間+垃圾回收執(zhí)行時間吞吐量=用戶代碼執(zhí)行時間用戶代碼執(zhí)行時間+垃圾回收執(zhí)行時間

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

對吞吐量、響應時間、QPS、并發(fā)數(shù)相關概念可以參考:吞吐量（TPS）、QPS、并發(fā)數(shù)、響應時間（RT）概念

所謂調(diào)優(yōu)，首先確定追求什么,是吞吐量? 還是追求響應時間？還是在滿足一定的響應時間的情況下，要求達到多大的吞吐量,等等。一般情況下追求吞吐量的有以下領域:科學計算、數(shù)據(jù)挖掘等。吞吐量優(yōu)先的垃圾處理器組合一般為：Parallel Scavenge + Parallel Old （PS + PO）。

而追求響應時間的業(yè)務有：網(wǎng)站相關 （JDK 1.8之后 G1,之前可以ParNew + CMS + Serial Old）

什么是調(diào)優(yōu)？

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術社區(qū)

2.  根據(jù)需求進行JVM規(guī)劃和預調(diào)優(yōu)

3.  優(yōu)化運行JVM運行環(huán)境（慢，卡頓）

4.  解決JVM運行過程中出現(xiàn)的各種問題(OOM)

調(diào)優(yōu)之前的規(guī)劃

•  調(diào)優(yōu)，從業(yè)務場景開始，沒有業(yè)務場景的調(diào)優(yōu)都是耍流氓

•  無監(jiān)控（壓力測試，能看到結果），不調(diào)優(yōu)

•  步驟：

      1.

      2.  或者每天產(chǎn)生一個日志文件

      1.  響應時間、停頓時間 [CMS G1 ZGC] （需要給用戶作響應）

      2.  吞吐量 = 用戶時間 /( 用戶時間 + GC時間) [PS+PO]

      1.  熟悉業(yè)務場景（沒有最好的垃圾回收器，只有最合適的垃圾回收器）

      2.  選擇回收器組合

      3.  計算內(nèi)存需求（經(jīng)驗值 1.5G 16G）

      4.  選定CPU（越高越好）

      5.  設定年代大小、升級年齡

      6.  設定日志參數(shù)   

-Xloggc:/opt/xxx/logs/xxx-xxx-gc-%t.log        -XX:+UseGCLogFileRotation        -XX:NumberOfGCLogFiles=5        -XX:GCLogFileSize=20M        -XX:+PrintGCDetails        -XX:+PrintGCDateStamps        -XX:+PrintGCCause

日志參數(shù)解釋說明:

/opt/xxx/logs/xxx-xxx-gc-%t.log 中XXX表示路徑,%t表示時間戳,意思是給日志文件添加一個時間標記,如果不添加的話,也就意味著每次虛擬機啟動都會使用原來的日志名,那么會被重寫。

Rotation中文意思是循環(huán)、輪流,意味著這個GC日志會循環(huán)寫

GCLogFileSize=20M 指定一個日志大小為20M,太大了不利于分析,太小又會產(chǎn)生過多的日志文件

NumberOfGCLogFiles=5 : 指定生成的日志數(shù)目

PrintGCDateStamps :PrintGCDateStamps會打印具體的時間，而PrintGCTimeStamps

主要打印針對JVM啟動的時候的相對時間，相對來說前者更消耗內(nèi)存。

  7.  觀察日志情況 日志有分析工具,可視化分析工具有GCeasy和GCViewer。

CPU高負荷排查流程

  1.  系統(tǒng)CPU經(jīng)常100%，如何調(diào)優(yōu)？(面試高頻) CPU100%那么一定有線程在占用系統(tǒng)資源，

      a.  找出哪個進程cpu高（top）

      b.  該進程中的哪個線程cpu高（top -Hp）

      c.  導出該線程的堆棧 (jstack)

      d.  查找哪個方法（棧幀）消耗時間 (jstack)

      e.  工作線程占比高 | 垃圾回收線程占比高

  2.  系統(tǒng)內(nèi)存飆高，如何查找問題？（面試高頻）

      a.  導出堆內(nèi)存 (jmap)

      b.  分析 (jhat jvisualvm mat jprofiler ... )

  3.  如何監(jiān)控JVM

      a.  jstat jvisualvm jprofiler arthas top...

CPU高負荷排查案例

  1.  測試代碼： 

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;     /**      * 從數(shù)據(jù)庫中讀取信用數(shù)據(jù)，套用模型，并把結果進行記錄和傳輸     */     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;         }     }

  2.  java -Xms200M -Xmx200M -XX:+PrintGC com.courage.jvm.gc.T15_FullGC_Problem01

  3.  收到CPU報警信息（CPU Memory）

  4.  top命令觀察到問題：內(nèi)存不斷增長 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

  5.  top -Hp 觀察進程中的線程，哪個線程CPU和內(nèi)存占比高 

[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

 6.   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

  7.  為什么阿里規(guī)范里規(guī)定，線程的名稱（尤其是線程池）都要寫有意義的名稱 怎么樣自定義線程池里的線程名稱？（自定義ThreadFactory）

  8.  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

  9.  jstat -gc 動態(tài)觀察gc情況 / 閱讀GC日志發(fā)現(xiàn)頻繁GC / arthas觀察 / jconsole/jvisualVM/ Jprofiler（最好用）

jstat gc 4655 500 : 每500毫秒打印端口4655的GC的情況

•  **S0C：**第一個幸存區(qū)的大小

•  **S1C：**第二個幸存區(qū)的大小

•  **S0U：**第一個幸存區(qū)的使用大小

•  **S1U：**第二個幸存區(qū)的使用大小

•  **EC：**伊甸園區(qū)的大小

•  **EU：**伊甸園區(qū)的使用大小

•  **OC：**老年代大小

•  **OU：**老年代使用大小

•  **MC：**方法區(qū)大小

•  **MU：**方法區(qū)使用大小

•  **CCSC:**壓縮類空間大小

•  **CCSU:**壓縮類空間使用大小

•  **YGC：**年輕代垃圾回收次數(shù)

•  **YGCT：**年輕代垃圾回收消耗時間

•  **FGC：**老年代垃圾回收次數(shù)

•  **FGCT：**老年代垃圾回收消耗時間

•  **GCT：**垃圾回收消耗總時間

如果面試官問你是怎么定位OOM問題的？能否用圖形界面（不能!因為圖形界面會影響服務器性能） 1：已經(jīng)上線的系統(tǒng)不用圖形界面用什么？（cmdline arthas） 2：圖形界面到底用在什么地方？測試！測試的時候進行監(jiān)控?。▔簻y觀察）

  10.  jmap -histo 6892 | head -10，查找有多少對象產(chǎn)生

這明顯能看出來是1對應的類創(chuàng)造的實例instances太多了,反過來追蹤代碼

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

線上系統(tǒng)，內(nèi)存特別大，jmap執(zhí)行期間會對進程產(chǎn)生很大影響，甚至卡頓（電商不適合） 1：設定了參數(shù)HeapDump，OOM的時候會自動產(chǎn)生堆轉儲文件 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文件存放位置:

 12.   java -Xms20M -Xmx20M -XX:+UseParallelGC -XX:+HeapDumpOnOutOfMemoryError com.courage.jvm.gc.T15_FullGC_Problem01 上面的意思是當發(fā)生內(nèi)存溢出時自動生成堆轉儲文件,需要注意的是,如果生成了這個文件先不要重啟服務器,將這個文件保存好之后再重啟。

  13.  使用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查找特定問題對象

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

  14.  最后找到代碼的問題

JVM調(diào)優(yōu)工具

jconsole遠程連接

  1.  程序啟動加入?yún)?shù)：   

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

  2.  如果遭遇 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

  3.  關閉linux防火墻（實戰(zhàn)中應該打開對應端口）

service iptables stop  chkconfig iptables off #永久關閉

  4.  windows上打開 jconsole遠程連接 192.168.182.130:11111

jvisualvm遠程連接

這個軟件在JDK8以后版本中移除了,使用的話需要額外下載,并且要在etc/visualvm.conf中修改默認的JDK_Home地址。參考:使用jvisualvm的jstatd方式遠程監(jiān)控Java程序

阿里巴巴Arthas

這個直接看官網(wǎng)就行了,純中文:Arthas 用戶文檔

JVM調(diào)優(yōu)案例

參數(shù)設置之承受海量訪問的動態(tài)Web應用

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

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

調(diào)優(yōu)說明：-Xmx 與 -Xms 相同以避免JVM反復重新申請內(nèi)存。-Xmx 的大小約等于系統(tǒng)內(nèi)存大小的一半，即充分利用系統(tǒng)資源，又給予系統(tǒng)安全運行的空間。-Xmn1256m 設置年輕代大小為1256MB。此值對系統(tǒng)性能影響較大，Sun官方推薦配置年輕代大小為整個堆的3/8。-Xss128k 設置較小的線程棧以支持創(chuàng)建更多的線程，支持海量訪問，并提升系統(tǒng)性能。-XX:SurvivorRatio=6 設置年輕代中Eden區(qū)與Survivor區(qū)的比值。系統(tǒng)默認是8，根據(jù)經(jīng)驗設置為6，則2個Survivor區(qū)與1個Eden區(qū)的比值為2:6，一個Survivor區(qū)占整個年輕代的1/8。-XX:ParallelGCThreads=8 配置并行收集器的線程數(shù)，即同時8個線程一起進行垃圾回收。此值一般配置為與CPU數(shù)目相等。-XX:MaxTenuringThreshold=0 設置垃圾最大年齡（在年輕代的存活次數(shù)）。如果設置為0的話，則年輕代對象不經(jīng)過Survivor區(qū)直接進入年老代。對于年老代比較多的應用，可以提高效率；如果將此值設置為一個較大值，則年輕代對象會在Survivor區(qū)進行多次復制，這樣可以增加對象再年輕代的存活時間，增加在年輕代即被回收的概率。根據(jù)被海量訪問的動態(tài)Web應用之特點，其內(nèi)存要么被緩存起來以減少直接訪問DB，要么被快速回收以支持高并發(fā)海量請求，因此其內(nèi)存對象在年輕代存活多次意義不大，可以直接進入年老代，根據(jù)實際應用效果，在這里設置此值為0。-XX:+UseConcMarkSweepGC 設置年老代為并發(fā)收集。CMS（ConcMarkSweepGC）收集的目標是盡量減少應用的暫停時間，減少Full GC發(fā)生的幾率，利用和應用程序線程并發(fā)的垃圾回收線程來標記清除年老代內(nèi)存，適用于應用中存在比較多的長生命周期對象的情況。

參數(shù)設置之內(nèi)部集成構建服務器

高性能數(shù)據(jù)處理的工具應用 服務器配置：1 核 CPU, 4G MEM, JDK 1.6.X 參數(shù)方案：-server -XX:PermSize=196m -XX:MaxPermSize=196m -Xmn320m -Xms768m -Xmx1024m 調(diào)優(yōu)說明：-XX:PermSize=196m -XX:MaxPermSize=196m 根據(jù)集成構建的特點，大規(guī)模的系統(tǒng)編譯可能需要加載大量的Java類到內(nèi)存中，所以預先分配好大量的持久代內(nèi)存是高效和必要的。-Xmn320m 遵循年輕代大小為整個堆的3/8原則。-Xms768m -Xmx1024m 根據(jù)系統(tǒng)大致能夠承受的堆內(nèi)存大小設置即可。

到此，關于“如何理解JVM調(diào)優(yōu)參數(shù)、方法、工具”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續(xù)學習更多相關知識，請繼續(xù)關注創(chuàng)新互聯(lián)網(wǎng)站，小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>

分享標題：如何理解JVM調(diào)優(yōu)參數(shù)、方法、工具
標題路徑：http://jinyejixie.com/article18/igojdp.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站改版、響應式網(wǎng)站、域名注冊、網(wǎng)站排名、手機網(wǎng)站建設、關鍵詞優(yōu)化

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉載內(nèi)容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)