1. 程式人生 > >JVM的配置引數

JVM的配置引數

最近看一些關於jvm的文章,感覺這個的介紹偏向於使用,轉載一下。

堆記憶體設定

原理

JVM堆記憶體分為2塊:Permanent Space 和 Heap Space。
  • Permanent 即 持久代(Permanent Generation),主要存放的是Java類定義資訊,與垃圾收集器要收集的Java物件關係不大。
  • Heap = { Old + NEW = {Eden, from, to} },Old 即 年老代(Old Generation),New 即 年輕代(Young Generation)。年老代和年輕代的劃分對垃圾收集影響比較大。

年輕代

所有新生成的物件首先都是放在年輕代。年輕代的目標就是儘可能快速的收集掉那些生命週期短的物件。年輕代一般分3個區,1個Eden區,2個Survivor區(from 和 to)。

大部分物件在Eden區中生成。當Eden區滿時,還存活的物件將被複制到Survivor區(兩個中的一個),當一個Survivor區滿時,此區的存活物件將被複制到另外一個Survivor區,當另一個Survivor區也滿了的時候,從前一個Survivor區複製過來的並且此時還存活的物件,將可能被複制到年老代。

2個Survivor區是對稱的,沒有先後關係,所以同一個Survivor區中可能同時存在從Eden區複製過來物件,和從另一個Survivor區複製過來的物件;而複製到年老區的只有從另一個Survivor區過來的物件。而且,因為需要交換的原因,Survivor區至少有一個是空的。特殊的情況下,根據程式需要,Survivor區是可以配置為多個的(多於2個),這樣可以增加物件在年輕代中的存在時間,減少被放到年老代的可能。

針對年輕代的垃圾回收即 Young GC。

年老代

在年輕代中經歷了N次(可配置)垃圾回收後仍然存活的物件,就會被複制到年老代中。因此,可以認為年老代中存放的都是一些生命週期較長的物件。

針對年老代的垃圾回收即 Full GC。

持久代

用於存放靜態型別資料,如 Java Class, Method 等。持久代對垃圾回收沒有顯著影響。但是有些應用可能動態生成或呼叫一些Class,例如 Hibernate CGLib 等,在這種時候往往需要設定一個比較大的持久代空間來存放這些執行過程中動態增加的型別。

所以,當一組物件生成時,記憶體申請過程如下:

  1. JVM會試圖為相關Java物件在年輕代的Eden區中初始化一塊記憶體區域。
  2. 當Eden區空間足夠時,記憶體申請結束。否則執行下一步。
  3. JVM試圖釋放在Eden區中所有不活躍的物件(Young GC)。釋放後若Eden空間仍然不足以放入新物件,JVM則試圖將部分Eden區中活躍物件放入Survivor區。
  4. Survivor區被用來作為Eden區及年老代的中間交換區域。當年老代空間足夠時,Survivor區中存活了一定次數的物件會被移到年老代。
  5. 當年老代空間不夠時,JVM會在年老代進行完全的垃圾回收(Full GC)。
  6. Full GC後,若Survivor區及年老代仍然無法存放從Eden區複製過來的物件,則會導致JVM無法在Eden區為新生成的物件申請記憶體,即出現“Out of Memory”。

OOM(“Out of Memory”)異常一般主要有如下2種原因

1. 年老代溢位,表現為:java.lang.OutOfMemoryError:Javaheapspace 這是最常見的情況,產生的原因可能是:設定的記憶體引數Xmx過小或程式的記憶體洩露及使用不當問題。 例如迴圈上萬次的字串處理、建立上千萬個物件、在一段程式碼內申請上百M甚至上G的記憶體。還有的時候雖然不會報記憶體溢位,卻會使系統不間斷的垃圾回收,也無法處理其它請求。這種情況下除了檢查程式、列印堆記憶體等方法排查,還可以藉助一些記憶體分析工具,比如MAT就很不錯。
2. 持久代溢位,表現為:java.lang.OutOfMemoryError:PermGenspace 通常由於持久代設定過小,動態載入了大量Java類而導致溢位,解決辦法唯有將引數 -XX:MaxPermSize 調大(一般256m能滿足絕大多數應用程式需求)。將部分Java類放到容器共享區(例如Tomcat share lib)去載入的辦法也是一個思路,但前提是容器裡部署了多個應用,且這些應用有大量的共享類庫。

