JVM啓動參數大全

java啓動參數共分爲三類；
其一是標準參數（-），全部的JVM實現都必須實現這些參數的功能，並且向後兼容；
其二是非標準參數（-X），默認jvm實現這些參數的功能，可是並不保證全部jvm實現都知足，且不保證向後兼容；
其三是非Stable參數（-XX），此類參數各個jvm實現會有所不一樣，未來可能會隨時取消，須要慎重使用；
本文主要描述標準參數部分，剩下的兩個部分將會陸續推出；

標準參數列表以下：
-client
 設置jvm使用client模式，特色是啓動速度比較快，但運行時性能和內存管理效率不高，一般用於客戶端應用程序或者PC應用開發和調試。

-server
 設置jvm使server模式，特色是啓動速度比較慢，但運行時性能和內存管理效率很高，適用於生產環境。在具備64位能力的jdk環境下將默認啓用該模式，而忽略-client參數。

-agentlib:libname[=options]
 用於裝載本地lib包；
 其中libname爲本地代理庫文件名，默認搜索路徑爲環境變量PATH中的路徑，options爲傳給本地庫啓動時的參數，多個參數之間用逗號分隔。 在Windows平臺上jvm搜索本地庫名爲libname.dll的文件，在linux上jvm搜索本地庫名爲libname.so的文件，搜索路徑環 境變量在不一樣系統上有所不一樣，好比Solaries上就默認搜索LD_LIBRARY_PATH。
 好比：-agentlib:hprof
 用來獲取jvm的運行狀況，包括CPU、內存、線程等的運行數據，並可輸出到指定文件中；windows中搜索路徑爲JRE_HOME/bin/hprof.dll。

-agentpath:pathname[=options]
 按全路徑裝載本地庫，再也不搜索PATH中的路徑；其餘功能和agentlib相同；更多的信息待續，在後續的JVMTI部分會詳述。

-classpath classpath
-cp classpath
 告知jvm搜索目錄名、jar文檔名、zip文檔名，之間用分號;分隔；使用-classpath後jvm將再也不使用CLASSPATH中的類搜索路徑，若是-classpath和CLASSPATH都沒有設置，則jvm使用當前路徑(.)做爲類搜索路徑。
 jvm搜索類的方式和順序爲：Bootstrap，Extension，User。
 Bootstrap中的路徑是jvm自帶的jar或zip文件，jvm首先搜索這些包文件，用System.getProperty("sun.boot.class.path")可獲得搜索路徑。
 Extension是位於JRE_HOME/lib/ext目錄下的jar文件，jvm在搜索完Bootstrap後就搜索該目錄下的jar文件，用System.getProperty("java.ext.dirs")可獲得搜索路徑。
 User搜索順序爲當前路徑.、CLASSPATH、-classpath，jvm最後搜索這些目錄，用System.getProperty("java.class.path")可獲得搜索路徑。

-Dproperty=value
 設置系統屬性名/值對，運行在此jvm之上的應用程序可用System.getProperty("property")獲得value的值。
 若是value中有空格，則須要用雙引號將該值括起來，如-Dname="space string"。
 該參數一般用於設置系統級全局變量值，如配置文件路徑，以便該屬性在程序中任何地方均可訪問。

-enableassertions[:<package name>"..." | :<class name> ]
-ea[:<package name>"..." | :<class name> ]
 上述參數就用來設置jvm是否啓動斷言機制（從JDK 1.4開始支持），缺省時jvm關閉斷言機制。
 用-ea 可打開斷言機制，不加<packagename>和classname時運行全部包和類中的斷言，若是但願只運行某些包或類中的斷言，可將包 名或類名加到-ea以後。例如要啓動包com.wombat.fruitbat中的斷言，可用命令java -ea:com.wombat.fruitbat...<Main Class>。

-disableassertions[:<package name>"..." | :<class ; ]
-da[:<package name>"..." | :<class name> ]
 用來設置jvm關閉斷言處理，packagename和classname的使用方法和-ea相同，jvm默認就是關閉狀態。
 該參數通常用於相同package內某些class不須要斷言的場景，好比com.wombat.fruitbat須要斷言，可是com.wombat.fruitbat.Brickbat該類不須要，則能夠以下運行：
 java -ea:com.wombat.fruitbat...-da:com.wombat.fruitbat.Brickbat <Main Class>。
 
