JVM 性能監控調優

原創 疾跑的蜗牛 2018-08-27 19:35


參考：http://www.cnblogs.com/java-zhao/category/776216.html(萬分感謝，學了好多東西)

1. JVM性能監控

1、定位系統問題

  • 依據
    • GC日誌
    • 堆轉儲快照（heapdump/hprof文件）
    • 線程快照（threaddump/javacore文件）
    • 運行日誌
    • 異常堆棧
  • 分析依據的工具
    • jps：顯示指定系統內的所有JVM進程
    • jstat：收集JVM各方面的運行數據
    • jinfo：顯示JVM配置信息
    • jmap：形成堆轉儲快照（heapdump文件）
    • jhat：分析heapdump文件
    • jstack：顯示JVM的線程快照
    • jconsole
    • visualVM

說明：後邊兩種是具有圖形化界面的。

 

2、jps（是其他所有命令的基礎）

作用：列出所有的JVM虛擬機進程。

格式：jps -l

 

3、jstat（是沒有GUI界面的情況下，在運行期定位JVM性能問題的首選）

作用：查看gc數據和類加載卸載數據

格式：jstat option PID interval count

意義：每隔interval毫秒做一次option，一共做count次

說明：S0(from區)使用了41.74%；S1(to區)使用了0；E(Eden區)使用了54.35%；O(Old，年老代)使用了62.41%；P(Perment，永久代)使用了99.63%；YGC(Young GC)了32次，YGCT(Young GC Time)花銷0.132秒；FGC(Full GC)了1次，FGCT(Full GC Time)花銷0.102秒；GCT(GC Time)總花銷0.234秒。

分析：其實上邊這個查詢結果可以直接看出，我們需要加大P（永久代大小）

說明：加載了3683個類，總共佔有4355.3字節；卸載了0個類，卸載的類的字節數爲0，類的加載與卸載共花銷3.16秒

更多的jstat的使用，參看http://my.oschina.net/skyline520/blog/304805

 

4、jinfo

作用：查看和運行期修改JVM的配置參數

格式：jinfo -flag parameter PID

說明：查看3732進程下的MaxTenuringThreshold參數值。

說明：修改3732進程下的MaxTenuringThreshold參數值，但是windows下失敗。

 

5、jmap

作用：生成堆轉儲快照和查看最佔內存的元素，用於分析內存泄露問題

格式（生成堆轉儲快照）：jmap -dump:format=b,file=文件名 PID

說明：生成了3732進程的堆轉儲文件myfile

格式（查看最佔內存的元素）：jmap -histo PID

說明：結果自己去看，太多了

 

6、jhat

作用：分析堆轉儲快照（與jmap配合）

格式：jhat 文件名

說明：執行上述命令後，打開localhost:7000，找到如下紅框部分打開，這裏纔是我們最關注的東西。

注意：該工具是萬不得已才用的。

推出命令使用”ctrl+c”

 

7、jstack

作用：生成線程快照，定位線程長時間卡頓的原因（線程間死鎖、死循環、請求外部資源導致的長時間等待）

格式：jstack -l PID

說明：查看3732進程中的所有線程的堆棧信息

《深入理解Java虛擬機》的作者提供了一個工具jsp頁面，使得我們可以在程序運行時，隨時運行該jsp頁面，來查看線程堆棧信息，代碼如下：

複製代碼
 1 <%@ page language="java" contentType="text/html; charset=UTF-8"
 2     pageEncoding="UTF-8" import="java.util.Map"%>
 3 <!DOCTYPE html>
 4 <html>
 5 <head>
 6 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
 7 <title>jstack</title>
 8 </head>
 9 <body>
10 <% 
11     for(Map.Entry<Thread, StackTraceElement[]> stackTrace : Thread.getAllStackTraces().entrySet()){
12         Thread thread = (Thread)stackTrace.getKey();
13         StackTraceElement[] elements = (StackTraceElement[])stackTrace.getValue();
14         
15         /* if(thread.equals(Thread.currentThread())){
16             continue;
17         } */
18         out.println("\n線程："+thread.getName()+"\n");
19         for(StackTraceElement ele : elements){
20             out.println("\t"+ele+"\n");
21         }
22     }
23 %>
24 </body>
25 </html>
複製代碼

注意：代碼中我註釋掉一段，是因爲想也查出當前線程的堆棧信息，作者並沒有這個註釋。

 

總結：

  • JVM性能相關的6個常用的JDK命令
    • jps：查詢JVM中的所有進程，找出將要操作的PID，是所有命令的基礎
    • jstat：查看相應JVM進程的gc、類加載卸載信息，是沒有GUI界面查看JVM運行數據的首選
    • jinfo：查看和在運行期動態修改JVM配置參數
    • jmap：生成堆轉儲快照和比較佔內存的對象
    • jhat：配合jmap分析堆轉儲日誌，除非沒有其他工具可做這個事兒，否則就不用該工具
    • jstack：生成線程快照，定位線程長時間卡頓的原因（線程間死鎖、死循環、請求外部資源導致的長時間等待）
  • 輸出gc信息到控制檯
    • -XX:+PrintGCDetails：輸出GC的詳細信息
    • -XX:+PrintGCTimeStamps：輸出GC的時間信息
    • -XX:+PrintGCApplicatonStoppedTime：GC造成的應用暫停的時間
  • 輸出gc信息到文件
    • 以上三個參數在這裏依舊適用
    • -Xloggc:文件路徑/gc.log：輸出到文件