引數說明

  • -Xmx3550m:設定JVM最大堆記憶體為3550M。
  • -Xms3550m:設定JVM初始堆記憶體為3550M。此值可以設定與-Xmx相同,以避免每次垃圾回收完成後JVM重新分配記憶體。
  • -Xss128k:設定每個執行緒的棧大小。JDK5.0以後每個執行緒棧大小為1M,之前每個執行緒棧大小為256K。應當根據應用的執行緒所需記憶體大小進行調整。在相同實體記憶體下,減小這個值能生成更多的執行緒。但是作業系統對一個程序內的執行緒數還是有限制的,不能無限生成,經驗值在3000~5000左右。需要注意的是:當這個值被設定的較大(例如>2MB)時將會在很大程度上降低系統的效能。
  • -Xmn2g:設定年輕代大小為2G。在整個堆記憶體大小確定的情況下,增大年輕代將會減小年老代,反之亦然。此值關係到JVM垃圾回收,對系統性能影響較大,官方推薦配置為整個堆大小的3/8。
  • -XX:NewSize=1024m:設定年輕代初始值為1024M。
  • -XX:MaxNewSize=1024m:設定年輕代最大值為1024M。
  • -XX:PermSize=256m:設定持久代初始值為256M。
  • -XX:MaxPermSize=256m:設定持久代最大值為256M。
  • -XX:NewRatio=4:設定年輕代(包括1個Eden和2個Survivor區)與年老代的比值。表示年輕代比年老代為1:4。
  • -XX:SurvivorRatio=4:設定年輕代中Eden區與Survivor區的比值。表示2個Survivor區(JVM堆記憶體年輕代中預設有2個大小相等的Survivor區)與1個Eden區的比值為2:4,即1個Survivor區佔整個年輕代大小的1/6。
  • -XX:MaxTenuringThreshold=7:表示一個物件如果在Survivor區(救助空間)移動了7次還沒有被垃圾回收就進入年老代。如果設定為0的話,則年輕代物件不經過Survivor區,直接進入年老代,對於需要大量常駐記憶體的應用,這樣做可以提高效率。如果將此值設定為一個較大值,則年輕代物件會在Survivor區進行多次複製,這樣可以增加物件在年輕代存活時間,增加物件在年輕代被垃圾回收的概率,減少Full GC的頻率,這樣做可以在某種程度上提高服務穩定性。

疑問解答

-Xmn,-XX:NewSize/-XX:MaxNewSize,-XX:NewRatio 3組引數都可以影響年輕代的大小,混合使用的情況下,優先順序是什麼?
如下:
  1. 高優先順序:-XX:NewSize/-XX:MaxNewSize 
  2. 中優先順序:-Xmn(預設等效  -Xmn=-XX:NewSize=-XX:MaxNewSize=?) 
  3. 低優先順序:-XX:NewRatio 
推薦使用-Xmn引數,原因是這個引數簡潔,相當於一次設定 NewSize/MaxNewSIze,而且兩者相等,適用於生產環境。-Xmn 配合 -Xms/-Xmx,即可將堆記憶體佈局完成。 -Xmn引數是在JDK 1.4 開始支援。

垃圾回收器選擇

JVM給出了3種選擇:序列收集器、並行收集器、併發收集器。序列收集器只適用於小資料量的情況,所以生產環境的選擇主要是並行收集器和併發收集器。

預設情況下JDK5.0以前都是使用序列收集器,如果想使用其他收集器需要在啟動時加入相應引數。JDK5.0以後,JVM會根據當前系統配置進行智慧判斷。

序列收集器

  • -XX:+UseSerialGC:設定序列收集器。

並行收集器(吞吐量優先)

  • -XX:+UseParallelGC:設定為並行收集器。此配置僅對年輕代有效。即年輕代使用並行收集,而年老代仍使用序列收集。
  • -XX:ParallelGCThreads=20:配置並行收集器的執行緒數,即:同時有多少個執行緒一起進行垃圾回收。此值建議配置與CPU數目相等。
  • -XX:+UseParallelOldGC:配置年老代垃圾收集方式為並行收集。JDK6.0開始支援對年老代並行收集。
  • -XX:MaxGCPauseMillis=100:設定每次年輕代垃圾回收的最長時間(單位毫秒)。如果無法滿足此時間,JVM會自動調整年輕代大小,以滿足此時間。
  • -XX:+UseAdaptiveSizePolicy:設定此選項後,並行收集器會自動調整年輕代Eden區大小和Survivor區大小的比例,以達成目標系統規定的最低響應時間或者收集頻率等指標。此引數建議在使用並行收集器時,一直開啟。

