jvm運行時分析

官方手冊：
http://docs.oracle.com/javase/7/docs/     ---->
http://docs.oracle.com/javase/7/docs/technotes/tools/solaris/java.html   java命令的各類選項的說明

參考書籍：

《深刻理解Java虛擬機：JVM高級特性與最佳實踐（第2版）》

首先說下JVM的內存堆結構，看下圖：

 

 

主要由 方法區Permanent Generation + 新生代Eden + 新生代倖存區S0和S1 + 老年代Old Generation；
大部分新生成的對象都放在Eden中，當Eden內存不夠用時，觸發Young GC，這時，會將Eden中不能被釋放的對象以及S0中倖存的對象，都Copy到S1中，而且將經歷過幾回Young GC還倖存的新生代對象，放入到Old Generation中，而後釋放Eden和S0；

因此S0和S1是來回切換使用的，保存新生代中還不能被釋放的對象，因此S0和S1總有一個會是空的，固然在發生Youg GC時，對象正在COPY時會是兩者都有數據；
若是經歷幾回Young GC時新生代仍是滿的，還不可以接收Eden中過來的倖存對象，就會拋出java.lang.OutOfMemorryError：java heap space;

若是在進行Youg GC時，發現S0不夠用時，則直接將對象放入Old Generation中，這時若是Old Generation內存也不夠時，則觸發Full GC,Full GC後若是Old Generation仍是滿的，就拋出內存溢出異常：
java.lang.OutOfMemorryError：java heap space;

因此，假設有一個永不銷燬的對象，其經歷的過程以下：首先在建立時放入Eden，當某個時刻Eden滿了時，經過Young GC放入S0或者S1，其在S0或者S1經歷過幾回Youg GC後，放入到Old generation中，當Old Generation滿了的時候，發生Full GC.

這裏有點須要注意，代碼區(方法區)，並不屬於堆空間，他是一個單獨的空間，其中保存有虛擬機本身的靜態數據，以及加載的Class類級別靜態對象，如class自己，method,field等，固然若是這部分空間不足時，同樣會觸發Full GC.並且若是GC以後仍是滿的，就會拋出PermGen Space異常

上面說到了堆和方法區，接下來咱們看下完整的JVM內存結構:

 

以前說了堆結構和代碼區Permanent Space，順着這個內存結構圖，說下Code Generation,JVM本身內部使用的一塊區域，用來編譯和保存本地代碼(native code),基本不會致使內存異常。若是該操做沒有足夠的空間，JVM可能會致使崩潰

Socket Buffers：用來作網絡通訊的緩衝區，分爲發送去和接收區，須要在java代碼中控制它，因此外部沒法配置。這裏若是滿了的話，會致使IOException: Too many open files 。

Thread JVM Stack:java的線程棧，java分配一個對象時，對象的具體內容在堆中，而對象的引用則位於棧中，也就是這裏。並且方法的局部變量以及函數地址的調入和調出，都存放在這裏，因此，JAVA的一個對象，有兩部分，對象自己的值在堆中，而引用則在棧中。當棧空間不夠時，好比遞歸層次太深，就會致使java.lang.StackOverflowError異常
Direct Memory Space：他可讓開發人員映射內存到java Object Heap外

JNI Code ：JNI code自己使用的內存很是小。

JNI allocate memory：JNI 程序自己也須要分配內存。

Garbage Collection：其實GC也是須要內存的，gc線程的消耗以及存放GC所緩存的信息。

因此，java進程實際佔用並不等於堆內存的大小，很顯然還有棧呀代碼區呀什麼之類的內存的大小。

再看一個列子，一個進程，設置的啓動參數中，堆的最大內存指定爲30G，而經過TOP命令，查看的內存使用狀況爲：

 

顯然，這裏的虛擬內存大小變成了38G，遠遠超過指定的堆的大小30G，究其緣由，一是，進程佔用的內存除了堆，還有棧空間之類的，就是上面標紅的一部分，二是，虛擬內存表示java像操做系統申請了38G，可是實際使用只有27G。在操做系統級別，內存是按頁分配的，並且，若是你申請了空間，不訪問它，那麼虛擬內存使用大小是你申請的大小，而RES倒是0，當你訪問時，若是物理內存不足，就有可能致使要訪問的內存頁不在物理內存裏，會發生缺頁中斷，發生CPU的上下文切換，性能會降低，而這時RES纔會增大。並且從經驗來看Xms和Xmx是告訴JAVA，我實際要使用的堆的最大值是多少，也就是RES是多少，也就是說我實際有可能要放28G的對象進來，而咱們知道JVM的堆空間，S0和S1是切換的，因此，java實際須要向操做系統申請的空間確定大於28G，可是實際進程使用的卻只有27G，這就是爲何上圖顯示RES爲27G而VIRT是38G。

jstat的整體使用參數說明

Option	Displays…
class	class loader的行爲統計。Statistics on the behavior of the class loader.
compiler	HotSpt JIT編譯器行爲統計。Statistics of the behavior of the HotSpot Just-in-Time compiler.
gc	垃圾回收堆的行爲統計。Statistics of the behavior of the garbage collected heap.
gccapacity	各個垃圾回收代容量(young,old,perm)和他們相應的空間統計。Statistics of the capacities of the generations and their corresponding spaces.
gccause	垃圾收集統計概述（同-gcutil），附加最近兩次垃圾回收事件的緣由。Summary of garbage collection statistics (same as -gcutil), with the cause of the last and current (if applicable) garbage collection events.
gcnew	新生代行爲統計。Statistics of the behavior of the new generation.
gcnewcapacity	新生代與其相應的內存空間的統計。Statistics of the sizes of the new generations and its corresponding spaces.
gcold	年老代和永生代行爲統計。Statistics of the behavior of the old and permanent generations.
gcoldcapacity	年老代行爲統計。Statistics of the sizes of the old generation.
gcpermcapacity	永生代行爲統計。Statistics of the sizes of the permanent generation.
gcutil	垃圾回收統計概述。Summary of garbage collection statistics.
printcompilation	HotSpot編譯方法統計。HotSpot compilation method statistics.

-h  n每隔 n個樣本 (行)， n是正整數，
缺省爲0，表明只有第一行爲列頭。 -t  n第一行輸出爲時間戳，
它表示自從目標JVM啓動以來逝去的時間，以秒爲單位。

如何查看JVM的性能呢？如今給出實際的列子：

一、查看java命令啓動參數

jinfo 20611

Attaching to process ID 20611, please wait...

Debugger attached successfully.

Server compiler detected.

JVM version is 19.1-b02

Java System Properties:

java.runtime.name = Java(TM) SE Runtime Environment

sun.boot.library.path = /usr/lib/jvm/java-1.6.0-sun-1.6.0.24.x86_64/jre/lib/amd64

java.vm.version = 19.1-b02

java.vm.vendor = Sun Microsystems Inc.

java.vendor.url = http://java.sun.com/

path.separator = :

java.vm.name = Java HotSpot(TM) 64-Bit Server VM

file.encoding.pkg = sun.io

sun.java.launcher = SUN_STANDARD

user.country = US

sun.os.patch.level = unknown

java.vm.specification.name = Java Virtual Machine Specification

user.dir = /mezi/dps/local/investopedia-market-service

java.runtime.version = 1.6.0_24-b07

java.awt.graphicsenv = sun.awt.X11GraphicsEnvironment

