jdk1.8 Hotspot虛擬機器引數通用配置
恰逢本人最近正在學些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