JVM性能調優2：JVM性能調優參數整理

序號	參數名	說明	JDK	默認值	使用過
1	JVM執行模式
2	-client -server	設置該JVM運行與Client 或者Server Hotspot模式，這兩種模式從本質上來說是在JVM中運行不同的JIT（運行時編譯模塊）代碼，並且兩者在JVM內部的接口是一致的。客戶端模式優化的是系統啟動時間更快，而服務端模式的優化則更關注與系統的整體性能。一般來說Client選項用於GUI的應用，Server選項多用於后台服務器應用。 另外兩者在編譯策略、垃圾收集策略、堆使用上也有所不同			是
3	-d32 -d64	指明該Java VM是運行與32位環境還是64位環境，默認是運行在32位環境下的，如果是配置了64位模式則需要操作系統也必須是64位的，當然CPU更需要是64位的。另外如果我們選擇了-server參數，則就暗含了64位模式。		默認32模式
4	-hotspot	在Hotspot類型的JVM中缺省使用，缺省為Client Hotspot模式。		默認client模式
5	-Xmixed	JVM執行模式的設置參數，混合模式即支持Hotspot即時編譯的運行模式. 支持Hotspot的JVM缺省都是運行於混合模式的。		默認混合模式
	-Xcomp	JVM優先以編譯模式運行，不能編譯的，以解釋模式運行。
6	-Xint	設置JVM的執行模式為解釋執行模式，純解釋執行的JVM對多數應用來說基本上時沒有意義的，僅僅可能會在一些嵌入式系統中應用
7	內存分配相關參數
8	-Xms	設置JVM啟動時初始內存堆的大小	1.6	物理內存的1/64.	是
9	-Xmx	設置JVM啟動后動態申請堆內存的最大堆空間	1.6	MIN（物理內存的1/4,1G)	是
10	-Xmn	為新生代分配的內存大小。		和cpu核數相關，建議1core對應512M，不超過1G。	是
11	-Xss	設置JVM線程棧的空間最大值。	1.6	當設置值小於64K時，用默認值。	是
12	-XX:ThreadStackSize=512	每個線程棧大小（K），等於0時表示使用缺省值		Sparc: 512K，Solaris Intel: 256K，Sparc 64bit: 1024 其他的都為 0
13	-XX:NewRatio=2	新生代內存容量與老生代內存容量的比例。 Ratio of new/old generation sizes. The default value is 2.	1.6	Client模式默認8，Server模式：2	是
14	-XX:MaxNewSize=size	Maximum size of new generation (in bytes). Since 1.4, MaxNewSize is computed as a function of NewRatio. [1.3.1 Sparc: 32m; 1.3.1 x86: 2.5m.]
15	-XX:NewSize=2m	新生代預估默認值。Default size of new generation (in bytes) [5.0 and newer: 64 bit VMs are scaled 30% larger; x86: 1m; x86, 5.0 and older: 640k]	1.6	2228K
16	-XX:SurvivorRatio=64	存活區和eden區所占的比率：2:64。 Ratio of eden/survivor space size.	1.6	32	是
17	-XX:PermSize=256m	為持久代分配的初始化內存空間。
18	-XX:MaxPermSize=256m	為持久代分配的最大內存空間。		client/server:64M	是
19	-XX:MaxTenuringThreshold=30	每次垃圾收集在新生代之間Copy的次數，超過該次數則移至Old區。 Maximum value for tenuring threshold. The default value is 15.		The default value is 15 for the parallel collector and is 4 for CMS.	是
20	-XX:TargetSurvivorRatio=50	該值是一個百分比，控制允許使用的生存區空間的比例。該參數設置較大的話可提高對survivor空間的使用率。		默認值是50。即占到50%，則執行Copy策略。	是
21	-XX: PretenureSizeThreshold=64K	當申請內存的對象超過該值時，直接在old區分配。		默認值是0，即所有的對象都在Eden區分配。
22	-XX:MaxHeapFreeRatio=size	JVM中堆空間的最大預估值空閑百分比。GC進行垃圾收集時后，如果預估值堆空閑空間超過預定值，收縮預估值內存。		默認值70	是
23	-XX:MinHeapFreeRatio=size	JVM中堆空間的最小預估值空閑百分比。GC進行垃圾收集后，堆空間不得低於預定值，增加分配的內存。		默認值40	是
	-XX:MaxDirectMemorySize=size	直接內存最大值。即NIO進行操作時，可以分配的最大緩存值，默認和heap最大值一致。		默認和heap最大值一致。