java.endorsed.dirs = /usr/lib/jvm/java-1.6.0-sun-1.6.0.24.x86_64/jre/lib/endorsed

os.arch = amd64

java.io.tmpdir = /tmp

line.separator =

java.vm.specification.vendor = Sun Microsystems Inc.

os.name = Linux

sun.jnu.encoding = UTF-8

java.library.path = /usr/lib/jvm/java-1.6.0-sun-1.6.0.24.x86_64/jre/lib/amd64/server:/usr/lib/jvm/java-1.6.0-sun-1.6.0.24.x86_64/jre/lib/amd64:/usr/lib/jvm/java-1.6.0-sun-1.6.0.24.x86_64/jre/../lib/amd64:/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib

java.specification.name = Java Platform API Specification

java.class.version = 50.0

sun.management.compiler = HotSpot 64-Bit Server Compiler

os.version = 2.6.18-348.12.1.el5

user.home = /home/mmdps

user.timezone = UTC

java.awt.printerjob = sun.print.PSPrinterJob

file.encoding = UTF-8

java.specification.version = 1.6

java.class.path = :libs/aopalliance.jar:libs/axiom-api-1.2.13.jar:libs/axiom-impl-1.2.13.jar:libs/axis2-adb-1.6.2.jar:libs/axis2-kernel-1.6.2.jar:libs/axis2-transport-http-1.6.2.jar:libs/axis2-transport-local-1.6.2.jar:libs/axis2-xmlbeans-1.6.2.jar:libs/bonecp-0.7.1.RELEASE.jar:libs/commons-codec-1.3.jar:libs/commons-httpclient-3.1.jar:libs/commons-lang-2.5.jar:libs/ehcache-2.7.1.jar:libs/google-collections-1.0.jar:libs/gson-2.2.4.jar:libs/guice-3.0.jar:libs/httpcore-4.0.jar:libs/javax.inject.jar:libs/jetty-client-8.1.10.v20130312.jar:libs/jetty-continuation-8.1.10.v20130312.jar:libs/jetty-http-8.1.10.v20130312.jar:libs/jetty-io-8.1.10.v20130312.jar:libs/jetty-security-8.1.10.v20130312.jar:libs/jetty-server-8.1.10.v20130312.jar:libs/jetty-servlet-8.1.10.v20130312.jar:libs/jetty-util-8.1.10.v20130312.jar:libs/jetty-xml-8.1.10.v20130312.jar:libs/json-rpc-1.0.jar:libs/log4j-1.2.15.jar:libs/mail-1.4.jar:libs/mockito-all-1.9.0.jar:libs/mysql-connector-java-5.1.7-bin.jar:libs/neethi-3.0.2.jar:libs/quartz.jar:libs/servlet-api-3.0.jar:libs/slf4j-api-1.7.5.jar:libs/slf4j-log4j12-1.7.5.jar:libs/start.jar:libs/wsdl4j-1.6.2.jar:libs/xmlbeans-2.3.0.jar:libs/XmlSchema-1.4.7.jar:properties:resources

user.name = mmdps

java.vm.specification.version = 1.0

java.home = /usr/lib/jvm/java-1.6.0-sun-1.6.0.24.x86_64/jre

sun.arch.data.model = 64

user.language = en

java.specification.vendor = Sun Microsystems Inc.

java.vm.info = mixed mode

java.version = 1.6.0_24

java.ext.dirs = /usr/lib/jvm/java-1.6.0-sun-1.6.0.24.x86_64/jre/lib/ext:/usr/java/packages/lib/ext

sun.boot.class.path = /usr/lib/jvm/java-1.6.0-sun-1.6.0.24.x86_64/jre/lib/resources.jar:/usr/lib/jvm/java-1.6.0-sun-1.6.0.24.x86_64/jre/lib/rt.jar:/usr/lib/jvm/java-1.6.0-sun-1.6.0.24.x86_64/jre/lib/sunrsasign.jar:/usr/lib/jvm/java-1.6.0-sun-1.6.0.24.x86_64/jre/lib/jsse.jar:/usr/lib/jvm/java-1.6.0-sun-1.6.0.24.x86_64/jre/lib/jce.jar:/usr/lib/jvm/java-1.6.0-sun-1.6.0.24.x86_64/jre/lib/charsets.jar:/usr/lib/jvm/java-1.6.0-sun-1.6.0.24.x86_64/jre/lib/modules/jdk.boot.jar:/usr/lib/jvm/java-1.6.0-sun-1.6.0.24.x86_64/jre/classes

java.vendor = Sun Microsystems Inc.

file.separator = /

java.vendor.url.bug = http://java.sun.com/cgi-bin/bugreport.cgi

sun.io.unicode.encoding = UnicodeLittle

sun.cpu.endian = little

sun.cpu.isalist =

VM Flags:

-Xms2000m -Xmx8000m

二、 jstat -gc pid 查看垃圾回收統計

            jstat -gc 50206 500 10

 

列名	描述
S0C	當前survivor space 0容量。Current survivor space 0 capacity (KB).
S1C	survivor space 1容量。Current survivor space 1 capacity (KB).
S0U	Survivor space 0 利用狀況。Survivor space 0 utilization (KB).
S1U	Survivor space 1 利用狀況。Survivor space 1 utilization (KB).
EC	當前新生代eden空間容量。Current eden space capacity (KB).
EU	新生代eden空間利用狀況。Eden space utilization (KB).
OC	當前年老代空間容量。Current old space capacity (KB).
OU	年老代利用狀況。Old space utilization (KB).
PC	當前永生代空間容量。Current permanent space capacity (KB).
PU	永生代空間利用狀況。Permanent space utilization (KB).
YGC	新生代GC事件次數。 Number of young generation GC Events.
YGCT	新生代GC耗時。Young generation garbage collection time.
FGC	full GC次數。Number of full GC events.
FGCT	full gc耗時。Full garbage collection time.
GCT	總GC耗時。Total garbage collection time.

三、GC內存空間使用統計

jstat -gccapacity 20611 500 5 

 

列名	描述
NGCMN	最小新生代容量。Minimum new generation capacity (KB).
NGCMX	最大新生代容量。Maximum new generation capacity (KB).
NGC	當前新生代容量。Current new generation capacity (KB).
S0C	當前新生代survivor 0區容量。Current survivor space 0 capacity (KB).
S1C	當前新生代survivor 1區容量。Current survivor space 1 capacity (KB).
EC	當前新生代eden空間容量。Current eden space capacity (KB).
OGCMN	最小年老代容量。Minimum old generation capacity (KB).
OGCMX	最大年老代容量。Maximum old generation capacity (KB).
OGC	當前年老代容量。Current old generation capacity (KB).
OC	當前年老代空間容量。Current old space capacity (KB).
PGCMN	最小永生代容量。Minimum permanent generation capacity (KB).
PGCMX	最大永生代容量。Maximum Permanent generation capacity (KB).
PGC	當前新生成的永生代容量。Current Permanent generation capacity (KB).
PC	當前永生代空間容量。Current Permanent space capacity (KB).
YGC	新生代GC次數。Number of Young generation GC Events.
FGC	Full GC次數。Number of Full GC Events.

四、GC內存空間各區使用比例
jstat -gcutil 20611 500 5  