圖形化的JVM性能監控


1、圖像化的故障處理工具

  • Jconsole
  • visualVM

2、Jconsole

進入”E:\Java\jdk1.6\bin”，雙擊”jconsole.exe”，彈出如下框：

說明：這裏列出了所有的JVM進程，一個Jconsole進程，一個eclipse（PID：4684），這相當於jps命令。

選中其中一個PID，假設選中了eclipse，雙擊，出現下圖：（注：之後的各個葉籤，都是每4秒刷新一次）

“內存”：相當於jstat -gc，在上圖中的詳細信息部分，該部分對應的信息就是頭部圖表部分所寫的參數（這裏是”整個堆”的情況），同時對應的也是右下角部分柱狀圖所選中的柱子（這裏是”堆”），對於”非堆”指的就是”方法區”（或者稱爲”永久代”）。當然，這裏也可以選擇時間範圍來查看相應的信息。

“類”：相當於jstat -class，列出了裝載類和卸載類的相關信息。

“線程”：相當於jstack，折線圖顯示了線程數目的變化情況，包括峯值線程數量、活動線程數量；左下角展示了所有線程名稱。雙擊相應的線程名稱

“VM摘要”：相當於jinfo

最後，測試一下線程死鎖的現象。代碼如下：

 View Code

執行main()方法，之後去查看”線程”標籤，點擊”檢測死鎖”，如下：

發現線程Thread-95和Thread-106死鎖（彼此擁有對方想要的鎖）

分析：

1）Integer緩存機制

Integer.valueOf(int xxx)，該方法爲了減少對象的創建，節省內存，會將xxx轉化成的Integer對象緩存起來，之後只要是相同的xxx，那麼這個方法都會直接從緩存中取出對象來。假設代碼中的Integer.valueOf(1)生成的對象是java.lang.Integer@987197，而Integer.valueOf(2)生成的對象是java.lang.Integer@15e293a，那麼之後無論調用多少次Integer.valueOf(1)，也無論是哪一個線程去調用該方法，返回的都只是同一個對象java.lang.Integer@987197。也就是說上邊的這段代碼中的Integer.valueOf(i)只會生成兩個不同的對象，就是java.lang.Integer@987197和java.lang.Integer@15e293a，而這兩個對象也就是我們的鎖對象。

2）死鎖發生的時機

假設線程”Thread-95”執行到其第一個synchronized塊中時（假設剛剛獲取了鎖對象java.lang.Integer@987197），這時候CPU時間片切換給了線程”Thread-106”，而”Thread-106”執行其第一個synchronized塊（獲取了鎖對象java.lang.Integer@15e293a），之後”Thread-106”要執行第二個synchronized塊兒來獲取鎖對象java.lang.Integer@987197，這時候就獲取不到了，因爲這個鎖對象正被”Thread-95”所持有，於是”Thread-106”就阻塞在java.lang.Integer@987197這個鎖對象上，這時，假設CPU時間片又切換給了”Thread-95”，該線程要執行第二個synchronized塊來獲取java.lang.Integer@15e293a，就獲取不到了，因爲該鎖對象已被”Thread-106”所持有

3）結果

“Thread-95”持有鎖對象java.lang.Integer@987197，阻塞在鎖對象java.lang.Integer@15e293a；

“Thread-106”持有鎖對象java.lang.Integer@15e293a，阻塞在鎖對象java.lang.Integer@987197

 

3、visualVM

是一塊更加全面的GUI監視工具，包含很多插件（需要自己下載），具體的見《深入理解Java虛擬機（第二版）》


JVM調優

1、JVM的調優主要是內存的調優，主要調兩個方面：

  • 各個代的大小
  • 垃圾收集器選擇