併發收集器(響應時間優先)

  • -XX:+UseConcMarkSweepGC:即CMS收集,設定年老代為併發收集。CMS收集是JDK1.4後期版本開始引入的新GC演算法。它的主要適合場景是對響應時間的重要性需求大於對吞吐量的需求,能夠承受垃圾回收執行緒和應用執行緒共享CPU資源,並且應用中存在比較多的長生命週期物件。CMS收集的目標是儘量減少應用的暫停時間,減少Full GC發生的機率,利用和應用程式執行緒併發的垃圾回收執行緒來標記清除年老代記憶體。
  • -XX:+UseParNewGC:設定年輕代為併發收集。可與CMS收集同時使用。JDK5.0以上,JVM會根據系統配置自行設定,所以無需再設定此引數。
  • -XX:CMSFullGCsBeforeCompaction=0:由於併發收集器不對記憶體空間進行壓縮和整理,所以執行一段時間並行收集以後會產生記憶體碎片,記憶體使用效率降低。此引數設定執行0次Full GC後對記憶體空間進行壓縮和整理,即每次Full GC後立刻開始壓縮和整理記憶體。
  • -XX:+UseCMSCompactAtFullCollection:開啟記憶體空間的壓縮和整理,在Full GC後執行。可能會影響效能,但可以消除記憶體碎片。
  • -XX:+CMSIncrementalMode:設定為增量收集模式。一般適用於單CPU情況。
  • -XX:CMSInitiatingOccupancyFraction=70:表示年老代記憶體空間使用到70%時就開始執行CMS收集,以確保年老代有足夠的空間接納來自年輕代的物件,避免Full GC的發生。

其它垃圾回收引數

  • -XX:+ScavengeBeforeFullGC:年輕代GC優於Full GC執行。
  • -XX:-DisableExplicitGC:不響應 System.gc() 程式碼。
  • -XX:+UseThreadPriorities:啟用本地執行緒優先順序API。即使 java.lang.Thread.setPriority() 生效,不啟用則無效。
  • -XX:SoftRefLRUPolicyMSPerMB=0:軟引用物件在最後一次被訪問後能存活0毫秒(JVM預設為1000毫秒)。
  • -XX:TargetSurvivorRatio=90:允許90%的Survivor區被佔用(JVM預設為50%)。提高對於Survivor區的使用率。

輔助資訊引數設定

  • -XX:-CITime:列印消耗在JIT編譯的時間。
  • -XX:ErrorFile=./hs_err_pid.log:儲存錯誤日誌或資料到指定檔案中。
  • -XX:HeapDumpPath=./java_pid.hprof:指定Dump堆記憶體時的路徑。
  • -XX:-HeapDumpOnOutOfMemoryError:當首次遭遇記憶體溢位時Dump出此時的堆記憶體。
  • -XX:OnError=";":出現致命ERROR後執行自定義命令。
  • -XX:OnOutOfMemoryError=";":當首次遭遇記憶體溢位時執行自定義命令。
  • -XX:-PrintClassHistogram:按下 Ctrl+Break 後列印堆記憶體中類例項的柱狀資訊,同JDK的 jmap -histo 命令。
  • -XX:-PrintConcurrentLocks:按下 Ctrl+Break 後列印執行緒棧中併發鎖的相關資訊,同JDK的 jstack -l 命令。
  • -XX:-PrintCompilation:當一個方法被編譯時列印相關資訊。
  • -XX:-PrintGC:每次GC時列印相關資訊。
  • -XX:-PrintGCDetails:每次GC時列印詳細資訊。
  • -XX:-PrintGCTimeStamps:列印每次GC的時間戳。
  • -XX:-TraceClassLoading:跟蹤類的載入資訊。
  • -XX:-TraceClassLoadingPreorder:跟蹤被引用到的所有類的載入資訊。
  • -XX:-TraceClassResolution:跟蹤常量池。
  • -XX:-TraceClassUnloading:跟蹤類的解除安裝資訊。