24	JVM優化
25	-XX:CompileThreshold=10000	設置方法是否進行即時編譯的調用次數的下限值。調用次數超過設定值，進行JIT編譯。		-server選項的缺省值為10000，-client選項的缺省值為1500	是
	-XX:+BackgroundCompilation	后台啟用jit編譯
26	-XX:-CITime	設置Hotspot的一次即時編譯所需要的最大時間
27	-XX:+AggressiveOpts	啟用激進的編譯優化		JDK 5 update 6后引入，但需要手動啟用。 JDK6默認啟用。
28	-XX:+UseFastAccessorMethods	原始類型的快速優化，get,set方法轉成本地代碼。
29	-XX:+DoEscapeAnalysis	增加逃逸分析。如果對象的指針未出創建者的方法體，該對象在線程棧內直接分配空間。	1.6
30	-XX:+DisableExplicitGC	屏蔽程序主動垃圾收集的函數system.gc()			是
31	-XX:FreqInlineSize=size	限制經常使用的動態編譯的函數的虛擬機指令的最大數量，
32	-XX:+UseLargePages	啟用大內存分頁。注意操作系統需支持。 關聯參數：-XX:LargePageSizeInBytes=4m
33	-XX:LargePageSizeInBytes=4m	設置堆內存的內存頁大小。		默認4K。
34	-XX:+UseBiasedLocking	啟用偏向鎖。		JDK 5 update 6后引入，但需要手動啟用。 JDK6默認啟用。
35	-XX:+UseSpinning	啟用多線程自旋鎖優化。 自旋鎖優化原理 大家知道，Java的多線程安全是基於Lock機制實現的，而Lock的性能往往不如人意。 原因是，monitorenter與monitorexit這兩個控制多線程同步的bytecode原語，是JVM依賴操作系統互斥(mutex)來實現的。 互斥是一種會導致線程掛起，並在較短的時間內又必須重新調度回原線程的，較為消耗資源的操作。 為了避免進入OS互斥，Java6的開發者們提出了自旋鎖優化。 自旋鎖優化的原理是在線程進入OS互斥前，通過CAS自旋一定的次數來檢測鎖的釋放。 如果在自旋次數未達到預設值前鎖已被釋放，則當前線程會立即持有該鎖。		java1.4.2和1.5需要手動啟用, java6默認已啟用
36	-XX:PreBlockSpin=10	控制多線程自旋鎖優化的自旋次數。(什么是自旋鎖優化？見 -XX:+UseSpinning 處的描述) 關聯選項： -XX:+UseSpinning		java6來說已經默認啟用了，這里默認自旋10次
37	-XX:+UseSplitVerifier	使用新的Class類型校驗器 。 新Class類型校驗器有什么特點？ 新Class類型校驗器，將老的校驗步驟拆分成了兩步： 1，類型推斷。 2，類型校驗。 新類型校驗器通過在javac編譯時嵌入類型信息到bytecode中，省略了類型推斷這一步，從而提升了classloader的性能。 Classload順序（供參考） load -> verify -> prepare -> resove -> init 關聯選項： -XX:+FailOverToOldVerifier		java5默認不啟用 java6默認啟用
38	-XX:+FailOverToOldVerifier	如果新的Class校驗器檢查失敗，則使用老的校驗器。 為什么會失敗？ 因為JDK6最高向下兼容到JDK1.2，而JDK1.2的class info 與JDK6的info存在較大的差異，所以新校驗器可能會出現校驗失敗的情況。 關聯選項： -XX:+UseSplitVerifier		Java6新引入選項，默認啟用
39	-XX:+HandlePromotionFailure	關閉新生代收集擔保。 在一次理想化的minor gc中，Eden和First Survivor中的活躍對象會被復制到Second Survivor。然而，Second Survivor不一定能容納下所有從E和F區copy過來的活躍對象。為了確保minor gc能夠順利完成，GC需要在年老代中額外保留一塊足以容納所有活躍對象的內存空間。這個預留操作，就被稱之為新生代收集擔保（New Generation Guarantee）。如果預留操作無法完成時，仍會觸發major gc(full gc)。 為什么要關閉新生代收集擔保？ 因為在年老代中預留的空間大小，是無法精確計算的。為了確保極端情況的發生，GC參考了最壞情況下的新生代內存占用，即Eden+First Survivor。這種策略無疑是在浪費年老代內存，從時序角度看，還會提前觸發Full GC。為了避免如上情況的發生，JVM允許開發者手動關閉新生代收集擔保。在開啟本選項后，minor gc將不再提供新生代收集擔保，而是在出現survior或年老代不夠用時，拋出promotion failed異常。		java5以前是默認不啟用，java6默認啟用
40	-XX:+UseTLAB	啟用線程本地緩存區（Thread Local）。		1.4.2以前和使用-client選項時，默認不啟用，其余版本默認啟用
41	-XX:+UseThreadPriorities	使用本地線程的優先級。		默認啟用
42	-XX:-UseLWPSynchronization	使用操作系統提供的輕量級線程LWP同步來代替基於Java虛擬機的線程的同步		限於solaris，默認啟用
43	-XX:+UseBoundThreads	綁定所有的用戶線程到內核線程。 減少線程進入飢餓狀態（得不到任何cpu time）的次數。		限於solaris，默認啟用
44	垃圾收集器設置
45	-XX:+UseSerialGC	設置串行收集器。			是
46	-XX:+UseParallelGC	選擇垃圾收集器為並行收集器，此配置僅對年輕代有效，即上述配置下，年輕代使用並行收集，而老年代仍舊使用串行收集。采用了多線程並行管理和回收垃圾對象，提高了回收效率，提高了服務器的吞吐量，適合於多處理器的服務器。			是
47	-XX:+UseParNewGC	指定在 New Generation使用 parallel collector,是 UseParallelGC的 gc的升級版本 ,有更好的性能或者優點 ,可以和 CMS gc一起使用			是
48	-XX:+UseParallelOldGC	采用對於老年代並行收集的策略，可以提高收集效率。JDK6.0支持對老年代並行收集。			是
49	-XX:+UseConcMarkSweepGC	指定在老年代使用 concurrent cmark sweep gc。gc thread和 app thread並行 (在 init-mark和 remark時 pause app thread)。app pause時間較短 ,適合交互性強的系統 ,如 web server。它可以並發執行收集操作，降低應用停止時間，同時它也是並行處理模式，可以有效地利用多處理器的系統的多進程處理。新生代默認使用：parnew		使用此垃圾收集器是，sun建議NewRatio=4
50	-XX:+CMSIncrementalMode	設置為增量模式。適用於單CPU情況
51	-XX:+ClassUnloading	對持久代卸載的類進行回收
52	-XX:+CMSClassUnloadingEnabled	使CMS收集持久代的unload的類，而不是fullgc
53	-XX:+CMSPermGenSweepingEnabled	使CMS收集持久代的類不引用的class，而不是fullgc。		1.JDK 1.6 32位下不可用。 2.JDK 1.5 64位下可用。
73	-XX:+UseAdaptiveSizePolicy	設置此選項后，並行收集器會對於收集時間、分配比例、收集之 后 堆的空閑空間等數據進行統計分析，然后以此為依據調整新生代和舊生代的大小以達到最佳效果。此值建議使用並行收集器時，一直打開。		適合吞吐量優先的垃圾收集器。 使用sun jdk（1.6.30以上到1.7的全部版本已經確認有該問題，jdk8修復，其他版本待驗證	是
74	-XX:+AggressiveHeap	選項會檢測主機的資源（內存大小、處理器數量），然后調整相關的參 數，使得長時間運行的、內存申請密集的任務能夠以最佳狀態運行。該選項最初是為擁有大量內存和 很多處理器的主機而設計的，但是從J2SE1.4.1以及其后繼版本來看，即使是對於那些只有4顆CPU的 主機，該選項都是很有幫助的。因此，吞吐收集器（-XX:+UseParallelGC）、大小自適應 （-XX:+UseAdaptiveSizePolicy）以及本選項（-XX:+AggressiveHeap）經常結合在一起使用。要使 用本選項，主機上至少要有256M的物理內存，堆內存的最初大小是基於物理內存計算出來的，然后 會根據需要盡可能的利用物理內存。用於JVM運行於大內存模式下，JVM的堆空間至少在1G以 上。與-Xms、-Xmx不同時使用，慎用！會導致JVM極度消耗內存		適合吞吐量優先的垃圾收集器。	是，在基建的性能調優時用過，並沒有顯示出出色的性能。
54	垃圾收集器相關參數
55	-XX:+ScavengeBeforeFullGC	並收集，在Full GC前觸發一次Minor GC。		默認啟用
57	-XX:+CMSParallelRemarkEnabled	盡量減少 mark的時間。			該參數未驗證。
	-XX:CMSScavengeBeforRemark	並發收集，在remark之前，啟動次收集。
