JVM調優系列：（五）JVM常用調試參數和工具
轉自：http://blog.csdn.net/opensure/article/details/46715769
JVM常用調試參數:
–verbose:gc在虛擬機發生內存回收時在輸出設備顯示信息
-Xloggc:filename把GC相關日誌信息記錄到文件以便分析
-XX:-HeapDumpOnOutOfMemoryError當首次遭遇OOM時導出此時堆中相關信息
-XX:OnError="<cmdargs>;<cmd args>" 出現致命ERROR之後運行自定義命令
-XX:-PrintClassHistogram遇到Ctrl-Break後打印類實例的柱狀信息，與jmap -histo功能相同
-XX:-PrintConcurrentLocks遇到Ctrl-Break後打印並發鎖的相關信息，與jstack -l功能相同
-XX:-PrintGC每次GC時打印相關信息
-XX:-PrintGCDetails每次GC時打印詳細信息
-XX:-PrintGCTimeStamps打印每次GC的時間戳
-XX:+PrintGCApplicationStoppedTime打印垃圾回收期間程序暫停的時間
-XX:+PrintHeapAtGC打印GC前後的詳細堆棧信息
-XX:+PrintTenuringDistribution查看每次minor GC後新的存活周期的閾值,即在年輕代survivor中的復制次數.
-XX:-TraceClassLoading跟蹤類的加載信息
-XX:-TraceClassUnloading跟蹤類的卸載信息
-XX:-TraceLoaderConstraints跟蹤類加載器約束的相關信息
-XX:ErrorFile=/opt/tomcat/bin/hs_error_%p.log Crash日誌
[GC [DefNew:209792K->4417K(235968K), 0.0201630 secs] 246722K->41347K(498112K),0.0204050 secs]
YoungGen內存區回收前209792K，回收後4417K, YoungGen大小是235968K, HEAP 內存區回收前246722K, 回收後41347K, heap的大小是498112K,GC消耗的時間是0.0204050 secs
[GC [1 CMS-initial-mark: 655374K(1310720K)] 662197K(1546688K), 0.0303050 secs] [Times: user=0.02 sys=0.02, real=0.03 secs]
[weak refs processing, 0.0417710 secs] [1 CMS-remark: 655734K(1310720K)] 766736K(1546688K), 0.0932010 secs] [Times: user=0.17 sys=0.00, real=0.09 secs]
CMS-initial-mark階段暫停了0.0303050秒，而CMS-remark階段暫停了0.0932010秒，因此兩次暫停的總共時間是0.123506秒.
兩種fail引起full gc：Prommotionfailed和Concurrent mode failed:
[ParNew (promotion failed): 320138K->320138K(353920K), 0.2365970 secs]
[CMS: 1458785K->1120688K(2520704K), 9.4584090 secs]
Prommotion failed由於救助空間不夠，從而向年老代轉移對象，年老代沒有足夠的空間來容納這些對象; 或者老生代空閑空間存在碎片，導致沒有足夠大的連續空間開存放新生代對，導致一次fullgc的產生。解決這個問題的辦法有兩種完全相反的傾向：增大救助空間、增大年老代。調整-XX:SurvivorRatio參數
Concurrent mode failed的產生是由於CMS回收年老代的速度太慢，導致年老代在CMS完成前就被沾滿，引起full gc，避免這個現象的產生就是調小-XX:CMSInitiatingOccupancyFraction參數的值.
java.lang.OutOfMemoryError:GC overhead limit exceeded:
JDK6新添的錯誤類型。是發生在GC占用大量時間為釋放很小空間的時候發生的，是一種保護機制。解決方案是，關閉該功能，使用-XX:-UseGCOverheadLimit. 需要查看是否有使用大內存的代碼或死循環。
JVM常用調試工具:
jconsole – jconsole是基於JavaManagementExtensions (JMX)的實時圖形化監測工具，這個工具利用了內建到JVM裏面的JMX指令來提供實時的性能和資源的監控，包括了Java程序的內存使用，Heap size, 線程的狀態，類的分配狀態和空間使用等等。Linux下設置環境變量如下：export DISPLAY=:0.0
jstatd–啟動jvm監控服務。它是一個基於rmi的應用，向遠程機器提供本機jvm應用程序的信息。默認端口1099。
-nr 當一個存在的RMI Registry沒有找到時，不嘗試創建一個內部的RMI Registry
-p port 端口號，默認為1099
-nrminame 默認為JStatRemoteHost；如果多個jstatd服務開始在同一臺主機上，rminame唯一確定一個jstatd服務
-J jvm選項
$JAVA_HOME/jre/lib/security/java.policy文件中添加下面的代碼：
grantcodebase "file:${java.home}/../lib/tools.jar" {
permission java.security.AllPermission;
};
默認端口為1099: jstatd -J-Djava.security.policy=jstatd.all.policy
指定hostname 指定端口: jstatd -J-Djava.rmi.server.hostname=192.168.8.7-J-Djava.security.policy=test/jstatd.all.policy -p 6001
啟動JMX: jstatd -J-Djava.rmi.server.hostname=192.168.8.7-J-Djava.security.policy=test/jstatd.all.policy -J-Dcom.sun.management.jmxremote.port=6001 -J-Dcom.sun.management.jmxremote.ssl=false-J-Dcom.sun.management.jmxremote.authenticate=false -J -Djava.awt.headless=true
(java.net.MalformedURLException:Local host name unknown: java.net.UnknownHostException: a: a
原因是/etc/hosts文件裏沒有主機名為：a的，解決方法就是在hosts文件中加入a:
127.0.0.1 a localhost)
jps –jps是用來查看JVM裏面所有進程的具體狀態, 包括進程ID，進程啟動的路徑等等。
-m 輸出傳遞給main方法的參數，如果是內嵌的JVM則輸出為null。
-l 輸出應用程序主類的完整包名，或者是應用程序JAR文件的完整路徑。
-v 輸出傳給JVM的參數。
jstack -- jstack用於打印出給定的java進程ID或core file或遠程調試服務的Java堆棧信息，如果是在64位機器上，需要指定選項"-J-d64",如果java程序崩潰生成core文件，jstack工具可以用來獲得core文件的java stack和nativestack的信息。Windows的jstack只支持-l.
-F當’jstack [-l] pid’沒有相應的時候強制打印棧信息
-l長列表. 打印關於鎖的附加信息,如屬於java.util.concurrent的ownable synchronizers列表.
-m打印java和native c/c++框架的所有棧信息.
Jstackpid 顯示jvm中當前所有線程的運行情況和線程當前狀態
jinfo –可以輸出並修改運行時的java 進程的opts。用處比較簡單，用於輸出JAVA系統參數及命令行參數。查看和修改運行中的java程序的運行環境參數。
jinfo-flag MaxPermSize 4084
jmap –jmap 可以從core文件或進程中獲得內存的具體匹配情況，包括Heap size, Perm size等等，打印出某個java進程（使用pid）內存內的，所有‘對象’的情況。
-heap ：打印jvm heap的情況
-histo： 打印jvm heap的直方圖。其輸出信息包括類名，對象數量，對象占用大小。
-histo：live ： 同上，但是只輸出存活對象的情況,會觸發FULL GC
-permstat： 打印permanentgeneration heap情況
jmap-dump:format=b,file=outfile 3024可以將3024進程的內存heap輸出出來到outfile文件裏，再配合JHAT進行分析.
Jhat用於對JAVA heap進行離線分析的工具，他可以對不同虛擬機中導出的heap信息文件進行分析，如LINUX上導出的文件可以拿到WINDOWS上進行分析
jhat -J-Xmx512m <heap dump file>
jstat – jstat利用了JVM內建的指令對Java應用程序的資源和性能進行實時的命令行的監控, 可以觀察到classloader，compiler，gc相關信息，包括了對Heap size和垃圾回收狀況的監控等等。
-class：統計class loader行為信息
-compile：統計編譯行為信息
-gc：統計jdk gc時heap信息
-gccapacity：統計不同的generations（不知道怎麽翻譯好，包括新生區，老年區，permanent區）相應的heap容量情況
-gccause：統計gc的情況，（同-gcutil）和引起gc的事件
-gcnew：統計gc時，新生代的情況
-gcnewcapacity：統計gc時，新生代heap容量
-gcold：統計gc時，老年區的情況
-gcoldcapacity：統計gc時，老年區heap容量
-gcpermcapacity：統計gc時，permanent區heap容量
-gcutil：統計gc時，heap情況
-compiler:顯示VM實時編譯的數量等信息
-snap: 查看Java進程的jvmstat的各個monitor的值
jstat-gc [email protected]
java-verbose:class PID輸出虛擬機裝入的類的信息, 當虛擬機報告類找不到或類沖突時可用此參數來診斷來查看虛擬機從裝入類的情況。
java –verbose:jni輸出native方法調用的相關情況，一般用於診斷jni調用錯誤信息
常用JVM分析信息獲取:
1、確認服務器上是否存在SUN JDK6，如果沒有建議安裝一個，我們需要使用裏面的工具（jps、jmap、jstat、jconsole、jstack）
2、 獲取MKEY的JAVA進程ID（後面簡稱PID）
a) 操作方法：進入SUN JDK的bin目錄在命令行中輸入jps，查看MKEY的進程ID
3、提取GC信息()
a) 操作方法：示例：jstat –gcPID 600000 43200 >> gc_20110909.log
4、 提取Heap區信息（間隔10分鐘提取一次）
a) 操作方法：jmap -heap PID >>heap_20110909.log
5、提取對象信息（間隔10分鐘提取一次）
a) 操作方法：jmap-histo PID > histo_*.log(文件較大,*按序號生成輸入)
6、線程轉儲日誌
a) jstack PID
b) 宕機日誌(在domain目錄,如果沒有宕機,條件允許的情況下可使用 kill -3 PID(此操作會殺掉進程))
精簡版:
服務器掛起後,在重啟之前執行以下命令:
jps-vl 查詢到相應的JAVA進程,簡稱PID
jstat –gcutilPID 5000 >> /opt/tomcat/bin/gcutil.log
vmstat3
jstackPID > /opt/tomcat/bin/jstack.log
jmap-histo PID > /opt/tomcat/bin/histo.log
網絡方面:
whiletrue; do A=$(netstat -n | awk ‘/^tcp/ {++S[$NF]} END {for(a in S) print a,S[a]}‘); echo $A ; sleep 3; done
netstat -an | grep1521
再重啟服務.提取相關日誌發出來
JVM調優系列：（五）JVM常用調試參數和工具