2、各個代的大小

  • 常用的調節參數
    • -Xmx
    • -Xms
    • -Xmn
    • -XX:SurvivorRatio
    • -XX:MaxTenuringThreshold
    • -XX:PermSize
    • -XX:MaxPermSize

  • 原則
    • -Xmx==-Xms：防止堆內存頻繁進行調整，調整的時機見《第一章 JVM內存結構》
    • -Xmn：通常設爲-Xmx/4（這是我在企業中實習時的設置方式，系統運行正常、平穩、速度也快），林昊推薦的是-Xmx/3，所以-Xmn==-Xmx/4~-Xmx/3
      • 調節時機：minor GC太頻繁
      • -Xmn過小：minor GC太頻繁；小對象可能也會直接進入年老代，提前導致Full GC
      • -Xmn過大：年輕代大了，minor GC的時間變長了；年老代變小了，Full GC會頻繁
      • 調節策略：若-Xmx可調大，則調大，且保持-Xmn==-Xmx/4~-Xmx/3；若-Xmx不可調大，在保持-Xmn==-Xmx/4~-Xmx/3的範圍內增大-Xmn，若-Xmn也不可調了，則試着調大-XX:SurvivorRatio來看看情況

    • -XX:SurvivorRatio：默認8
      • -XX:SurvivorRatio過大：Eden變大，Survivor變小，minor GC可能減少，但是由於suvivor減小了，所以如果minor GC存活下來的對象大於suvivor，則會直接進入年老代
      • -XX:SurvivorRatio過小：Eden變小，Survivor變大，minor GC可能增多，但是由於suvivor變大了，能夠存儲更多存活下來的對象，進入年老代的對象可能會減少

    • -XX:MaxTenuringThreshold：默認爲15
      • -XX:SurvivorRatio過大：對象在年輕代的存活時間變長，可能在年輕代就被回收掉而不必進入年老代，但是相應的複製的時候survivor區就會被佔用更多的空間。
      • -XX:SurvivorRatio過大：對象在年輕代的存活時間變短，可能會早早進入年老代而失去在年輕代被回收的機會，但是相應的複製的時候survivor區也就有更多內存了，這樣可能會避免部分大對象直接進入年老代

    • -XX:MaxPermSize==-XX:PermSize
      • 在實際開發中，前臺不要使用jsp，使用velocity等模板引擎技術
      • 不要引入無關的jar


3、垃圾收集器選擇

企業中最常用的兩個組合：（這裏由於大部分大型企業用的還是JDK1.6，所以G1不說）

關於下邊兩組垃圾收集器的詳細原理見：第五章 JVM垃圾收集器（1）

  • Parallel Scavenge/Parallel Old
    • 注重吞吐量（吞吐量越大，說明CPU利用率越高）
    • 主要用於處理很多的CPU計算任務而用戶交互任務較少的情況
    • 也用於讓JVM自動調優而我們袖手旁觀的情況（-XX:+UseParallelOldGC，-XX:GCTimeRatio，-Xmx，-XX:+UseAdaptiveSizePolicy）
    • -XX:+UseParallelOldGC：指定使用該組合

  • ParNew/CMS
    • 注重STW的縮短（該時間越短，用戶體驗越好，而且會減少部分請求的請求超時問題）
    • -XX:+UseConcMarkSweepGC：指定使用該組合
    • -XX:CMSInitiatingOccupancyFraction：來指定當年老代空間滿了多少後（百分比）進行垃圾回收

  • 關於上邊兩種組合的說明
    • 一般而言，在企業中，機器的CPU數量都比較多，且CPU的計算能力也不會成爲瓶頸，所以對於CMS的併發標記與併發清除階段，會佔用CPU資源的問題，其實不是大事兒；而對於Parallel的注重吞吐量的問題也就不是什麼大事兒了，畢竟CPU是強大的
    • 所以，ParNew/CMS是首選（在G1不能用的情況下），Parallel Scavenge/Parallel Old只在想讓JVM自動管理內存的情況下使用

注意：在實際調優過程中，可以使用jstat、jconsole、visualVM或GC日誌的檢測數據來調，具體的示例見《深入理解java虛擬機（第二版）》p142對eclipse運行速度的調優。

關於GC日誌的參數含義與每一種垃圾收集器的GC日誌的格式，查看《深入理解Java虛擬機（第二版）》的P89和《深入分析Java web技術內幕（修訂版）》的P224


發表評論
所有評論
還沒有人評論，想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章

JVM的內存區域劃分

相由心生fhy 2018-08-27 20:02:39

Java Heap sapce 與 Java PermGen space

yangyangisse 2018-08-27 20:02:03

在知乎推出Java求職類專欄文章

义臻 2018-08-27 20:00:05

java ClassLoader作用

花开花落半春秋 2018-08-27 19:34:09

JAVA虛擬機內存結構

刘坤RUI 2018-08-27 19:33:49

JVM內存模型

auleit 2018-08-27 19:17:02

JVM概述

auleit 2018-08-27 19:17:01

類的加載機制

auleit 2018-08-27 19:17:00

JVM垃圾回收機制

auleit 2018-08-27 19:16:44

Java 類加載機制

Andy2019 2018-08-27 18:53:43

第2章 Java內存區域與內存溢出異常

Andy2019 2018-08-27 18:53:36

JVM調優——Java動態編譯過程中的內存溢出問題

J_java1 2018-08-27 18:49:54

基於JVM之上的併發編程模式剖析

J_java1 2018-08-27 18:49:54

不談架構，看看如何從代碼層面優化系統性能！

J_java1 2018-08-27 18:49:51

Java執行那些事——類加載機制（ 上）

大圣代 2018-08-27 18:44:10