56	-XX:+UseGCOverheadLimit	限制GC的運行時間。如果GC耗時過長，就拋OOM。		默認啟用
58	-XX:CMSFullGCsBeforeCompaction=10	由於並發收集器不對內存空間進行壓縮、整理，所以運行一段時間以后會產生“碎片”，使得運行效率降低。此值設置運行多少次GC以后對內存空間進行壓縮、整理。發生多少次CMS Full GC，這個參數最好不要設置，因為要做compaction的話，也就是真正的Full GC是串行的，非常慢，讓它自己去決定什么時候需要做compaction。		配合並發垃圾收集器。
59	-XX:+UseCMSCompactAtFullCollection	打開對老年代的壓縮。可能會影響性能，但是可以消除碎片,在FULL GC的時候，壓縮內存， CMS是不會移動內存的，因此，這個非常容易產生碎片，導致內存不夠用，因此，內存的壓縮這個時候就會被啟用。增加這個參數是個好習慣。		配合並發垃圾收集器。
60	-XX：CMSInitiatingOccupancyFraction	說明老年代到百分之多少滿的時候開始執行對老年代的並發垃圾回收（CMS），這個參數設置有很大技巧，基本上滿足公式： (Xmx-Xmn)*(100-CMSInitiatingOccupancyFraction)/100>=Xmn 時就不會出現promotion failed。在我的應用中Xmx是6000，Xmn是500，那么Xmx-Xmn是5500兆，也就是老年代有5500兆，CMSInitiatingOccupancyFraction=90說明老年代到90%滿的時候開始執行對老年代的並發垃圾回收（CMS），這時還剩10%的空間是5500*10%=550兆，所以即使Xmn（也就是年輕代共500兆）里所有對象都搬到老年代里，550兆的空間也足夠了，所以只要滿足上面的公式，就不會出現垃圾回收時的promotion failed； 如果按照Xmx=2048,Xmn=768的比例計算，則CMSInitiatingOccupancyFraction的值不能超過40，否則就容易出現垃圾回收時的promotion failed。		jdk：1.5配合並發垃圾收集器。默認是68%。 JDK 1.6 默認是92%。（太高，建議修改為80%）。
61	-XX:+UseCMSInitiatingOccupancyOnly	是否僅僅按照指定比例啟動CMS收集，默認為false。指示只有在老年代在使用了初始化的比例后 concurrent collector 啟動收集。 配合：，CMSInitiatingOccupancyFraction參數使用。		默認false
	-XX:CMSScheduleRemarkEdenSizeThreshold	即Eden區域多大的時候開始觸發remark，默認是2M		默認是2M
	-XX:CMSScheduleRemarkEdenPenetration	即Eden區域多大的時候開始出發remark，eden使用量超過百分比多少的時候觸發，默認是50%。		默認是50%。
	-XX:CMSMaxAbortablePrecleanTime	但是如果長期不做remark導致old做不了，可以設置超時，這個超時默認是5秒，超過5秒鍾做remark；設置preclean步驟的超時時間，單位為毫秒。		默認5秒
	-XX:CMSInitiatingPermOccupancyFraction	持久代內存達到多是，進行垃圾收集。