列名	描述
S0	survivor 0區利用率。 Survivor space 0 utilization as a percentage of the space’s current capacity.
S1	survivor 1區利用率。 Survivor space 1 utilization as a percentage of the space’s current capacity.
E	eden區利用率。 Eden space utilization as a percentage of the space’s current capacity.
O	年老代空間利用率。 Old space utilization as a percentage of the space’s current capacity.
P	永生代空間利用率。Permanent space utilization as a percentage of the space’s current capacity.
YGC	young gc次數。 Number of young generation GC events.
YGCT	young gc耗時。 Young generation garbage collection time.
FGC	full gc次數。 Number of full GC events.
FGCT	full gc耗時。 Full garbage collection time.
GCT	GC總耗時。 Total garbage collection time.

五、GC內存空間的GC緣由
與-gcutil相同，多兩列，一個是最後一次GC緣由，一個是本次GC緣由
 jstat -gccause 20611 500 5

 

列名	描述
LGCC	上次GC緣由。Cause of last Garbage Collection.
GCC	本次GC緣由。Cause of current Garbage Collection.

六、新生代使用狀況
 jstat -gcnew 20611 500 5

 

列名	描述
S0C	當前survivor 0區容量。Current survivor space 0 capacity (KB).
S1C	當前survivor 1區容量。Current survivor space 1 capacity (KB).
S0U	當前survivor 0區利用狀況。 Survivor space 0 utilization (KB).
S1U	當前survivor 1區利用狀況。 Survivor space 1 utilization (KB).
TT	閥值， 用於控制對象在新生代存活的次數。 Tenuring threshold.
MTT	閥值， 用於控制對象在新生代存活的最大次數。Maximum tenuring threshold.
DSS	指望存活大小。 Desired survivor size (KB).
EC	當前eden空間容量。Current eden space capacity (KB).
EU	eden空間利用狀況。 Eden space utilization (KB).
YGC	年輕代gc次數。Number of young generation GC events.
YGCT	年輕代GC耗時。 Young generation garbage collection time.

note: 若某個age上的survivor space對象的大小若是超過Desired survivor size，則從新計算tenuring threshold，以age和MaxTenuringThreshold的最小值爲準

七、新生代空間統計

jstat -gcnewcapacity 20611 500 5

 

列名	描述
NGCMN	最小新生代容量。Minimum new generation capacity (KB).
NGCMX	最大新生代容量。Maximum new generation capacity (KB).
NGC	當前新生代容量。Current new generation capacity (KB).
S0CMX	最大survivor 0區容量。Maximum survivor space 0 capacity (KB).
S0C	當前survivor 0區容量。Current survivor space 0 capacity (KB).
S1CMX	最大survivor 1區容量。Maximum survivor space 1 capacity (KB).
S1C	當前survivor 1區容量。Current survivor space 1 capacity (KB).
ECMX	最大eden區容量。Maximum eden space capacity (KB).
EC	當前eden區容量。Current eden space capacity (KB).
YGC	young gc次數。 Number of young generation GC events.
FGC	full gc次數。Number of Full GC Events.

八、年老代使用狀況

jstat -gcold 20611 500 5  

 

列名	描述
PC	當前永久代空間容量。Current permanent space capacity (KB).
PU	永久代空間利用狀況。Permanent space utilization (KB).
OC	當前年老代空間容量。Current old space capacity (KB).
OU	年老代空間利用狀況。 old space utilization (KB).
YGC	young gc次數。 Number of young generation GC events.
FGC	full gc次數。Number of full GC events.
FGCT	full gc耗時。 Full garbage collection time.
GCT	gc總耗時。 Total garbage collection time.

九、年老代空間容量

jstat -gcoldcapacity 20611 500 5 

 

列名	描述
OGCMN	最小年老代容量。Minimum old generation capacity (KB).
OGCMX	最大年老代容量。Maximum old generation capacity (KB).
OGC	當前年老代容量。Current old generation capacity (KB).
OC	當前年老代空間容量。Current old space capacity (KB).
YGC	young gc次數。 Number of young generation GC events.
FGC	full gc次數。 Number of full GC events.
FGCT	full gc耗時。Full garbage collection time.
GCT	總GC耗時。 Total garbage collection time.

十、永生代統計

 jstat -gcpermcapacity 20611 500 5

 

列名	描述
PGCMN	Minimum permanent generation capacity (KB).
PGCMX	Maximum permanent generation capacity (KB).
PGC	Current permanent generation capacity (KB).
PC	Current permanent space capacity (KB).
YGC	Number of young generation GC events.
FGC	Number of full GC events.
FGCT	Full garbage collection time.
GCT	Total garbage collection time.

十一、編譯統計

jstat -printcompilation 20611 500 5   

 

列名	描述
Compiled	執行的編譯任務次數
Size	Number of bytes of bytecode for the method.
Type	編譯類型。Compilation type.
Method	類名和方法名。類名使用」/」代替了原命名空間符號」.」

十二、類加載狀況

jstat -class 20611 500 5

 

列名	描述
Loaded	已加載的類個數。
Bytes	已加載類佔用字節數（KB爲單位）。
Unloaded	卸載的類個數。
Bytes	卸載的類佔用字節數（KB爲單位）。
Time	加載和卸載操做花費的時間。

1三、棧大小的調整

jinfo flag  ThreadStackSize  20611  :-XX:ThreadStackSize=1024

按照以上這些數據，咱們作下內存分佈的分析

先看持久代，參數設置爲：XX:PermSize 最小值，XX:MaxpermSize最大值
使用 jinfo -flag PermSize 20611  + jinfo -flag MaxPermSize 20611 看到值分別爲：

-XX:PermSize=21757952 -XX:MaxPermSize=85983232，由於上面的進程，咱們沒配置它，因此這兩個值就是默認值，一個是20.75M，一個是82M，

這個與  jstat -gcpermcapacity 20611 500 5命令中的   PGCMN =  21248.0 KB 和   PGCMX=  83968.0 KB是相吻合的，同時咱們看到當前容量爲 31M，
因此，這個總容量是沒太大問題的，可是這裏會發生在GC以後內存收縮狀況， 因此咱們通常都設置成 XX:PermSize=XX:MaxPermSize 

實驗1（持久代），咱們用參數配置後再來啓動它，  -XX:PermSize=50M  -XX:MaxPermSize=100M，使用 jstat -gcpermcapacity命令後發現PGCMN=51200
PGCMX=102400，PGC=51200，因此，和咱們指望的是同樣的，可是若是想看咱們實際佔用了多少呢？經過jstat -gc 19539  命令，能夠發現

PC=51200，PU=29174.4，說明咱們實際是用了29M 。

反過來，由於咱們知道咱們的進程須要佔用29M的空間，當咱們把 -XX:PermSize=10M -XX:MaxPermSize=10M配置成最多使用10M時，啓動進程就會發現報了以下錯誤：

Exception in thread "main" java.lang.OutOfMemoryError: PermGen space

看下新生代區，一共有這幾個參數能夠影響到其大小：  指定年輕代的大小(Eden+S0+S1)； -XX:NewSize設置年輕代初始化值大小； -XX:MaxNewSize設置年輕代最大值，

-XX:NewRatio年輕代與年老代的比值， Xms=Xmx而且設置了Xmn的狀況下，該參數不須要進行設置； -XX:SurvivorRatio設置 Survivor 與 Eden 之間的比值，若是設置爲8，則表示
一個Surivior（S0）爲1，Eden爲8，因此，S0佔年輕代的1/10，S1佔1/10，Eden佔8/10

