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

本系列包括：

JVM性能調優1：JVM性能調優理論及實踐（收集整理）

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

JVM性能調優3：JVM_堆溢出分析過程和命令

JVm性能調優4：GC日誌分析

JVM性能調優5：Heap堆分析方法



序號	參數名	說明	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<size>	設置JVM啓動時初始內存堆的大小	1.6	物理內存的1/64.	是
9	-Xmx<size>	設置JVM啓動後動態申請堆內存的最大堆空間	1.6	MIN（物理內存的1/4,1G)	是
10	-Xmn<size>	爲新生代分配的內存大小。		和cpu核數相關，建議1core對應512M，不超過1G。	是
11	-Xss<size>	設置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=<N>	指定垃圾回收時的最長暫停時間。<N>爲毫秒.若是指定了此值的話，堆大小和垃圾回收相關參數會進行調整以達到指定值。設定此值可能會減小應用的吞吐量。		適合吞吐量優先的垃圾收集器。
71	-XX:GCTimeRatio=<N>	爲垃圾回收時間與非垃圾回收時間的比值.公式爲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=<N>	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=<N>	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=<N>	This is the percentage (0-100) used to add conservatism when computing the duty cycle	1.5	配合併發垃圾收集器。 10
67	-XX:CMSIncrementalOffset=<N>	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=<N>	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<pid>.hprof	堆內存快照的存儲文件路徑。文件名通常爲 java_<pid>_<date>_<time>_heapDump.hprof		不啓用
80	-XX:+HeapDumpOnOutOfMemoryError	在OOM時，輸出一個dump.core文件到		1.4.2 update12 和 5.0 update 7 引入。 默認不啓用
81	-XX:ErrorFile=./hs_err_pid<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]: <bootloader> ] 裝載策略變化是實現classloader隔離/名稱空間一致性的關鍵技術。	1.6	不啓用
93	-XX:+PerfSaveDataToFile	當java進程因OOM或crashed被強制終止後，生成一個堆快照文件（什麼是堆內存快照? 見 -XX:HeapDumpPath 處的描述）。		不啓用