69	-XX:ConcGCThreads=n	Number of threads concurrent garbage collectors will use. The default value varies with the platform on which the JVM is running.		配合並發垃圾收集器。 (ParallelGCThreads + 3)/4)； ParallelGCThreads是年輕代的並行收集線程數	JDK 32位 1.6下不可用。
	-XX:ParallelCMSThreads	同上-XX:ConcGCThreads=n
70	-XX:MaxGCPauseMillis=	指定垃圾回收時的最長暫停時間。為毫秒.如果指定了此值的話，堆大小和垃圾回收相關參數會進行調整以達到指定值。設定此值可能會減少應用的吞吐量。		適合吞吐量優先的垃圾收集器。
71	-XX:GCTimeRatio=	為垃圾回收時間與非垃圾回收時間的比值.公式為1:（1+N）。例如，-XX:GCTimeRatio=19時，表示5%的時間用於垃圾回收。默認情況為99，即1%的時間用於垃圾回收。		適合吞吐量優先的垃圾收集器。 默認值：1%
	?-XX:+CMSConcurrentMTEnabled	在並發階段利用多核。
72	-XX:ParallelGCThreads=8	配置並行收集器的線程數，即：同時多少個線程一起進行垃圾回收。此值最好配置與處理器數目相等。 Sets the number of threads used during parallel phases of the garbage collectors. The default value varies with the platform on which the JVM is running.		並行垃圾收集器配套使用。 ncpus <= 8) ? ncpus : 3 + ((ncpus * 5) / 8)； 在cms垃圾收集中： 指定在stop-the-world過程中，並行線程的個數，默認cpu個數。
75	-Xnoincgc	在垃圾收集中不使用火車算法
76	-Xincgc	在垃圾收集中使用火車算法，降低暫停時間。注意會占用10%左右的CPU資源。		適合低停頓垃圾收集器。
62	-XX:+CMSIncrementalMode	在並發垃圾收集器中，使用增量模式。默認為不使用。	1.5	配合並發垃圾收集器。 默認不啟用	以下綠色表示增量收集，適用於單CPU情況。Sun不推薦使用
63	-XX:+CMSIncrementalPacing	This flag enables automatic adjustment of the incremental mode duty cycle based on statistics collected while the JVM is running.	1.5	配合並發垃圾收集器。 默認不啟用
64	-XX:CMSIncrementalDutyCycle=	This is the percentage (0-100) of time between minor collections that the concurrent collector is allowed to run. If CMSIncrementalPacing is enabled, then this is just the initial value.	1.5	配合並發垃圾收集器。 默認50
65	-XX:CMSIncrementalDutyCycleMin=	This is the percentage (0-100) which is the lower bound on the duty cycle when CMSIncrementalPacing is enabled.	1.5	配合並發垃圾收集器。 10
66	-XX:CMSIncrementalSafetyFactor=	This is the percentage (0-100) used to add conservatism when computing the duty cycle	1.5	配合並發垃圾收集器。 10
67	-XX:CMSIncrementalOffset=	This is the percentage (0-100) by which the incremental mode duty cycle is shifted to the right within the period between minor collections.	1.5	配合並發垃圾收集器。 0
68	-XX:CMSExpAvgFactor=	This is the percentage (0-100) used to weight the current sample when computing exponential averages for the concurrent collection statistics	1.5	配合並發垃圾收集器。 25
77	調試選項
78	-XX:-CITime	打印JIT編譯器編譯耗時。		1.4引入。 默認啟用
79	-XX:HeapDumpPath=./java_pid.hprof	堆內存快照的存儲文件路徑。文件名一般為 java___ _heapDump.hprof		不啟用
80	-XX:+HeapDumpOnOutOfMemoryError	在OOM時，輸出一個dump.core文件到		1.4.2 update12 和 5.0 update 7 引入。 默認不啟用
81	-XX:ErrorFile=./hs_err_pid.log		1.6	如果JVM crashed，將錯誤日志輸出到指定文件路徑。
	-verbose:gc	輸出垃圾回收信息和-Xloggc:path配合使用
	-Xloggc：filename -XX:GCLogFileSize=5M	gc日志輸出文件;日志文件分隔，每5M分隔一個文件。