先使用jinfo -falg看下這些值的默認配置：-XX:NewSize=1310720  -XX:MaxNewSize=18446744073709486080(無限制) -XX:NewRatio=2 -XX:SurvivorRatio=8
當我使用java -server - Xmn3000M  -XX:SurvivorRatio=8 -XX:NewSize=3000M -XX:MaxNewSize=3000M -XX:PermSize=500M -XX:MaxPermSize=500M  -Xms2000m  -Xmx8000m該參數時啓動會報錯， Error occurred during initialization of VM ，Too small initial heap for new size specified ，緣由在於-Xms指定初始化堆大小爲2000M，而最小新生代 -Xmn3000 都比該值大，這個是不容許的，因此，

調整後的參數爲：java -server -Xmn3000M -XX:SurvivorRatio=8 -XX:NewSize=3000M -XX:MaxNewSize=3000M -XX:PermSize=500M -XX:MaxPermSize=500M -Xms8000m -Xmx8000m

使用jstat -gcnewcapacity 26111命令發現，最小最大新生代的大小 確實 都是3000M，但奇怪的是S0\S1\Eden的最大值也都是3000M，Eden實際容量是2400M，

這說明這種狀況下 - XX:SurvivorRatio=8這個參數不起做用了。

而通常咱們配置 XX:SurvivorRatio=1從而使 新生代Eden=S0=S1,而且Xmn設置新生代的大小

調整後的參數爲：-Xmn3000M -XX:SurvivorRatio=1 -XX:PermSize=500M -XX:MaxPermSize=500M -Xms8000m -Xmx8000m

這時候再使用gcnewcapacity就會發現：NGCMN=NGCMX=NGC=3000M，lS0C=S1C=EC=1024000，跟咱們預期的徹底同樣！
可是運行一段時間之後，發現值稍微有了一些變化，S0C=1024000，S1C=836224，EC=1360512，就是EC變大了，而S1變小了，至於爲何，不得而已？？？

看下老年區
老年區沒得設置，由於其空間大小就是堆的總空間減去年輕代的空間

其餘的一些設置：

-XX:+UseConcMarkSweepGC 使用CMS模式進行垃圾回收，該機制的特色是併發收集、低停頓，但同時，也會產生一些碎片和浮動垃圾，由於CMS併發清理階段用戶線程還在運行着，伴隨程序的運行天然還會有新的垃這一部分垃圾出如今標記過程以後，CMS沒法在本次收集中處理掉它們，只好留待下一次GC時再將其清理掉，這部分就是浮動垃圾。

-XX:+UseCMSCompactAtFullCollection，在FULL GC的時候， 對年老代的壓縮。因爲啓動了CMS機制進行垃圾收集，其會產生碎片，因此圾不斷產生，因此該選擇須要配合上面這個選擇，CMS收集器一塊兒使用
-XX:CMSInitiatingOccupancyFraction=70 使用cms做爲垃圾回收，使用70％後開始CMS收集。爲了保證不出現promotion failed(見下面介紹)錯誤,該值的設置須要知足如下公式CMSInitiatingOccupancyFraction計算公式    
 CMSInitiatingOccupancyFraction值與Xmn的關係公式 
 上面介紹了promontion faild產生的緣由是EDEN空間不足的狀況下將EDEN與From survivor中的存活對象存入To survivor區時,To survivor區的空間不足，再次晉升到old gen區，而old gen區內存也不夠的狀況下產生了promontion faild從而致使full gc.那能夠推斷出：eden+from survivor < old gen區剩餘內存時，不會出現promontion faild的狀況，即：
 (Xmx-Xmn)*(1-CMSInitiatingOccupancyFraction/100)>=(Xmn-Xmn/(SurvivorRatior+2))  進而推斷出： 
 CMSInitiatingOccupancyFraction <=((Xmx-Xmn)-(Xmn-Xmn/(SurvivorRatior+2)))/(Xmx-Xmn)*100 
  


    
    
    
    
    

   
 
 
    
 
     
 
      
 -XX:+UseParNewGC 
 
      
 設置年輕代爲並行收集 
 
      
   
 
      
 可與CMS收集同時使用
 JDK5.0以上,JVM會根據系統配置自行設置,因此無需再設置此值 
 
     
 
     
 
      
 -XX:ParallelGCThreads 
 
      
 並行收集器的線程數 
 
      
   
 
      
 此值最好配置與處理器數目相等 一樣適用於CMS 
 
     
 
    
 

   

網上一個很NB的配置參考：


    
    
    
    
    

   
 
 
    
$JAVA_ARGS
.=
"
-Dresin.home=$SERVER_ROOT
-server
-Xmx3000M
-Xms3000M
-Xmn600M
-XX:PermSize=500M
-XX:MaxPermSize=500M
-Xss256K
-XX:+DisableExplicitGC
-XX:SurvivorRatio=1
-XX:+UseConcMarkSweepGC
-XX:+UseParNewGC
-XX:+CMSParallelRemarkEnabled
-XX:+UseCMSCompactAtFullCollection
-XX:CMSFullGCsBeforeCompaction=0
-XX:+CMSClassUnloadingEnabled
-XX:LargePageSizeInBytes=128M
-XX:+UseFastAccessorMethods
-XX:+UseCMSInitiatingOccupancyOnly
-XX:CMSInitiatingOccupancyFraction=70
-XX:SoftRefLRUPolicyMSPerMB=0
-XX:+PrintClassHistogram
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-XX:+PrintHeapAtGC
-Xloggc:log/gc.log
";
 
 
    64位jdk參考設置，年老代漲得很慢，CMS執行頻率變小，CMS沒有停滯，也不會有promotion failed問題，內存回收得很乾淨
  

   


    
    
    
    
    

   

    
    

   

