JVM調優參數、方法、工具以及案例總結
這種文章挺難寫的,一是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
虛擬機參數
并行收集器相關參數
CMS處理器參數設置
JVM輔助信息參數設置
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：設置年輕代為并發收集?？膳cCMS收集同時使用。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];
- }
- }
- }
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執行器執行 -Xmn10M :表示設置年輕代值為10M -Xms40M :表示設置堆內存的最小Heap值為40M -Xmx60M :表示設置堆內存的最大Heap值為60M -XX:+PrintCommandLineFlags:打印顯式隱式參數,就是結果前三行 -XX:+PrintGC : 打印垃圾回收有關信息 HelloGC :這是需要執行的啟動類 PrintGCDetails :打印GC詳細信息 PrintGCTimeStamps :打印GC時間戳 PrintGCCauses :打印GC產生的原因
結果解釋:
3. 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
4. java -XX:+PrintFlagsInitial 默認參數值
5. java -XX:+PrintFlagsFinal 最終參數值
6. java -XX:+PrintFlagsFinal | grep xxx 找到對應的參數
7. java -XX:+PrintFlagsFinal -version |grep GC
JVM調優流程
JVM調優,設計到三個大的方面,在服務器出現問題之前要先根據業務場景選擇合適的垃圾處理器,設置不同的虛擬機參數,運行中觀察GC日志,分析性能,分析問題定位問題,虛擬機排錯等內容,如果服務器掛掉了,要及時生成日志文件便于找到問題所在。
調優前的基礎概念
目前的垃圾處理器中,一類是以吞吐量優先,一類是以響應時間優先:
吞吐量=用戶代碼執行時間用戶代碼執行時間+垃圾回收執行時間吞吐量=用戶代碼執行時間用戶代碼執行時間+垃圾回收執行時間
響應時間：STW越短，響應時間越好
對吞吐量、響應時間、QPS、并發數相關概念可以參考:吞吐量（TPS）、QPS、并發數、響應時間（RT）概念
所謂調優，首先確定追求什么,是吞吐量? 還是追求響應時間？還是在滿足一定的響應時間的情況下，要求達到多大的吞吐量,等等。一般情況下追求吞吐量的有以下領域:科學計算、數據挖掘等。吞吐量優先的垃圾處理器組合一般為：Parallel Scavenge + Parallel Old （PS + PO）。
而追求響應時間的業務有：網站相關 （JDK 1.8之后 G1,之前可以ParNew + CMS + Serial Old）
什么是調優？
- 根據需求進行JVM規劃和預調優
- 優化運行JVM運行環境（慢，卡頓）
- 解決JVM運行過程中出現的各種問題(OOM)
調優之前的規劃
- 調優，從業務場景開始，沒有業務場景的調優都是耍流氓
- 無監控（壓力測試，能看到結果），不調優
- 步驟：
1.
2. 或者每天產生一個日志文件
1. 響應時間、停頓時間 [CMS G1 ZGC] （需要給用戶作響應）
2. 吞吐量 = 用戶時間 /( 用戶時間 + GC時間) [PS+PO]
1. 熟悉業務場景（沒有最好的垃圾回收器，只有最合適的垃圾回收器）
2. 選擇回收器組合
3. 計算內存需求（經驗值 1.5G 16G）
4. 選定CPU（越高越好）
5. 設定年代大小、升級年齡
6. 設定日志參數
- -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啟動的時候的相對時間，相對來說前者更消耗內存。
7. 觀察日志情況 日志有分析工具,可視化分析工具有GCeasy和GCViewer。
CPU高負荷排查流程
1. 系統CPU經常100%，如何調優？(面試高頻) CPU100%那么一定有線程在占用系統資源，
a. 找出哪個進程cpu高（top）
b. 該進程中的哪個線程cpu高（top -Hp）
c. 導出該線程的堆棧 (jstack)
d. 查找哪個方法（棧幀）消耗時間 (jstack)
e. 工作線程占比高 | 垃圾回收線程占比高
2. 系統內存飆高，如何查找問題？（面試高頻）
a. 導出堆內存 (jmap)
b. 分析 (jhat jvisualvm mat jprofiler ... )
3. 如何監控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;
- /**
- * 從數據庫中讀取信用數據，套用模型，并把結果進行記錄和傳輸
- */
- 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命令觀察到問題：內存不斷增長 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和內存占比高
- [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. 為什么阿里規范里規定，線程的名稱（尤其是線程池）都要寫有意義的名稱 怎么樣自定義線程池里的線程名稱？（自定義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 動態觀察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：圖形界面到底用在什么地方？測試！測試的時候進行監控！（壓測觀察）
10. jmap -histo 6892 | head -10，查找有多少對象產生
- 這明顯能看出來是1對應的類創造的實例instances太多了,反過來追蹤代碼
11. 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文件存放位置:
12. java -Xms20M -Xmx20M -XX:+UseParallelGC -XX:+HeapDumpOnOutOfMemoryError com.courage.jvm.gc.T15_FullGC_Problem01 上面的意思是當發生內存溢出時自動生成堆轉儲文件,需要注意的是,如果生成了這個文件先不要重啟服務器,將這個文件保存好之后再重啟。
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調優工具
jconsole遠程連接
1. 程序啟動加入參數：
- 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防火墻（實戰中應該打開對應端口）
- service iptables stop
- chkconfig iptables off #永久關閉
4. 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 根據系統大致能夠承受的堆內存大小設置即可。