82	-XX:+PrintCompilation	往stdout打印方法被JIT編譯時的信息。 例如： 1 java.lang.String::charAt (33 bytes)		不啟用
83	-XX:+PrintGC	開啟GC日志打印。 打印格式例如： [Full GC 131115K->7482K(1015808K), 0.1633180 secs]		不啟用
84	-XX:+PrintGCDetails	打印GC回收的細節。 打印格式例如： [Full GC (System) [Tenured: 0K->2394K(466048K), 0.0624140 secs] 30822K->2394K(518464K), [Perm : 10443K->10443K(16384K)], 0.0625410 secs] [Times: user=0.05 sys=0.01, real=0.06 secs]		不啟用
85	-XX:+PrintGCTimeStamps	打印GC停頓耗時。 打印格式例如： 2.744: [Full GC (System) 2.744: [Tenured: 0K->2441K(466048K), 0.0598400 secs] 31754K->2441K(518464K), [Perm : 10717K->10717K(16384K)], 0.0599570 secs] [Times: user=0.06 sys=0.00, real=0.06secs]		不啟用
86	-XX:+PrintTenuringDistribution	打印對象的存活期限信息。 打印格式例如： [GC Desired survivor size 4653056 bytes, new threshold 32 (max 32) - age 1: 2330640 bytes, 2330640 total - age 2: 9520 bytes, 2340160 total 204009K->21850K(515200K), 0.1563482 secs] Age1 2表示在第1和2次GC后存活的對象大小。		不啟用
87	-XX:+TraceClassLoading	打印class裝載信息到stdout。記Loaded狀態。		不啟用
88	-XX:+TraceClassLoadingPreorder	按class的引用/依賴順序打印類裝載信息到stdout。不同於 TraceClassLoading，本選項只記 Loading狀態。	1.4.2	不啟用
89	-XX:+TraceClassUnloading	打印class的卸載信息到stdout。記Unloaded狀態。		不啟用
90	-XX:+TraceClassResolution	打印所有靜態類，常量的代碼引用位置。用於debug。 例如： RESOLVE java.util.HashMap java.util.HashMap$Entry HashMap.java:209 說明HashMap類的209行引用了靜態類 java.util.HashMap$Entry	1.4.2	不啟用
91	-XX:+TraceClassUnloading	打印class的卸載信息到stdout。記Unloaded狀態。		不啟用
92	-XX:+TraceLoaderConstraints	打印class的裝載策略變化信息到stdout。 例如： [Adding new constraint for name: java/lang/String, loader[0]: sun/misc/Launcher$ExtClassLoader, loader[1]: ] 裝載策略變化是實現classloader隔離/名稱空間一致性的關鍵技術。	1.6	不啟用
93	-XX:+PerfSaveDataToFile	當java進程因OOM或crashed被強制終止后，生成一個堆快照文件（什么是堆內存快照? 見 -XX:HeapDumpPath 處的描述）