深刻JVM內核——原理、診斷與優化——經常使用JVM配置參數

java 獲取內存dump 的幾種方式

一、獲取內存詳情：jmap -dump:format=b,file=e.bin pid
這種方式能夠用 jvisualvm.exe 進行內存分析，或者採用 Eclipse Memory Analysis Tools (MAT)這個工具

2. 獲取內存dump：  jmap -histo:live pid
這種方式會先出發fullgc，全部若是不但願觸發fullgc 能夠使用jmap -histo pid

3.第三種方式：jdk啓動加參數：
-XX:+HeapDumpBeforeFullGC 
-XX:HeapDumpPath=/httx/logs/dump
這種方式會產生dump日誌，再經過jvisualvm.exe 或者Eclipse Memory Analysis Tools 工具進行分析

 

jstack

系統運行緩慢，CPU 100%，以及Full GC次數過多問題的排查思路

 

Trace跟蹤參數

-verbose:gc
-XX:+printGC
能夠打印GC的簡要信息
    [GC 4790K->374K(15872K), 0.0001606 secs]
    [GC 4790K->374K(15872K), 0.0001474 secs]
    [GC 4790K->374K(15872K), 0.0001563 secs]
    [GC 4790K->374K(15872K), 0.0001682 secs]

-XX:+PrintGCTimeStamps
    打印CG發生的時間戳

[GC[DefNew: 4416K->0K(4928K), 0.0001897 secs] 4790K->374K(15872K), 0.0002232 secs]
 [Times: user=0.00 sys=0.00, real=0.00 secs] 

 

-XX:+PrintGCDetails 打印GC詳細信息

Heap
 def new generation   total 13824K, used 11223K [0x27e80000, 0x28d80000, 0x28d80000)
  eden space 12288K,  91% used [0x27e80000, 0x28975f20, 0x28a80000)
  from space 1536K,   0% used [0x28a80000, 0x28a80000, 0x28c00000)
  to   space 1536K,   0% used [0x28c00000, 0x28c00000, 0x28d80000)
 tenured generation   total 5120K, used 0K [0x28d80000, 0x29280000, 0x34680000)
   the space 5120K,   0% used [0x28d80000, 0x28d80000, 0x28d80200, 0x29280000)
 compacting perm gen  total 12288K, used 142K [0x34680000, 0x35280000, 0x38680000)
   the space 12288K,   1% used [0x34680000, 0x346a3a90, 0x346a3c00, 0x35280000)
    ro space 10240K,  44% used [0x38680000, 0x38af73f0, 0x38af7400, 0x39080000)
    rw space 12288K,  52% used [0x39080000, 0x396cdd28, 0x396cde00, 0x39c80000)

 

-Xloggc:log/gc.log
    指定GC log的位置，以文件輸出
    幫助開發人員分析問題

 

-XX:+PrintHeapAtGC
    每次一次GC後，都打印堆信息