頗有用的一個各參數說明：

 JVM參數的含義 實例見實例分析 



    
    
    
    
    

   
 
 
    
 
     
 
      
 參數名稱 
 
      
 含義 
 
      
 默認值 
 
      
   
 
     
 
     
 
      
 -Xms 
 
      
 初始堆大小 
 
      
 物理內存的1/64(<1GB) 
 
      
 默認(MinHeapFreeRatio參數能夠調整)空餘堆內存小於40%時，JVM就會增大堆直到-Xmx的最大限制. 
 
     
 
     
 
      
 -Xmx 
 
      
 最大堆大小 
 
      
 物理內存的1/4(<1GB) 
 
      
 默認(MaxHeapFreeRatio參數能夠調整)空餘堆內存大於70%時，JVM會減小堆直到 -Xms的最小限制 
 
     
 
     
 
      
 -Xmn 
 
      
 年輕代大小(1.4or lator) 
 
      
   
 
      
 注意：此處的大小是（eden+ 2 survivor space).與jmap -heap中顯示的New gen是不一樣的。 整個堆大小=年輕代大小 + 年老代大小 + 持久代大小. 增大年輕代後,將會減少年老代大小.此值對系統性能影響較大,Sun官方推薦配置爲整個堆的3/8 
 
     
 
     
 
      
 -XX:NewSize 
 
      
 設置年輕代大小(for 1.3/1.4) 
 
      
   
 
      
   
 
     
 
     
 
      
 -XX:MaxNewSize 
 
      
 年輕代最大值(for 1.3/1.4) 
 
      
   
 
      
   
 
     
 
     
 
      
 -XX:PermSize 
 
      
 設置持久代(perm gen)初始值 
 
      
 物理內存的1/64 
 
      
   
 
     
 
     
 
      
 -XX:MaxPermSize 
 
      
 設置持久代最大值 
 
      
 物理內存的1/4 
 
      
   
 
     
 
     
 
      
 -Xss 
 
      
 每一個線程的堆棧大小 
 
      
   
 
      
 JDK5.0之後每一個線程堆棧大小爲1M,之前每一個線程堆棧大小爲256K.更具應用的線程所需內存大小進行 調整.在相同物理內存下,減少這個值能生成更多的線程.可是操做系統對一個進程內的線程數仍是有限制的,不能無限生成,經驗值在3000~5000左右 通常小的應用， 若是棧不是很深， 應該是128k夠用的 大的應用建議使用256k。這個選項對性能影響比較大，須要嚴格的測試。（校長） 和threadstacksize選項解釋很相似,官方文檔彷佛沒有解釋,在論壇中有這樣一句話:"」 -Xss is translated in a VM flag named ThreadStackSize」 通常設置這個值就能夠了。 
 
     
 
     
 
      
 -XX:ThreadStackSize 
 
      
 Thread Stack Size 
 
      
   
 
      
 (0 means use default stack size) [Sparc: 512; Solaris x86: 320 (was 256 prior in 5.0 and earlier); Sparc 64 bit: 1024; Linux amd64: 1024 (was 0 in 5.0 and earlier); all others 0.] 
 
     
 
     
 
      
 -XX:NewRatio 
 
      
 年輕代(包括Eden和兩個Survivor區)與年老代的比值(除去持久代) 
 
      
   
 
      
 -XX:NewRatio=4表示年輕代與年老代所佔比值爲1:4,年輕代佔整個堆棧的1/5 Xms=Xmx而且設置了Xmn的狀況下，該參數不須要進行設置。 
 
     
 
     
 
      
 -XX:SurvivorRatio 
 
      
 Eden區與Survivor區的大小比值 
 
      
   
 
      
 設置爲8,則兩個Survivor區與一個Eden區的比值爲2:8,一個Survivor區佔整個年輕代的1/10 
 
     
 
     
 
      
 -XX:LargePageSizeInBytes 
 
      
 內存頁的大小不可設置過大， 會影響Perm的大小 
 
      
   
 
      
 =128m 
 
     
 
     
 
      
 -XX:+UseFastAccessorMethods 
 
      
 原始類型的快速優化 
 
      
   
 
      
   
 
     
 
     
 
      
 -XX:+DisableExplicitGC 
 
      
 關閉System.gc() 
 
      
   
 
      
 這個參數須要嚴格的測試 
 
     
 
     
 
      
 -XX:MaxTenuringThreshold 
 
      
 垃圾最大年齡 
 
      
   
 
      
 若是設置爲0的話,則年輕代對象不通過Survivor區,直接進入年老代. 對於年老代比較多的應用,能夠提升效率.若是將此值設置爲一個較大值,則年輕代對象會在Survivor區進行屢次複製,這樣能夠增長對象再年輕代的存活 時間,增長在年輕代即被回收的機率 該參數只有在串行GC時纔有效. 
 
     
 
     
 
      
 -XX:+AggressiveOpts 
 
      
 加快編譯 
 
      
   
 
      
   
 
     
 
     
 
      
 -XX:+UseBiasedLocking 
 
      
 鎖機制的性能改善 
 
      
   
 
      
   
 
     
 
     
 
      
 -Xnoclassgc 
 
      
 禁用垃圾回收 
 
      
   
 
      
   
 
     
 
     
 
      
 -XX:SoftRefLRUPolicyMSPerMB 
 
      
 每兆堆空閒空間中SoftReference的存活時間 
 
      
 1s 
 
      
 softly reachable objects will remain alive for some amount of time after the last time they were referenced. The default value is one second of lifetime per free megabyte in the heap 
 
     
 
     
 
      
 -XX:PretenureSizeThreshold 
 
      
 對象超過多大是直接在舊生代分配 
 
      
 0 
 
      
 單位字節 新生代採用Parallel Scavenge GC時無效 另外一種直接在舊生代分配的狀況是大的數組對象,且數組中無外部引用對象. 
 
     
 
     
 
      
 -XX:TLABWasteTargetPercent 
 
      
 TLAB佔eden區的百分比 
 
      
 1% 
 
      
   
 
     
 
     
 
      
 -XX:+CollectGen0First 
 
      
 FullGC時是否先YGC 
 
      
 false 
 
      
   
 
     
 
    
 

   

 並行收集器相關參數 



    
    
    
    
    

   
 
 
    
 
     
 
      
 -XX:+UseParallelGC 
 
      
 Full GC採用parallel MSC (此項待驗證) 
 
      
   
 
      
 
 選擇垃圾收集器爲並行收集器.此配置僅對年輕代有效.即上述配置下,年輕代使用併發收集,而年老代仍舊使用串行收集.(此項待驗證) 
 
 
     
 
     
 
      
 -XX:+UseParNewGC 
 
      
 設置年輕代爲並行收集 
 
      
   
 
      
 可與CMS收集同時使用 JDK5.0以上,JVM會根據系統配置自行設置,因此無需再設置此值 
 
     
 
     
 
      
 -XX:ParallelGCThreads 
 
      
 並行收集器的線程數 
 
      
   
 
      
 此值最好配置與處理器數目相等 一樣適用於CMS 
 
     
 
     
 
      
 -XX:+UseParallelOldGC 
 
      
 年老代垃圾收集方式爲並行收集(Parallel Compacting) 
 
      
   
 
      
 這個是JAVA 6出現的參數選項 
 
     
 
     
 
      
 -XX:MaxGCPauseMillis 
 
      
 每次年輕代垃圾回收的最長時間(最大暫停時間) 
 
      
   
 
      
 若是沒法知足此時間,JVM會自動調全年輕代大小,以知足此值. 
 
     
 
     
 
      
 -XX:+UseAdaptiveSizePolicy 
 
      
 自動選擇年輕代區大小和相應的Survivor區比例 
 
      
   
 
      
 設置此選項後,並行收集器會自動選擇年輕代區大小和相應的Survivor區比例,以達到目標系統規定的最低相應時間或者收集頻率等,此值建議使用並行收集器時,一直打開. 
 
     
 
     
 
      
 -XX:GCTimeRatio 
 
      
 設置垃圾回收時間佔程序運行時間的百分比 
 
      
   
 
      
 公式爲1/(1+n) 
 
     
 
     
 
      
 -XX:+ScavengeBeforeFullGC 
 
      
 Full GC前調用YGC 
 
      
 true 
 
      
 Do young generation GC prior to a full GC. (Introduced in 1.4.1.) 
 
     
 
    
 

   

 CMS相關參數 



    
    
    
    
    

   
 
 
    
 
     
 
      
 -XX:+UseConcMarkSweepGC 
 
      
 使用CMS內存收集 
 
      
   
 
      
 測試中配置這個之後,-XX:NewRatio=4的配置失效了,緣由不明.因此,此時年輕代大小最好用-Xmn設置.??? 
 
     
 
     
 
      
 -XX:+AggressiveHeap 
 
      
   
 
      
   
 
      
 試圖是使用大量的物理內存 長時間大內存使用的優化，能檢查計算資源（內存， 處理器數量） 至少須要256MB內存 大量的CPU／內存， （在1.4.1在4CPU的機器上已經顯示有提高） 
 
     
 
     
 
      
 -XX:CMSFullGCsBeforeCompaction 
 
      
 多少次後進行內存壓縮 
 
      
   
 
      
 因爲併發收集器不對內存空間進行壓縮,整理,因此運行一段時間之後會產生"碎片",使得運行效率下降.此值設置運行多少次GC之後對內存空間進行壓縮,整理. 
 
     
 
     
 
      
 -XX:+CMSParallelRemarkEnabled 
 
      
 下降標記停頓 
 
      
   
 
      
   
 
     
 
     
 
      
 -XX+UseCMSCompactAtFullCollection 
 
      
 在FULL GC的時候， 對年老代的壓縮 
 
      
   
 
      
 CMS是不會移動內存的， 所以， 這個很是容易產生碎片， 致使內存不夠用， 所以， 內存的壓縮這個時候就會被啓用。 增長這個參數是個好習慣。 可能會影響性能,可是能夠消除碎片 
 
     
 
     
 
      
 -XX:+UseCMSInitiatingOccupancyOnly 
 
      
 使用手動定義初始化定義開始CMS收集 
 
      
   
 
      
 禁止hostspot自行觸發CMS GC 
 
     
 
     
 
      
 -XX:CMSInitiatingOccupancyFraction=70 
 
      
 使用cms做爲垃圾回收 使用70％後開始CMS收集 
 
      
 92 
 
      
 爲了保證不出現promotion failed(見下面介紹)錯誤,該值的設置須要知足如下公式CMSInitiatingOccupancyFraction計算公式 
 
     
 
     
 
      
 -XX:CMSInitiatingPermOccupancyFraction 
 
      
 設置Perm Gen使用到達多少比率時觸發 
 
      
 92 
 
      
   
 
     
 
     
 
      
 -XX:+CMSIncrementalMode 
 
      
 設置爲增量模式 
 
      
   
 
      
 用於單CPU狀況 
 
     
 
     
 
      
 -XX:+CMSClassUnloadingEnabled 
 
      
   
 
      
   
 
      
   
 
     
 
    
 

   

 輔助信息 



    
    
    
    
    

   
 
 
    
 
     
 
      
 -XX:+PrintGC 
 
      
   
 
      
   
 
      
 
 輸出形式: 
 
 [GC 118250K->113543K(130112K), 0.0094143 secs] [Full GC 121376K->10414K(130112K), 0.0650971 secs] 
 
 
     
 
     
 
      
 -XX:+PrintGCDetails 
 
      
   
 
      
   
 
      
 
 輸出形式:[GC [DefNew: 8614K->781K(9088K), 0.0123035 secs] 118250K->113543K(130112K), 0.0124633 secs] [GC [DefNew: 8614K->8614K(9088K), 0.0000665 secs][Tenured: 112761K->10414K(121024K), 0.0433488 secs] 121376K->10414K(130112K), 0.0436268 secs] 
 
 
     
 
     
 
      
 -XX:+PrintGCTimeStamps 
 
      
   
 
      
   
 
      
   
 
     
 
     
 
      
 -XX:+PrintGC:PrintGCTimeStamps 
 
      
   
 
      
   
 
      
 可與-XX:+PrintGC -XX:+PrintGCDetails混合使用 輸出形式:11.851: [GC 98328K->93620K(130112K), 0.0082960 secs] 
 
     
 
     
 
      
 -XX:+PrintGCApplicationStoppedTime 
 
      
 打印垃圾回收期間程序暫停的時間.可與上面混合使用 
 
      
   
 
      
 輸出形式:Total time for which application threads were stopped: 0.0468229 seconds 
 
     
 
     
 
      
 -XX:+PrintGCApplicationConcurrentTime 
 
      
 打印每次垃圾回收前,程序未中斷的執行時間.可與上面混合使用 
 
      
   
 
      
 輸出形式:Application time: 0.5291524 seconds 
 
     
 
     
 
      
 -XX:+PrintHeapAtGC 
 
      
 打印GC先後的詳細堆棧信息 
 
      
   
 
      
   
 
     
 
     
 
      
 -Xloggc:filename 
 
      
 把相關日誌信息記錄到文件以便分析. 與上面幾個配合使用 
 
      
   
 
      
   
 
     
 
     
 
      
 
 -XX:+PrintClassHistogram 
 
 
      
 garbage collects before printing the histogram. 
 
      
   
 
      
   
 
     
 
     
 
      
 -XX:+PrintTLAB 
 
      
 查看TLAB空間的使用狀況 
 
      
   
 
      
   
 
     
 
     
 
      
 XX:+PrintTenuringDistribution 
 
      
 查看每次minor GC後新的存活週期的閾值 
 
      
   
 
      
 
 Desired survivor size 1048576 bytes, new threshold 7 (max 15) new threshold 7即標識新的存活週期的閾值爲7。 
 
 
     
 
    
 

   

 GC性能方面的考慮 

        對於GC的性能主要有2個方面的指標：吞吐量throughput（工做時間不算gc的時間佔總的時間比）和暫停pause（gc發生時app對外顯示的沒法響應）。 

 1. Total Heap 

        默認狀況下，vm會增長/減小heap大小以維持free space在整個vm中佔的比例，這個比例由MinHeapFreeRatio和MaxHeapFreeRatio指定。 

 通常而言，server端的app會有如下規則： 



    
    
    
    
    

   
 
 
    
 對vm分配儘量多的memory； 
 
 
    
 將Xms和Xmx設爲同樣的值。若是虛擬機啓動時設置使用的內存比較小，這個時候又須要初始化不少對象，虛擬機就必須重複地增長內存。 
 
 
    
 處理器核數增長，內存也跟着增大。 
 

   

 2. The Young Generation 

        另一個對於app流暢性運行影響的因素是young generation的大小。young generation越大，minor collection越少；可是在固定heap size狀況下，更大的young generation就意味着小的tenured generation，就意味着更多的major collection(major collection會引起minor collection)。 

        NewRatio反映的是young和tenured generation的大小比例。NewSize和MaxNewSize反映的是young generation大小的下限和上限，將這兩個值設爲同樣就固定了young generation的大小（同Xms和Xmx設爲同樣）。 

        若是但願，SurvivorRatio也能夠優化survivor的大小，不過這對於性能的影響不是很大。SurvivorRatio是eden和survior大小比例。 

 通常而言，server端的app會有如下規則： 



    
    
    
    
    

   
 
 
    
 首先決定能分配給vm的最大的heap size，而後設定最佳的young generation的大小； 
 
 
    
 若是heap size固定後，增長young generation的大小意味着減少tenured generation大小。讓tenured generation在任什麼時候候夠大，可以容納全部live的data（留10%-20%的空餘）。 
 

   

 經驗&&規則 



    
    
    
    
    

   
 
 
    
 年輕代大小選擇 
 
 
    
 響應時間優先的應用:儘量設大,直到接近系統的最低響應時間限制(根據實際狀況選擇).在此種狀況下,年輕代收集發生的頻率也是最小的.同時,減小到達年老代的對象. 
 
 
    
 吞吐量優先的應用:儘量的設置大,可能到達Gbit的程度.由於對響應時間沒有要求,垃圾收集能夠並行進行,通常適合8CPU以上的應用. 
 
 
    
 避免設置太小.當新生代設置太小時會致使:1.YGC次數更加頻繁 2.可能致使YGC對象直接進入舊生代,若是此時舊生代滿了,會觸發FGC. 
 
 
    
 年老代大小選擇 
 

   