-enablesystemassertions
-esa
 激活系統類的斷言。
 
-disablesystemassertions
-dsa
 關閉系統類的斷言。

-jar
 指定以jar包的形式執行一個應用程序。
 要這樣執行一個應用程序，必須讓jar包的manifest文件中聲明初始加載的Main-class，固然那Main-class必須有public static void main(String[] args)方法。

-javaagent:jarpath[=options]
 指定jvm啓動時裝入java語言設備代理。
 Jarpath文件中的mainfest文件必須有Agent-Class屬性。代理類也必須實現公共的靜態public static void premain(String agentArgs, Instrumentation inst)方法（和main方法相似）。當jvm初始化時，將按代理類的說明順序調用premain方法；具體參見 java.lang.instrument軟件包的描述。

-verbose
-verbose:class
 輸出jvm載入類的相關信息，當jvm報告說找不到類或者類衝突時可此進行診斷。
-verbose:gc
 輸出每次GC的相關狀況。
-verbose:jni
 輸出native方法調用的相關狀況，通常用於診斷jni調用錯誤信息。
 
-version
 輸出java的版本信息，好比jdk版本、vendor、model。
-version:release
 指定class或者jar運行時須要的jdk版本信息；若指定版本未找到，則以能找到的系統默認jdk版本執行；通常狀況下，對於jar文件，能夠在manifest文件中指定須要的版本信息，而不是在命令行。
 release中能夠指定單個版本，也能夠指定一個列表，中間用空格隔開，且支持複雜組合，好比：
 -version:"1.5.0_04 1.5*&1.5.1_02+"
 指定class或者jar須要jdk版本爲1.5.0_04或者是1.5系列中比1.5.1_02更高的全部版本。

-showversion
 輸出java版本信息（與-version相同）以後，繼續輸出java的標準參數列表及其描述。
 
-?
-help
 輸出java標準參數列表及其描述。

-X
 輸出非標準的參數列表及其描述。

以上的這些參數咱們常常會在不少狀況下用到多個的組合，好比咱們在用JProfiler進行跟蹤監控時，須要在被監控java啓動參數中加上以下配置：
-agentlib:jprofilerti=port=8849  -Xbootclasspath/a:/usr/local/jprofiler5/bin/agent.jar
其中就用到兩個-agentlib和-X參數，bootclasspath參數的詳細信息將會在非標準參數中詳細說明。

http://blog.csdn.net/sfdev/archive/2008/01/24/2063464.aspx

非標準參數又稱爲擴展參數，其列表以下：
-Xint
 設置jvm以解釋模式運行，全部的字節碼將被直接執行，而不會編譯成本地碼。
 
-Xbatch
 關閉後臺代碼編譯，強制在前臺編譯，編譯完成以後才能進行代碼執行；
 默認狀況下，jvm在後臺進行編譯，若沒有編譯完成，則前臺運行代碼時以解釋模式運行。
 
-Xbootclasspath:bootclasspath
 讓jvm從指定路徑（能夠是分號分隔的目錄、jar、或者zip）中加載bootclass，用來替換jdk的rt.jar；若非必要，通常不會用到；
-Xbootclasspath/a:path
 將指定路徑的全部文件追加到默認bootstrap路徑中；
-Xbootclasspath/p:path
 讓jvm優先於bootstrap默認路徑加載指定路徑的全部文件；
 
-Xcheck:jni
 對JNI函數進行附加check；此時jvm將校驗傳遞給JNI函數參數的合法性，在本地代碼中遇到非法數據時，jmv將報一個致命錯誤而終止；使用該參數後將形成性能降低，請慎用。
 
-Xfuture
 讓jvm對類文件執行嚴格的格式檢查（默認jvm不進行嚴格格式檢查），以符合類文件格式規範，推薦開發人員使用該參數。
 
-Xnoclassgc
 關閉針對class的gc功能；由於其阻止內存回收，因此可能會致使OutOfMemoryError錯誤，慎用；
 
-Xincgc
 開啓增量gc（默認爲關閉）；這有助於減小長時間GC時應用程序出現的停頓；但因爲可能和應用程序併發執行，因此會下降CPU對應用的處理能力。
 
-Xloggc:file
 與-verbose:gc功能相似，只是將每次GC事件的相關狀況記錄到一個文件中，文件的位置最好在本地，以免網絡的潛在問題。
 若與verbose命令同時出如今命令行中，則以-Xloggc爲準。
 