關於引數名稱等

  • 標準引數(-),所有JVM都必須支援這些引數的功能,而且向後相容;例如:
    • -client——設定JVM使用Client模式,特點是啟動速度比較快,但執行時效能和記憶體管理效率不高,通常用於客戶端應用程式或開發除錯;在32位環境下直接執行Java程式預設啟用該模式。
    • -server——設定JVM使Server模式,特點是啟動速度比較慢,但執行時效能和記憶體管理效率很高,適用於生產環境。在具有64位能力的JDK環境下預設啟用該模式。
  • 非標準引數(-X),預設JVM實現這些引數的功能,但是並不保證所有JVM實現都滿足,且不保證向後相容;
  • 非穩定引數(-XX),此類引數各個JVM實現會有所不同,將來可能會不被支援,需要慎重使用;

JVM服務引數調優實戰

大型網站伺服器案例

承受海量訪問的動態Web應用

伺服器配置:8 CPU, 8G MEM, JDK 1.6.X

引數方案:

-server -Xmx3550m -Xms3550m -Xmn1256m -Xss128k -XX:SurvivorRatio=6 -XX:MaxPermSize=256m -XX:ParallelGCThreads=8 -XX:MaxTenuringThreshold=0 -XX:+UseConcMarkSweepGC

調優說明:

  • -Xmx 與 -Xms 相同以避免JVM反覆重新申請記憶體。-Xmx 的大小約等於系統記憶體大小的一半,即充分利用系統資源,又給予系統安全執行的空間。
  • -Xmn1256m 設定年輕代大小為1256MB。此值對系統性能影響較大,Sun官方推薦配置年輕代大小為整個堆的3/8。
  • -Xss128k 設定較小的執行緒棧以支援建立更多的執行緒,支援海量訪問,並提升系統性能。
  • -XX:SurvivorRatio=6 設定年輕代中Eden區與Survivor區的比值。系統預設是8,根據經驗設定為6,則2個Survivor區與1個Eden區的比值為2:6,一個Survivor區佔整個年輕代的1/8。
  • -XX:ParallelGCThreads=8 配置並行收集器的執行緒數,即同時8個執行緒一起進行垃圾回收。此值一般配置為與CPU數目相等。
  • -XX:MaxTenuringThreshold=0 設定垃圾最大年齡(在年輕代的存活次數)。如果設定為0的話,則年輕代物件不經過Survivor區直接進入年老代。對於年老代比較多的應用,可以提高效率;如果將此值設定為一個較大值,則年輕代物件會在Survivor區進行多次複製,這樣可以增加物件再年輕代的存活時間,增加在年輕代即被回收的概率。根據被海量訪問的動態Web應用之特點,其記憶體要麼被快取起來以減少直接訪問DB,要麼被快速回收以支援高併發海量請求,因此其記憶體物件在年輕代存活多次意義不大,可以直接進入年老代,根據實際應用效果,在這裡設定此值為0。
  • -XX:+UseConcMarkSweepGC 設定年老代為併發收集。CMS(ConcMarkSweepGC)收集的目標是儘量減少應用的暫停時間,減少Full GC發生的機率,利用和應用程式執行緒併發的垃圾回收執行緒來標記清除年老代記憶體,適用於應用中存在比較多的長生命週期物件的情況。

內部整合構建伺服器案例

高效能資料處理的工具應用

伺服器配置:1 CPU, 4G MEM, JDK 1.6.X

引數方案:

-server -XX:PermSize=196m -XX:MaxPermSize=196m -Xmn320m -Xms768m -Xmx1024m

調優說明:

  • -XX:PermSize=196m -XX:MaxPermSize=196m 根據整合構建的特點,大規模的系統編譯可能需要載入大量的Java類到記憶體中,所以預先分配好大量的持久代記憶體是高效和必要的。
  • -Xmn320m 遵循年輕代大小為整個堆的3/8原則。
  • -Xms768m -Xmx1024m 根據系統大致能夠承受的堆記憶體大小設定即可。
在64位伺服器上執行應用程式,構建執行時,用 jmap -heap 11540 命令觀察JVM堆記憶體狀況如下:

Attaching to process ID 11540, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 20.12-b01


using thread-local object allocation.
Parallel GC with 4 thread(s)


Heap Configuration:
   MinHeapFreeRatio = 40
   MaxHeapFreeRatio = 70
   MaxHeapSize      = 1073741824 (1024.0MB)
   NewSize          = 335544320 (320.0MB)
   MaxNewSize       = 335544320 (320.0MB)
   OldSize          = 5439488 (5.1875MB)
   NewRatio         = 2
   SurvivorRatio    = 8
   PermSize         = 205520896 (196.0MB)
   MaxPermSize      = 205520896 (196.0MB)


Heap Usage:
PS Young Generation
Eden Space:
   capacity = 255852544 (244.0MB)
   used     = 101395504 (96.69828796386719MB)
   free     = 154457040 (147.3017120361328MB)
   39.63044588683081% used
From Space:
   capacity = 34144256 (32.5625MB)
   used     = 33993968 (32.41917419433594MB)
   free     = 150288 (0.1433258056640625MB)
   99.55984397492803% used
To Space:
   capacity = 39845888 (38.0MB)
   used     = 0 (0.0MB)
   free     = 39845888 (38.0MB)
   0.0% used
PS Old Generation
   capacity = 469762048 (448.0MB)
   used     = 44347696 (42.29325866699219MB)
   free     = 425414352 (405.7067413330078MB)
   9.440459523882184% used
PS Perm Generation
   capacity = 205520896 (196.0MB)
   used     = 85169496 (81.22396087646484MB)
   free     = 120351400 (114.77603912353516MB)
   41.440796365543285% used

結果是比較健康的。

相關推薦

JVM配置引數詳解

一、堆引數設定 -XX:+PrintGC 使用這個引數,虛擬機器啟動後,只要遇到GC就會列印日誌 -XX:+UseSerialGC 配置序列回收器 -XX:+PrintGCDetails 可以檢視詳細資訊,包括各個區的情況 -Xms:設定Java程式啟動

關於docker執行Java程式JVM配置引數使用jconsole的簡單量化過程

1.如果服務可以本地啟動那麼儘量在本地進行引數預估 2.如果服務不能本地啟動,可以使用遠端連線方式進行預估   3.衡量要點: Java程式執行大致分為三塊:堆記憶體,非堆記憶體(虛擬機器棧,方法區,本地方法棧,程式計數器),堆外記憶體. docker容器中執行除了

深入理解JVM——配置引數(三);垃圾回收演算法(四)

深入理解JVM(三)——配置引數 1、跟蹤引數 2、堆分配引數 3、棧分配引數 這三類引數分別用於跟蹤監控JVM狀態,分配堆記憶體、棧記憶體。 跟蹤引數 跟蹤監控JVM,用於JVM調優以及故障排查。 1、當發生GC時,列印GC簡要資訊 使

jdk8 jvm配置引數說明

這些選項是特定於Java HotSpot虛擬機器的通用選項。 -X 顯示所有可用-X選項的幫助。 -Xbatch 禁用後臺編譯。預設情況下,JVM將該方法編譯為後臺任務,以直譯器模式執行該方法,直到後臺編譯完成。該-Xbatch標誌禁用後臺編譯,以便所有方法的編譯作為前臺任務繼續進行,直

JVM 配置引數

【宣告】  歡迎轉載,但請保留文章原始出處→_→  本文主要內容: Trace跟蹤引數堆的分配引數棧的分配引數 零、在IDE的後臺列印GC日誌: 既然學習JVM,閱讀GC日誌是處理Java虛擬機器記憶體問題的基礎技能,它只是一些人為確定的規則,沒有太多技術含

Java虛擬機器詳解03----常用JVM配置引數

本文主要內容: Trace跟蹤引數 堆的分配引數 棧的分配引數 零、在IDE的後臺列印GC日誌: 既然學習JVM,閱讀GC日誌是處理Java虛擬機器記憶體問題的基礎技能,它只是一些人為確定的規則,沒有太多技術含量。 既然如此,那麼在I

【Java虛擬機器探究】5.常用JVM配置引數-棧的分配引數

