恰逢本人最近正在學些JVM虛擬機器一些引數配置、簡單優化的東西，下面是整理的一些通用引數的含義或配置說明，雖然這些配置網上到處都有，但筆者這是結合實際應用加以整理收集的，希望能帶來參考價值，最後附上某一知名大公司JVM配置清單，以做參考。

-XX:CMSClassUnloadingEnabled

HotspotJVM預設的gc是並行收集器，CMS相對於並行收集器不同的是CMS只回收老年代與永久代，且CMS並不預設回收永久代需要開啟 CMSClassUnloadingEnabled 引數。

-XX:+UseCMSCompactAtFullCollection

在Full GC時,開啟對年老代的壓縮.

-XX:CMSFullGCsBeforeCompaction=9

設定CMS GC在n次Full GC後進行記憶體壓縮

-XX:CMSInitiatingOccupancyFraction=80

配置記憶體佔比超過80%進行一次gc

-XX:+CMSParallelRemarkEnabled

降低標記停頓

gc停頓的意思就像是在整個分析期間凍結在某個時間點上，具體的原因是防止在分析的時候，物件引用關係還在不斷的變化，如果沒有GC停頓很有可能分析不準確。

如何降低：在Serial的老年代垃圾收集器中，會把所有執行緒的暫停，停下來收集哪些是死亡物件。在CMS和G1中都採取了初始標記、併發標記、短暫GC停頓重新標記，初始標記會直接記錄能GC ROOTS 關聯的物件，在併發標記的時候有一個執行緒來標記，這個時候物件的發生的變化都會記錄下來，在重新標記的時候會修正，這樣就會降低GC停頓時間

-XX:+CMSScavengeBeforeRemark

• CMS GC分為初始標記->併發標記->併發預清理->重新標記->併發清除->併發重置幾個步驟,該引數的作用是在Remark前對年輕代進行一次minor gc，以減輕Remark的工作量click me

-XX:+ExplicitGCInvokesConcurrent

開啟此引數後，在做System.gc()時會做background模式CMS GC，即並行FULL GC，可提高FULL GC效率 CMS並行fullGC

-XX:-HeapDumpOnOutOfMemoryError

可以讓JVM在出現記憶體溢位時候Dump出當前的記憶體轉儲快照

-XX:HeapDumpPath=/data/applogs

DUMP檔案的路徑

-XX:InitialHeapSize=5361369088

出事堆記憶體大小

-XX:MaxNewSize=2061500416

最大新生代大小

-XX:MaxTenuringThreshold=9

在新生代中物件存活次數(經過Minor GC的次數)後仍然存活，就會晉升到老年代

-XX:NewSize=2061500416

新生代初始大小

-XX:OldPLABSize=16

XX:+PrintGC

輸出GC日誌

-XX:+PrintGCApplicationConcurrentTime

列印每次垃圾回收前，程式未中斷的執行時間

-XX:+PrintGCApplicationStoppedTime

輸出GC應用暫停的時間

-XX:+PrintGCDetails

輸出詳細的GC日誌

-XX:+PrintGCTimeStamps

輸出gc時間戳

-XX:+PrintGCDetails

輸出GC日期格式的時間戳

-XX:+PrintHeapAtGC

HotSpot在GC前後都會將GC堆的概要狀況輸出

-XX:-ReduceInitialCardMarks

解決gc bug card-marking performance optimization演算法在實現的時候有瑕疵，在某些情況下會引起heap corruption。這個情況主要發生在新建立的大物件 和Eden space大小差不多，然後jvm做young GC的時候。 解決方案：在啟動引數中增加-XX:-ReduceInitialCardMarks將效能優化策略關閉。

-XX:+ScavengeBeforeFullGC

在Full gc前進行一次minor dc

-XX:SoftRefLRUPolicyMSPerMB=0

官方解釋是：Soft reference在虛擬機器中比在客戶集中存活的更長一些。其清除頻率可以用命令列引數 -XX:SoftRefLRUPolicyMSPerMB=來控制，這可以指定每兆堆空閒空間的 soft reference 保持存活（一旦它不強可達了）的毫秒數，這意味著每兆堆中的空閒空間中的 soft reference 會（在最後一個強引用被回收之後）存活1秒鐘。注意，這是一個近似的值，因為 soft reference 只會在垃圾回收時才會被清除，而垃圾回收並不總在發生。系統預設為一秒，我覺得沒必要等1秒，客戶集中不用就立刻清除，改為 -XX:SoftRefLRUPolicyMSPerMB=0；

-XX:SurvivorRatio=8

SurvivorRation 與 Eden區的比例 8：1

-XX:ThreadStackSize=512

執行緒堆疊大小

-XX:+UseCMSInitiatingOccupancyOnly

只是用設定的回收閾值(上面指定的70%),如果不指定,JVM僅在第一次使用設定值,後續則自動調整

用-XX+UseCMSInitiatingOccupancyOnly標誌來命令JVM不基於執行時收集的資料來啟動CMS垃圾收集週期。而是，當該標誌被開啟時，JVM通過CMSInitiatingOccupancyFraction的值進行每一次CMS收集，而不僅僅是第一次。然而，請記住大多數情況下，JVM比我們自己能作出更好的垃圾收集決策。因此，只有當我們充足的理由(比如測試)並且對應用程式產生的物件的生命週期有深刻的認知時，才應該使用該標誌。

-XX:+UseCompressedOops

由於64位JVM消耗的記憶體會比32位的大1.5倍，因為物件指標在64位架構下，長度會翻倍（更寬的定址）。好在從JDK 1.6 update14開始，64 bit JVM正式支援了 -XX:+UseCompressedOops 這個可以壓縮指標，起到節約記憶體佔用的新引數 使用-XX:+UseCompressedOops壓縮物件指標

oops指的是普通物件指標(ordinary object pointers)。 Java堆中物件指標會被壓縮成32位

-XX:+UseCompressedClassPointers

壓縮類指標 物件中指向類元資料的指標會被壓縮成32位 類指標壓縮空間會有一個基地址

-XX:+UseConcMarkSweepGC

設定年老代為CMS併發收集

-XX:+UseParNewGC

設定年輕代為並行收集

-XX:+CMSClassUnloadingEnabled
-XX:CMSFullGCsBeforeCompaction=9
-XX:CMSInitiatingOccupancyFraction=80
-XX:+CMSParallelRemarkEnabled
-XX:+CMSScavengeBeforeRemark
-XX:+ExplicitGCInvokesConcurrent
-XX:-HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/data/applogs/HeapDumpOnOutOfMemoryError
-XX:InitialHeapSize=5361369088
-XX:MaxHeapSize=5361369088
-XX:MaxNewSize=2061500416
-XX:MaxTenuringThreshold=9
-XX:NewSize=2061500416
-XX:OldPLABSize=16
-XX:+PrintGC
-XX:+PrintGCApplicationConcurrentTime
-XX:+PrintGCApplicationStoppedTime
-XX:+PrintGCDateStamps
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-XX:+PrintHeapAtGC
-XX:-ReduceInitialCardMarks
-XX:+ScavengeBeforeFullGC
-XX:SoftRefLRUPolicyMSPerMB=0
-XX:SurvivorRatio=8
-XX:ThreadStackSize=512
-XX:+UseCMSCompactAtFullCollection
-XX:+UseCMSInitiatingOccupancyOnly
-XX:+UseCompressedClassPointers
-XX:+UseCompressedOops
-XX:+UseConcMarkSweepGC
-XX:+UseParNewGC