響應時間優先的應用:年老代使用併發收集器,因此其大小須要當心設置,通常要考慮併發會話率和會話持續時間等一些參數.若是堆設置小了,能夠會形成內存碎 片,高回收頻率以及應用暫停而使用傳統的標記清除方式;若是堆大了,則須要較長的收集時間.最優化的方案,通常須要參考如下數據得到: 併發垃圾收集信息、持久代併發收集次數、傳統GC信息、花在年輕代和年老代回收上的時間比例。 


    
    
    
    
    

   
 
 
    
 
 
 
    
 吞吐量優先的應用:通常吞吐量優先的應用都有一個很大的年輕代和一個較小的年老代.緣由是,這樣能夠儘量回收掉大部分短時間對象,減小中期的對象,而年老代盡存放長期存活對象. 
 
 
    
 較小堆引發的碎片問題 由於年老代的併發收集器使用標記,清除算法,因此不會對堆進行壓縮.當收集器回收時,他會把相鄰的空間進行合併,這樣能夠分配給較大的對象.可是,當堆空間較小時,運行一段時間之後,就會出現"碎片",若是併發收集器找不到足夠的空間,那麼併發收集器將會中止,而後使用傳統的標記,清除方式進行回收.若是出現"碎片",可能須要進行以下配置: -XX:+UseCMSCompactAtFullCollection:使用併發收集器時,開啓對年老代的壓縮. -XX:CMSFullGCsBeforeCompaction=0:上面配置開啓的狀況下,這裏設置多少次Full GC後,對年老代進行壓縮 
 
 
    
 用64位操做系統，Linux下64位的jdk比32位jdk要慢一些，可是吃得內存更多，吞吐量更大 
 
 
    
 XMX和XMS設置同樣大，MaxPermSize和MinPermSize設置同樣大，這樣能夠減輕伸縮堆大小帶來的壓力 
 
 
    
 使用CMS的好處是用盡可能少的新生代，經驗值是128M－256M， 而後老生代利用CMS並行收集， 這樣能保證系統低延遲的吞吐效率。 實際上cms的收集停頓時間很是的短，2G的內存， 大約20－80ms的應用程序停頓時間 
 
 
    
 系統停頓的時候多是GC的問題也多是程序的問題，多用jmap和jstack查看，或者killall -3 java，而後查看java控制檯日誌，能看出不少問題。(相關工具的使用方法將在後面的blog中介紹) 
 
 
    
 仔細瞭解本身的應用，若是用了緩存，那麼年老代應該大一些，緩存的HashMap不該該無限制長，建議採用LRU算法的Map作緩存，LRUMap的最大長度也要根據實際狀況設定。 
 
 
    
 採用併發回收時，年輕代小一點，年老代要大，由於年老大用的是併發回收，即便時間長點也不會影響其餘程序繼續運行，網站不會停頓 
 
 
    
 JVM參數的設置(特別是 –Xmx –Xms –Xmn -XX:SurvivorRatio  -XX:MaxTenuringThreshold等參數的設置沒有一個固定的公式，須要根據PV old區實際數據 YGC次數等多方面來衡量。爲了不promotion faild可能會致使xmn設置偏小，也意味着YGC的次數會增多，處理併發訪問的能力降低等問題。每一個參數的調整都須要通過詳細的性能測試，才能找到特定應用的最佳配置。 
 

   

 promotion failed: 

 垃圾回收時promotion failed是個很頭痛的問題，通常多是兩種緣由產生，第一個緣由是救助空間不夠，救助空間裏的對象還不該該被移動到年老代，但年輕代又有不少對象須要放入救助空間；第二個緣由是年老代沒有足夠的空間接納來自年輕代的對象；這兩種狀況都會轉向Full GC，網站停頓時間較長。 

 解決方方案一： 

 第一個緣由個人最終解決辦法是去掉救助空間，設置-XX:SurvivorRatio=65536 -XX:MaxTenuringThreshold=0便可，第二個緣由個人解決辦法是設置CMSInitiatingOccupancyFraction爲某個值（假設70），這樣年老代空間到70%時就開始執行CMS，年老代有足夠的空間接納來自年輕代的對象。 

 解決方案一的改進方案： 

 又有改進了，上面方法不太好，由於沒有用到救助空間，因此年老代容易滿，CMS執行會比較頻繁。我改善了一下，仍是用救助空間，可是把救助空間加大，這樣也不會有promotion failed。具體操做上，32位Linux和64位Linux好像不同，64位系統彷佛只要配置MaxTenuringThreshold參數，CMS仍是有暫停。爲了解決暫停問題和promotion failed問題，最後我設置-XX:SurvivorRatio=1 ，並把MaxTenuringThreshold去掉，這樣即沒有暫停又不會有promotoin failed，並且更重要的是，年老代和永久代上升很是慢（由於好多對象到不了年老代就被回收了），因此CMS執行頻率很是低，好幾個小時才執行一次，這樣，服務器都不用重啓了。 

 -Xmx4000M -Xms4000M -Xmn600M -XX:PermSize=500M -XX:MaxPermSize=500M -Xss256K -XX:+DisableExplicitGC -XX:SurvivorRatio=1 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0 -XX:+CMSClassUnloadingEnabled -XX:LargePageSizeInBytes=128M -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=80 -XX:SoftRefLRUPolicyMSPerMB=0 -XX:+PrintClassHistogram -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -Xloggc:log/gc.log 

   

 CMSInitiatingOccupancyFraction值與Xmn的關係公式 

 上面介紹了promontion faild產生的緣由是EDEN空間不足的狀況下將EDEN與From survivor中的存活對象存入To survivor區時,To survivor區的空間不足，再次晉升到old gen區，而old gen區內存也不夠的狀況下產生了promontion faild從而致使full gc.那能夠推斷出：eden+from survivor < old gen區剩餘內存時，不會出現promontion faild的狀況，即： (Xmx-Xmn)*(1-CMSInitiatingOccupancyFraction/100)>=(Xmn-Xmn/(SurvivorRatior+2))  進而推斷出： 

 
 

 參考圖：  

 

四，JVM 內存參數分析實例

環境:OS：Linux version 2.6.9-79.custome.ELxenU cpu: 4 * Intel(R) Xeon(R) CPU E5410 @ 2.33GHz (雙核) memory:4G

1

de style="line-height: 16px; background-color: inherit; font-family: Consolas, 'Bitstream Vera Sans Mono', 'Courier New', Courier, monospace !important; font-size: 1em !important;" >-server -Xmx2g -Xms2g -Xmn256m -XX:PermSize=192m -Xss256k -XX:+DisableExplicitGC -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:LargePageSizeInBytes=128m -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=70de>

-Xmx2g 最大堆內存2G
-Xms2g 最小內存2G
-Xmn256m 新生代內存256m 整個堆大小=年輕代大小 + 年老代大小 + 持久代大小。持久代通常是固定大小的（例如64m、96m），因此增大年輕代後，將會減少年老代大小。此值對系統性能影響較大，Sun官方推薦配置爲整個堆的3/8。
-XX:PermSize=192m 持久代 192m
-Xss256k 指定線程桟大小256K
-XX:LargePageSizeInBytes=128m 指定Java heap的分頁頁面大小爲128M
-server 可使得新生代採用並行GC，年老代採用串行
-XX:+DisableExplicitGC
-XX:+UseConcMarkSweepGC 指定在Old Generation使用concurrent gc ，啓用CMS低停頓垃圾收集器。GC線程和應用線程並行
-XX:+CMSParallelRemarkEnabled
-XX:+UseCMSCompactAtFullCollection
-XX:+UseFastAccessorMethods
-XX:+UseCMSInitiatingOccupancyOnly
-XX:CMSInitiatingOccupancyFraction=70

五. 內存回收

GC：垃圾回收。回收的是堆和方法區的內存。

基本原理：找到不被使用的對象，而後回收內存。使用收集器的方式實現GC。

A）怎麼找到？從根集合出發，找出無引用的對象。

根集合對象： 當前運行線程棧上引用的對象，常量及靜態變量，傳到本地方法且沒有被本地方法釋放的對象引用。

B）收集器

按回收算法爲兩種： 引用計數收集器，跟蹤收集器。

引用計數採用算法：原理是此對象有一個引用，即增長一個計數，刪除一個引用則減小一個計數。垃圾回收時，只用收集計數爲0的對象。

跟蹤收集器採用算法：複製，標記-清除，標記-壓縮。

按分區對待的方式分： 增量收集器（jdk5開始廢棄），分代收集器。

增量收集器：就是經過必定的回收算法，把一個長時間的中斷，劃分爲不少個小的中斷，經過這種方式減小GC對用戶程序的影響。

分代收集：對象存活的時間有長短，基於此將堆分爲多個代，不一樣的代採用不一樣的GC方式。

按吞吐量和響應時間（暫停時間）分爲： 串行收集器，並行收集器，併發收集器。

C）評估垃圾回收策略的兩個重要度量

吞吐量：JVM花費在垃圾回收上的時間越長，則吞吐量越低
暫停時間：JVM垃圾回收過程中有一個暫停期，在暫停期間，應用程序不能運行
串行收集器：單線程（單CPU）進行垃圾回收的工做。
–適用狀況：數據量比較小；單處理器下而且對響應時間無要求的應用。
–缺點：只能用於小型應用
並行收集器：多個線程同時進行垃圾回收的工做。
–適用狀況：」對吞吐量有高要求」，多CPU、對應用響應時間無要求的中、大型應用。舉例：科學計算。
–缺點：應用響應時間可能較長
併發收集器：傳說中的CMS。垃圾回收器的一些工做與應用程序同時進行。
–適用狀況：」對響應時間有高要求」，多CPU、對應用響應時間有較高要求的中、大型應用。舉例：Web服務器/應用服務器。

D）GC類型

GC有兩種類型：Minor GC（Scavenge GC）和Full GC。

Minor GC：對新生代內存進行GC。

Full GC：對新生代，舊生代，持久代都進行GC。

Full GC可能的緣由：

a）老年代或持久代空間滿。

b）老年代採用CMS GC，GC日誌出現prmotion failed和concurrent mode failure時可能觸發。

prmotion failed：Minor GC是，S0（S1）放不下，放入舊生代時，仍然放不下形成的。

concurrent mode failure：CMS GC的過程當中，有對象放入舊生代，此時舊生代空間不夠。

c）統計獲得Minor GC後存活對象放入舊生代的平均大小大於舊生代剩餘空間。

d）System.gc()，只是」建議」JVM回收內存，不是強制。

六. 爲什麼內存溢出：

既然都有GC，爲何還有內存被用盡（固然除了忽然申請大空間）。這裏更想說的是新生代和老年代被耗盡。

這是由於jvm有四種引用類型，不一樣的引用，GC的條件是不同的。

A）四種引用

軟引用：SoftReference,弱引用：WeakReference ,虛引用：PhantomReference。

軟引用：內存不足，或軟引用不常用時會被回收。適用於作緩存。

弱引用：使用弱引用建立的對象自己沒有強引用，GC時必定會被回收。

虛引用：虛引用並不會決定對象的生命週期。若是一個對象僅持有虛引用，那麼它就和沒有任何引用同樣，在任什麼時候候均可能被垃圾回收。

除此以外都是強引用，咱們通常建立一個對象時的引用就是強引用。對象被強引用，是不會不垃圾回收的。

B）內存溢出（泄露）

兩種理解，

一是須要使用的對象在不斷增長，直到須要分配的jvm內存超出了沒法知足，因而產生溢出。

二是無用的對象在不斷增長，但又沒法回收，因而產生泄露。

泄露的對象有兩個特色，首先，這些對象是可達的，即在有向圖中，存在通路能夠與其相連；其次，這些對象是無用的，即程序之後不會再使用這些對象。這些對象不會被GC所回收，然而它卻佔用內存

 CMSInitiatingOccupancyFraction <=((Xmx-Xmn)-(Xmn-Xmn/(SurvivorRatior+2)))/(Xmx-Xmn)*100 

 例如： 

 當xmx=128 xmn=36 SurvivorRatior=1時 CMSInitiatingOccupancyFraction<=((128.0-36)-(36-36/(1+2)))/(128-36)*100 =73.913 

 當xmx=128 xmn=24 SurvivorRatior=1時 CMSInitiatingOccupancyFraction<=((128.0-24)-(24-24/(1+2)))/(128-24)*100=84.615… 

 當xmx=3000 xmn=600 SurvivorRatior=1時  CMSInitiatingOccupancyFraction<=((3000.0-600)-(600-600/(1+2)))/(3000-600)*100=83.33 

 CMSInitiatingOccupancyFraction低於70% 須要調整xmn或SurvivorRatior值。 

(8000-3000)-(3000-3000/3)/(8000-3000)*100=60

(4000-1500)-(1500-1500/3)/(4000-1500)*100= 60

我本身的一個配置：

$JAVA_ARGS
.=
"
-Dresin.home=$SERVER_ROOT
-server
-Xmx8000M
-Xms8000M
-Xmn3000M
-XX:PermSize=500M
-XX:MaxPermSize=500M
-Xss1024K
-XX:+DisableExplicitGC
-XX:SurvivorRatio=1
-XX:+UseConcMarkSweepGC
-XX:+UseParNewGC
-XX:+CMSParallelRemarkEnabled
-XX:+UseCMSCompactAtFullCollection
-XX:CMSFullGCsBeforeCompaction=0
-XX:+CMSClassUnloadingEnabled
-XX:LargePageSizeInBytes=128M
-XX:+UseFastAccessorMethods
-XX:+UseCMSInitiatingOccupancyOnly
-XX:CMSInitiatingOccupancyFraction=55
-XX:SoftRefLRUPolicyMSPerMB=0
-XX:+PrintClassHistogram
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-XX:+PrintHeapAtGC
-Xloggc:log/gc.log
";

使用這個配置之後，在GC日誌中沒有發現任何Full GC，因此網站不會有較大的停頓，可是使用jstat -gc 發現full gc 次數仍是有的，緣由是CMS GC，也就是對老年代的GC，也有顯示在這裏的FULL GC統計次數以內，不過CMS GC是併發低停頓的，因此對網站影響很是小，特別強調，CMS不是徹底沒有停頓，是停頓的時間不多，緣由是：

 

這張圖表示的是CMS在執行Full GC的過程，這個過程包括了6個步驟：
# STW initial mark
# Concurrent marking
# Concurrent precleaning
# STW remark
# Concurrent sweeping
# Concurrent reset

在這六個步驟中，有兩個步驟須要STW，分別是：initial mark和remark（如圖所示）。而其它的四個步驟是能夠和application「併發」執行，因此也就2個步驟會暫停應用服務，因此就減小了服務暫停的時間