-Xmsn
 指定jvm堆的初始大小，默認爲物理內存的1/64，最小爲1M；能夠指定單位，好比k、m，若不指定，則默認爲字節。
 
-Xmxn
 指定jvm堆的最大值，默認爲物理內存的1/4或者1G，最小爲2M；單位與-Xms一致。
 
-Xprof
 跟蹤正運行的程序，並將跟蹤數據在標準輸出輸出；適合於開發環境調試。
 
-Xrs
 減小jvm對操做系統信號（signals）的使用，該參數從1.3.1開始有效；
 從jdk1.3.0開始，jvm容許程序在關閉以前還能夠執行一些代碼（好比關閉數據庫的鏈接池），即便jvm被忽然終止；
 jvm關閉工具經過監控控制檯的相關事件而知足以上的功能；更確切的說，通知在關閉工具執行以前，先註冊控制檯的控制handler，而後對 CTRL_C_EVENT, CTRL_CLOSE_EVENT, CTRL_LOGOFF_EVENT, and CTRL_SHUTDOWN_EVENT這幾類事件直接返回true。
 但若是jvm以服務的形式在後臺運行（好比servlet引擎），他能接收CTRL_LOGOFF_EVENT事件，但此時並不須要初始化關閉程序；爲 了避免相似衝突的再次出現，從jdk1.3.1開始提供-Xrs參數；當此參數被設置以後，jvm將不接收控制檯的控制handler，也就是說他不監控 和處理CTRL_C_EVENT, CTRL_CLOSE_EVENT, CTRL_LOGOFF_EVENT, or CTRL_SHUTDOWN_EVENT事件。
 
-Xssn
 設置單個線程棧的大小，通常默認爲512k。 

上面這些參數中，好比-Xmsn、-Xmxn……都是咱們性能優化中很重要的參數；
-Xprof、-Xloggc:file等都是在沒有專業跟蹤工具狀況下排錯的好手；
在上一小節中提到的關於JProfiler的配置中就使用到了-Xbootclasspath/a:path；

http://blog.csdn.net/sfdev/archive/2008/01/24/2063928.aspx

前面咱們提到用-XX做爲前綴的參數列表在jvm中多是不健壯的，SUN也不推薦使用，後續可能會在沒有通知的狀況下就直接取消了；可是因爲這些參數中的確有不少是對咱們頗有用的，好比咱們常常會見到的-XX:PermSize、-XX:MaxPermSize等等；

下面咱們將就Java HotSpot VM中-XX:的可配置參數列表進行描述；
這些參數能夠被鬆散的聚合成三類：
行爲參數（Behavioral Options）：用於改變jvm的一些基礎行爲；
性能調優（Performance Tuning）：用於jvm的性能調優；
調試參數（Debugging Options）：通常用於打開跟蹤、打印、輸出等jvm參數，用於顯示jvm更加詳細的信息；

因爲sun官方文檔中對各參數的描述也都很是少（大多隻有一句話），並且大多涉及OS層面的東西，很難描述清楚，因此如下是挑選了一些咱們開發中可能會用得比較多的配置項，若須要查看全部參數列表，能夠點擊HotSpot VM Specific Options.查看原文；

首先來介紹行爲參數：

參數及其默認值	描述
-XX:-DisableExplicitGC	禁止調用System.gc()；但jvm的gc仍然有效
-XX:+MaxFDLimit	最大化文件描述符的數量限制
-XX:+ScavengeBeforeFullGC	新生代GC優先於Full GC執行
-XX:+UseGCOverheadLimit	在拋出OOM以前限制jvm耗費在GC上的時間比例
-XX:-UseConcMarkSweepGC	對老生代採用併發標記交換算法進行GC
-XX:-UseParallelGC	啓用並行GC
-XX:-UseParallelOldGC	對Full GC啓用並行，當-XX:-UseParallelGC啓用時該項自動啓用
-XX:-UseSerialGC	啓用串行GC
-XX:+UseThreadPriorities	啓用本地線程優先級