在使用JVM編譯java時,都會去設定相關的引數(例如使用eclipse的時候,可以設定eclipse的eclipse.ini檔案來對jvm做一些引數配置)。jvm的引數設定主要涉及到三種,分別是Trace跟蹤引數、堆的分配引數、棧的分配引數。本章主要講解棧的分配引數的相關資

常用JVM配置引數

【宣告】  歡迎轉載,但請保留文章原始出處→_→  本文主要內容: Trace跟蹤引數 堆的分配引數 棧的分配引數 零、在IDE的後臺列印GC日誌: 既然學習JVM,閱讀GC日誌是處理Java虛擬機器記憶體問題的基礎

Java虛擬機器詳解----常用JVM配置引數

原文地址:http://www.cnblogs.com/smyhvae/p/4736162.html 本文主要內容: Trace跟蹤引數堆的分配引數棧的分配引數 零、在IDE的後臺列印GC日誌: 既然學習JVM,閱讀GC日誌是處理Java虛擬機器記憶體問題的

jenkins 對 maven對應的 jvm 配置引數

If you get an java.lang.OutOfMemoryError, you can set the MAVEN_OPTS environment variable, like this in *nix environments: export MAVEN_OPTS="-Xm

JVM調優---常用JVM配置引數

一、Trace跟蹤引數(跟蹤GC、類、變數的記憶體變化情況) 開啟GC跟蹤日誌(每次執行GC的資訊都能列印,獲得執行時間,空間大小): -verbose:gc 或 -XX:+printGC 或 -XX:+printGCDetails 類載入監控:(監控類載入的順序

JVM 記憶體配置引數

對於JVM記憶體配置引數: -Xmx10240m -Xms10240m -Xmn5120m -XXSurvivorRatio=3   -Xmx:最大堆大小 -Xms:初始堆大小 -Xmn:年輕代大小 -XXSurvivorRatio:年輕代中Eden區

JVM JMM 引數配置,記憶體模型

  java虛擬機器在執行Java程式的過程中會把它所管理的記憶體劃分為若干個不同的資料區域。這些區域都有各自的用途,以及建立和銷燬的時間。有的區域隨著虛擬機器程序的啟動而存在,有些區域則是依賴使用者執行緒的啟動和結束而建立和銷燬。 JVM記憶體模型可以分為兩個部分,如下圖所示

JVM G1GC引數配置

https://www.oracle.com/technetwork/articles/java/g1gc-1984535.html         主要這兩個引數需要設定下,ParallelGCThreads=8 MaxGCPause

jvm 常用配置引數

-verbose:gc 列印 GC 的簡要資訊 -XX:+printGC 列印 GC 的簡要資訊 [GC (Allocation Failure) 6036K->1672K(19968K), 0.0012595 secs] -XX:+Print

JVM 常用引數配置

常用引數: -Xmx :堆的最大值 -Xms :堆的最小值 -Xmn :堆年輕代大小 (eden+ 2 survivor space) -XX:PermSize: 設定持久代(perm gen)初始值 -XX:MaxPermSize: 設定持久代最大值 -XXSurvivorRatio:

JVM - 常見配置引數

  堆疊常用 -Xms :初始堆大小 -Xmx :最大堆大小 -Xss  :為jvm啟動的每個執行緒分配的記憶體大小 -XX:NewSize=n :設定年輕代大小 -XX:NewRatio=n: 設定老

解析 JVM記憶體配置引數 -Xmx10240m -Xms10240m -Xmn5120m -XXSurvivorRatio=3

-Xmx:最大堆大小 -Xms:初始堆大小 -Xmn:年輕代大小 -XXSurvivorRatio:年輕代中Eden區與Survivor區的大小比值 年輕代5120m, Eden : Survivor=3,Survivor區大小=1024m(Survivor區有兩個,即將年輕代分為5

JVM記憶體配置引數、GC工作原理及Minor GC、FullGC

對於JVM記憶體配置引數:-Xmx10240m -Xms10240m -Xmn5120m -XXSurvivorRatio=3,其最小記憶體值和Survivor區總大小分別是()5120m,1024m5120m,2048m10240m,1024m10240m,2048mD-X

idea配置jvm啟動引數

前言:         最近在看《深入理解JAVA虛擬機器》這本書,需要在IDE中設定JVM的一些引數資訊。本人使用的是idea,所以記錄一下如何使用idea配置JVM引數。 1、Run-EditCo