{Heap before GC invocations=0 (full 0):
 def new generation   total 3072K, used 2752K [0x33c80000, 0x33fd0000, 0x33fd0000)
  eden space 2752K, 100% used [0x33c80000, 0x33f30000, 0x33f30000)
  from space 320K,   0% used [0x33f30000, 0x33f30000, 0x33f80000)
  to   space 320K,   0% used [0x33f80000, 0x33f80000, 0x33fd0000)
 tenured generation   total 6848K, used 0K [0x33fd0000, 0x34680000, 0x34680000)
   the space 6848K,   0% used [0x33fd0000, 0x33fd0000, 0x33fd0200, 0x34680000)
 compacting perm gen  total 12288K, used 143K [0x34680000, 0x35280000, 0x38680000)
   the space 12288K,   1% used [0x34680000, 0x346a3c58, 0x346a3e00, 0x35280000)
    ro space 10240K,  44% used [0x38680000, 0x38af73f0, 0x38af7400, 0x39080000)
    rw space 12288K,  52% used [0x39080000, 0x396cdd28, 0x396cde00, 0x39c80000)
[GC[DefNew: 2752K->320K(3072K), 0.0014296 secs] 2752K->377K(9920K), 0.0014604 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
Heap after GC invocations=1 (full 0):
 def new generation   total 3072K, used 320K [0x33c80000, 0x33fd0000, 0x33fd0000)
  eden space 2752K,   0% used [0x33c80000, 0x33c80000, 0x33f30000)
  from space 320K, 100% used [0x33f80000, 0x33fd0000, 0x33fd0000)
  to   space 320K,   0% used [0x33f30000, 0x33f30000, 0x33f80000)
 tenured generation   total 6848K, used 57K [0x33fd0000, 0x34680000, 0x34680000)
   the space 6848K,   0% used [0x33fd0000, 0x33fde458, 0x33fde600, 0x34680000)
 compacting perm gen  total 12288K, used 143K [0x34680000, 0x35280000, 0x38680000)
   the space 12288K,   1% used [0x34680000, 0x346a3c58, 0x346a3e00, 0x35280000)
    ro space 10240K,  44% used [0x38680000, 0x38af73f0, 0x38af7400, 0x39080000)
    rw space 12288K,  52% used [0x39080000, 0x396cdd28, 0x396cde00, 0x39c80000)
}

 

-XX:+TraceClassLoading
    監控類的加載

[Loaded java.lang.Object from shared objects file]
[Loaded java.io.Serializable from shared objects file]
[Loaded java.lang.Comparable from shared objects file]
[Loaded java.lang.CharSequence from shared objects file]
[Loaded java.lang.String from shared objects file]
[Loaded java.lang.reflect.GenericDeclaration from shared objects file]
[Loaded java.lang.reflect.Type from shared objects file]

 

-XX:+PrintClassHistogram
    按下Ctrl+Break後，打印類的信息：
    分別顯示：序號、實例數量、總大小、類型

num     #instances         #bytes  class name
----------------------------------------------
   1:        890617      470266000  [B
   2:        890643       21375432  java.util.HashMap$Node
   3:        890608       14249728  java.lang.Long
   4:            13        8389712  [Ljava.util.HashMap$Node;
   5:          2062         371680  [C
   6:           463          41904  java.lang.Class

 

堆的分配參數

-Xmx
    指定最大堆
–Xms
    指定最小堆
-Xmn
    設置新生代大小
-XX:NewRatio
    新生代（eden+2*s）和老年代（不包含永久區）的比值
    4 表示 新生代:老年代=1:4，即年輕代佔堆的1/5
-XX:SurvivorRatio
    設置兩個Survivor區和eden的比
    8表示 兩個Survivor:eden=2:8，即一個Survivor佔年輕代的1/10

-XX:+HeapDumpPath
    導出OOM的路徑

-XX:+HeapDumpOnOutOfMemoryError
    OOM時導出堆到文件

-Xmx20m -Xms5m -XX:HeapDumpOnOutofMemoryError -XX:HeapDumpPath=/apps/logs/oomError.dump
分配了20M最大空間 ，啓動 最小空間5M ， 發生了 內存溢出錯誤時 dump路徑爲/apps/logs/oomError.dump

-XX:OnOutOfMemoryError
    在OOM時，執行一個腳本
    "-XX:OnOutOfMemoryError=D:/tools/jdk1.7_40/bin/printstack.bat %p「
    當程序OOM時，在D:/a.txt中將會生成線程的dump
    能夠在OOM時，發送郵件，甚至是重啓程序

# pritstack.bat中內容：
D:/tools/jdk1.7_40/bin/jstack -F %1 > D:/a.txt

堆的分配參數 – 總結
    根據實際事情調整新生代和倖存代的大小
    官方推薦新生代佔堆的3/8
    倖存代佔新生代的1/10
    在OOM時，記得Dump出堆，確保能夠排查現場問題

 

永久區分配參數

-XX:PermSize  -XX:MaxPermSize
    設置永久區的初始空間和最大空間
    這兩個參數的大小決定了一個系統能夠容納java類的多少

實驗：使用CGLIB等庫的時候，可能會產生大量的類，這些類，有可能撐爆永久區致使OOM

for(int i=0;i<100000;i++){
    CglibBean bean = new CglibBean("geym.jvm.ch3.perm.bean"+i,new HashMap());
}

在使用java7時，若是web項目中jsp數量比較多，可能出現Perm OOM。使用cglib庫的一些框架，如hibernate，可能出現Perm OOM。

 

棧的分配參數

-Xss
    爲每一個線程分配獨立的棧空間
    一般只有幾百K
    決定了函數調用的深度
    局部變量、參數 分配在棧上

java.lang.StackOverflowError異常是因爲當前線程的棧滿了  ，也就是函數調用層級過多致使。好比死遞歸。