上面表格中黑體的三個參數表明着jvm中GC執行的三種方式，即串行、並行、併發；
串行（SerialGC）是jvm的默認GC方式，通常適用於小型應用和單處理器，算法比較簡單，GC效率也較高，但可能會給應用帶來停頓；
並行（ParallelGC）是指GC運行時，對應用程序運行沒有影響，GC和app二者的線程在併發執行，這樣能夠最大限度不影響app的運行；
併發（ConcMarkSweepGC）是指多個線程併發執行GC，通常適用於多處理器系統中，能夠提升GC的效率，但算法複雜，系統消耗較大；

性能調優參數列表：

 

參數及其默認值	描述
-XX:LargePageSizeInBytes=4m	設置用於Java堆的大頁面尺寸
-XX:MaxHeapFreeRatio=70	GC後java堆中空閒量佔的最大比例
-XX:MaxNewSize=size	新生成對象能佔用內存的最大值
-XX:MaxPermSize=64m	老生代對象能佔用內存的最大值
-XX:MinHeapFreeRatio=40	GC後java堆中空閒量佔的最小比例
-XX:NewRatio=2	新生代內存容量與老生代內存容量的比例
-XX:NewSize=2.125m	新生代對象生成時佔用內存的默認值
-XX:ReservedCodeCacheSize=32m	保留代碼佔用的內存容量
-XX:ThreadStackSize=512	設置線程棧大小，若爲0則使用系統默認值
-XX:+UseLargePages	使用大頁面內存

咱們在平常性能調優中基本上都會用到以上黑體的這幾個屬性； 

調試參數列表：

 

參數及其默認值	描述
-XX:-CITime	打印消耗在JIT編譯的時間
-XX:ErrorFile=./hs_err_pid<pid>.log	保存錯誤日誌或者數據到文件中
-XX:-ExtendedDTraceProbes	開啓solaris特有的dtrace探針
-XX:HeapDumpPath=./java_pid<pid>.hprof	指定導出堆信息時的路徑或文件名
-XX:-HeapDumpOnOutOfMemoryError	當首次遭遇OOM時導出此時堆中相關信息
-XX:OnError="<cmd args>;<cmd args>"	出現致命ERROR以後運行自定義命令
-XX:OnOutOfMemoryError="<cmd args>;<cmd args>"	當首次遭遇OOM時執行自定義命令
-XX:-PrintClassHistogram	遇到Ctrl-Break後打印類實例的柱狀信息，與jmap -histo功能相同
-XX:-PrintConcurrentLocks	遇到Ctrl-Break後打印併發鎖的相關信息，與jstack -l功能相同
-XX:-PrintCommandLineFlags	打印在命令行中出現過的標記
-XX:-PrintCompilation	當一個方法被編譯時打印相關信息
-XX:-PrintGC	每次GC時打印相關信息
-XX:-PrintGC Details	每次GC時打印詳細信息
-XX:-PrintGCTimeStamps	打印每次GC的時間戳
-XX:-TraceClassLoading	跟蹤類的加載信息
-XX:-TraceClassLoadingPreorder	跟蹤被引用到的全部類的加載信息
-XX:-TraceClassResolution	跟蹤常量池
-XX:-TraceClassUnloading	跟蹤類的卸載信息
-XX:-TraceLoaderConstraints	跟蹤類加載器約束的相關信息

當系統出現問題的時候，又不能使用外部跟蹤工具（好比JProfiler……）的狀況下，以上的這些參數就會發揮重大做用了，好比dump堆信息、打印併發鎖……

 

 

-----------------------第二種理解------------------

無論是YGC仍是Full GC,GC過程當中都會對致使程序運行中中斷,正確的選擇不一樣的GC策略, 調整JVM、GC的參數，能夠極大的減小因爲GC工做，而致使的程序運行中斷方面的問題，進而適當的提升Java程序的工做效率。可是調整GC是以個極爲 複雜的過程，因爲各個程序具有不一樣的特色，如：web和GUI程序就有很大區別（Web能夠適當的停頓，但GUI停頓是客戶沒法接受的），並且因爲跑在各 個機器上的配置不一樣（主要cup個數，內存不一樣），因此使用的GC種類也會不一樣(如何選擇見GC種類及如何選擇)。本文將注重介紹JVM、GC的一些重要參數的設置來提升系統的性能。

       JVM內存組成及GC相關內容請見以前的文章:JVM內存組成 GC策略&內存申請。

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%的空餘）。

經驗&&規則

