轉自：http://blog.163.com/itjin45@126/blog/static/10510751320144201519454/
官方手冊：
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 loader的行為統計。Statistics on the behavior of the class loader. |
|
| HotSpt JIT編譯器行為統計。Statistics of the behavior of the HotSpot Just-in-Time compiler. |
|
| 垃圾回收堆的行為統計。Statistics of the behavior of the garbage collected heap. |
|
| 各個垃圾回收代容量(young,old,perm)和他們相應的空間統計。Statistics of the capacities of the generations and their corresponding spaces. |
|
| 垃圾收集統計概述（同-gcutil），附加最近兩次垃圾回收事件的原因。Summary of garbage collection statistics (same as -gcutil), with the cause of the last and |
|
| 新生代行為統計。Statistics of the behavior of the new generation. |
|
| 新生代與其相應的內存空間的統計。Statistics of the sizes of the new generations and its corresponding spaces. |
|
| 年老代和永生代行為統計。Statistics of the behavior of the old and permanent generations. |
|
| 年老代行為統計。Statistics of the sizes of the old generation. |
|
| 永生代行為統計。Statistics of the sizes of the permanent generation. |
|
| 垃圾回收統計概述。Summary of garbage collection statistics. |
|
| HotSpot編譯方法統計。HotSpot compilation method statistics. |
-h n
每隔n個樣本 (行)，n是正整數，
缺省為0，代表只有第一行為列頭。
-t n
第一行輸出為時間戳，
它表示自從目標JVM啟動以來逝去的時間，以秒為單位。
如何查看JVM的性能呢？現在給出實際的列子：
1、查看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
2、 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. |
3、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. |
4、GC內存空間各區使用比例
jstat -gcutil 20611 500 5
| 列名 |
描述 |
| S0 |
survivor 0區利用率。 |
| S1 |
survivor 1區利用率。 |
| E |
eden區利用率。 |
| O |
年老代空間利用率。 |
| P |
永生代空間利用率。Permanent space utilization as a percentage of |
| YGC |
young gc次數。 |
| YGCT |
young gc耗時。 |
| FGC |
full gc次數。 |
| FGCT |
full gc耗時。 |
| GCT |
GC總耗時。 |
5、GC內存空間的GC原因
與-gcutil相同，多兩列，一個是最后一次GC原因，一個是本次GC原因
jstat -gccause 20611 500 5
| 列名 |
描述 |
| LGCC |
上次GC原因。Cause of last Garbage Collection. |
| GCC |
本次GC原因。Cause of current Garbage Collection. |
6、新生代使用情況
jstat -gcnew 20611 500 5
| 列名 |
描述 |
| S0C |
當前survivor 0區容量。Current |
| S1C |
當前survivor 1區容量。Current |
| S0U |
當前survivor 0區利用情況。 |
| S1U |
當前survivor 1區利用情況。 |
| TT |
閥值， 用於控制對象在新生代存活的次數。 |
| MTT |
閥值， 用於控制對象在新生代存活的最大次數。Maximum tenuring threshold. |
| DSS |
期望存活大小。 |
| EC |
當前eden空間容量。Current eden space capacity (KB). |
| EU |
eden空間利用情況。 |
| YGC |
年輕代gc次數。Number of young generation GC events. |
| YGCT |
年輕代GC耗時。 |
note: 若某個age上的survivor space對象的大小如果超過Desired survivor size，則重新計算tenuring threshold，以age和MaxTenuringThreshold的最小值為准
7、新生代空間統計
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 |
| 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次數。 |
| FGC |
full gc次數。Number of Full GC Events. |
8、年老代使用情況
jstat -gcold 20611 500 5
| 列名 |
描述 |
| PC |
當前永久代空間容量。Current permanent space capacity (KB). |
| PU |
永久代空間利用情況。Permanent space utilization (KB). |
| OC |
當前年老代空間容量。Current old space capacity (KB). |
| OU |
年老代空間利用情況。 |
| YGC |
young gc次數。 |
| FGC |
full gc次數。Number of full GC events. |
| FGCT |
full gc耗時。 |
| GCT |
gc總耗時。 |
9、年老代空間容量
jstat -gcoldcapacity 20611 500 5
| 列名 |
描述 |
| OGCMN |
最小年老代容量。Minimum |
| OGCMX |
最大年老代容量。Maximum |
| OGC |
當前年老代容量。Current |
| OC |
當前年老代空間容量。Current |
| YGC |
young gc次數。 |
| FGC |
full gc次數。 |
| FGCT |
full gc耗時。Full garbage collection time. |
| GCT |
總GC耗時。 |
10、永生代統計
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. |
11、編譯統計
jstat -printcompilation 20611 500 5
| 列名 |
描述 |
| Compiled |
執行的編譯任務次數 |
| Size |
Number of bytes of bytecode for the method. |
| Type |
編譯類型。Compilation type. |
| Method |
類名和方法名。類名使用”/”代替了原命名空間符號”.” |
12、類加載情況
jstat -class 20611 500 5
| 列名 |
描述 |
| Loaded |
已加載的類個數。 |
| Bytes |
已加載類占用字節數（KB為單位）。 |
| Unloaded |
卸載的類個數。 |
| Bytes |
卸載的類占用字節數（KB為單位）。 |
| Time |
加載和卸載操作花費的時間。 |
13、棧大小的調整
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收集同時使用 |
| -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是不同的。 |
| -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左右 |
| -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 |
| -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區進行多次復制,這樣可以增加對象再年輕代的存活 時間,增加在年輕代即被回收的概率 |
| -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收集同時使用 |
| -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 |
|
|
試圖是使用大量的物理內存 |
| -XX:CMSFullGCsBeforeCompaction |
多少次后進行內存壓縮 |
|
由於並發收集器不對內存空間進行壓縮,整理,所以運行一段時間以后會產生"碎片",使得運行效率降低.此值設置運行多少次GC以后對內存空間進行壓縮,整理. |
| -XX:+CMSParallelRemarkEnabled |
降低標記停頓 |
|
|
| -XX+UseCMSCompactAtFullCollection |
在FULL GC的時候， 對年老代的壓縮 |
|
CMS是不會移動內存的， 因此， 這個非常容易產生碎片， 導致內存不夠用， 因此， 內存的壓縮這個時候就會被啟用。 增加這個參數是個好習慣。 |
| -XX:+UseCMSInitiatingOccupancyOnly |
使用手動定義初始化定義開始CMS收集 |
|
禁止hostspot自行觸發CMS GC |
| -XX:CMSInitiatingOccupancyFraction=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] |
| -XX:+PrintGCDetails |
|
|
輸出形式:[GC [DefNew: 8614K->781K(9088K), 0.0123035 secs] 118250K->113543K(130112K), 0.0124633 secs] |
| -XX:+PrintGCTimeStamps |
|
|
|
| -XX:+PrintGC:PrintGCTimeStamps |
|
|
可與-XX:+PrintGC -XX:+PrintGCDetails混合使用 |
| -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) |
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; 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個步驟會暫停應用服務，所以就減少了服務暫停的時間