1. 年輕代大小選擇
   • 響應時間優先的應用:儘量設大,直到接近系統的最低響應時間限制(根據實際狀況選擇).在此種狀況下,年輕代收集發生的頻率也是最小的.同時,減小到達年老代的對象.
   • 吞吐量優先的應用:儘量的設置大,可能到達Gbit的程度.由於對響應時間沒有要求,垃圾收集能夠並行進行,通常適合8CPU以上的應用.
   • 避免設置太小.當新生代設置太小時會致使:1.YGC次數更加頻繁 2.可能致使YGC對象直接進入舊生代,若是此時舊生代滿了,會觸發FGC.
2. 年老代大小選擇
   1. 響 應時間優先的應用:年老代使用併發收集器,因此其大小須要當心設置,通常要考慮併發會話率和會話持續時間等一些參數.若是堆設置小了,能夠會形成內存碎 片,高回收頻率以及應用暫停而使用傳統的標記清除方式;若是堆大了,則須要較長的收集時間.最優化的方案,通常須要參考如下數據得到:
      併發垃圾收集信息、持久代併發收集次數、傳統GC信息、花在年輕代和年老代回收上的時間比例。
   2. 吞吐量優先的應用:通常吞吐量優先的應用都有一個很大的年輕代和一個較小的年老代.緣由是,這樣能夠儘量回收掉大部分短時間對象,減小中期的對象,而年老代盡存放長期存活對象.
3. 較小堆引發的碎片問題
   因 爲年老代的併發收集器使用標記,清除算法,因此不會對堆進行壓縮.當收集器回收時,他會把相鄰的空間進行合併,這樣能夠分配給較大的對象.可是,當堆空間 較小時,運行一段時間之後,就會出現"碎片",若是併發收集器找不到足夠的空間,那麼併發收集器將會中止,而後使用傳統的標記,清除方式進行回收.若是出 現"碎片",可能須要進行以下配置:
   -XX:+UseCMSCompactAtFullCollection:使用併發收集器時,開啓對年老代的壓縮.
   -XX:CMSFullGCsBeforeCompaction=0:上面配置開啓的狀況下,這裏設置多少次Full GC後,對年老代進行壓縮
4. 用64位操做系統，Linux下64位的jdk比32位jdk要慢一些，可是吃得內存更多，吞吐量更大
5. XMX和XMS設置同樣大，MaxPermSize和MinPermSize設置同樣大，這樣能夠減輕伸縮堆大小帶來的壓力
6. 使用CMS的好處是用盡可能少的新生代，經驗值是128M－256M， 而後老生代利用CMS並行收集， 這樣能保證系統低延遲的吞吐效率。 實際上cms的收集停頓時間很是的短，2G的內存， 大約20－80ms的應用程序停頓時間
7. 系統停頓的時候多是GC的問題也多是程序的問題，多用jmap和jstack查看，或者killall -3 java，而後查看java控制檯日誌，能看出不少問題。(相關工具的使用方法將在後面的blog中介紹)
8. 仔細瞭解本身的應用，若是用了緩存，那麼年老代應該大一些，緩存的HashMap不該該無限制長，建議採用LRU算法的Map作緩存，LRUMap的最大長度也要根據實際狀況設定。
9. 採用併發回收時，年輕代小一點，年老代要大，由於年老大用的是併發回收，即便時間長點也不會影響其餘程序繼續運行，網站不會停頓
10. 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))  進而推斷出：

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值。

令：

網上一童鞋推斷出的公式是：:(Xmx-Xmn)*(100-CMSInitiatingOccupancyFraction)/100>=Xmn 這個公式我的認爲不是很嚴謹，在內存小的時候會影響xmn的計算。

 

關於實際環境的GC參數配置見:實例分析   監測工具見JVM監測

參考：

JAVA HOTSPOT VM（http://www.helloying.com/blog/archives/164）

JVM 幾個重要的參數 (校長)

java jvm 參數 -Xms -Xmx -Xmn -Xss 調優總結

Java HotSpot VM Options

http://bbs.weblogicfans.net/archiver/tid-2835.html

Frequently Asked Questions About the Java HotSpot VM

Java SE HotSpot at a Glance

Java性能調優筆記(內附測試例子 頗有用)

說說MaxTenuringThreshold這個參數

 

相關文章推薦:

GC調優方法總結

Java 6 JVM參數選項大全（中文版）