JVM常用內(nèi)存參數(shù)配置有哪些

這篇文章主要為大家展示了“JVM常用內(nèi)存參數(shù)配置有哪些”，內(nèi)容簡而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓小編帶領(lǐng)大家一起研究并學習一下“JVM常用內(nèi)存參數(shù)配置有哪些”這篇文章吧。

創(chuàng)新互聯(lián)是一家集網(wǎng)站建設(shè),小店企業(yè)網(wǎng)站建設(shè),小店品牌網(wǎng)站建設(shè),網(wǎng)站定制,小店網(wǎng)站建設(shè)報價,網(wǎng)絡(luò)營銷,網(wǎng)絡(luò)優(yōu)化,小店網(wǎng)站推廣為一體的創(chuàng)新建站企業(yè)，幫助傳統(tǒng)企業(yè)提升企業(yè)形象加強企業(yè)競爭力?？沙浞譂M足這一群體相比中小企業(yè)更為豐富、高端、多元的互聯(lián)網(wǎng)需求。同時我們時刻保持專業(yè)、時尚、前沿，時刻以成就客戶成長自我，堅持不斷學習、思考、沉淀、凈化自己，讓我們?yōu)楦嗟钠髽I(yè)打造出實用型網(wǎng)站。

　　-Xms 

JVM啟動時申請的初始Heap值，默認為操作系統(tǒng)物理內(nèi)存的1/64但小于1G。默認當空余堆內(nèi)存大于70%時，JVM會減小heap的大小到-Xms指定的大小，可通過-XX:MaxHeapFreeRation=來指定這個比列。Server端JVM最好將-Xms和-Xmx設(shè)為相同值，避免每次垃圾回收完成后JVM重新分配內(nèi)存；開發(fā)測試機JVM可以保留默認值。(例如：-Xms4g)

　　-Xmx 

JVM可申請的最大Heap值，默認值為物理內(nèi)存的1/4但小于1G，默認當空余堆內(nèi)存小于40%時，JVM會增大Heap到-Xmx指定的大小，可通過-XX:MinHeapFreeRation=來指定這個比列。最佳設(shè)值應(yīng)該視物理內(nèi)存大小及計算機內(nèi)其他內(nèi)存開銷而定。(例如：-Xmx4g)

　　-Xmn 

Java Heap Young區(qū)大小。整個堆大小=年輕代大小 + 年老代大小 + 持久代大小(相對于HotSpot 類型的虛擬機來說)。持久代一般固定大小為64m，所以增大年輕代后，將會減小年老代大小。此值對系統(tǒng)性能影響較大，Sun官方推薦配置為整個堆的3/8。(例如：-Xmn2g)

程序新創(chuàng)建的對象都是從年輕代分配內(nèi)存，年輕代由Eden Space和兩塊相同大小的SurvivorSpace(通常又稱S0和S1或From和To)構(gòu)成，可通過-Xmn參數(shù)來指定年輕代的大小，也可以通過-XX:SurvivorRation來調(diào)整Eden Space及SurvivorSpace的大小。

老年代用于存放經(jīng)過多次新生代GC仍然存活的對象，例如緩存對象，新建的對象也有可能直接進入老年代，主要有兩種情況：1、大對象，可通過啟動參數(shù)設(shè)置-XX:PretenureSizeThreshold=1024(單位為字節(jié)，默認為0)來代表超過多大時就不在新生代分配，而是直接在老年代分配。2、大的數(shù)組對象，且數(shù)組中無引用外部對象。老年代所占的內(nèi)存大小為-Xmx對應(yīng)的值減去-Xmn對應(yīng)的值。如果在堆中沒有內(nèi)存完成實例分配，并且堆也無法再擴展時，將會拋出OutOfMemoryError異常。

　　-Xss 

Java每個線程的Stack大小。JDK5.0以后每個線程堆棧大小為1M，以前每個線程堆棧大小為256K。根據(jù)應(yīng)用的線程所需內(nèi)存大小進行調(diào)整。在相同物理內(nèi)存下，減小這個值能生成更多的線程。但是操作系統(tǒng)對一個進程內(nèi)的線程數(shù)還是有限制的，不能無限生成，經(jīng)驗值在3000~5000左右。(例如：-Xss1024K)

　　-XX:PermSize

持久代（方法區(qū)）的初始內(nèi)存大小。（例如：-XX:PermSize=64m）

　　-XX:MaxPermSize

持久代（方法區(qū)）的最大內(nèi)存大小。（例如：-XX:MaxPermSize=512m）

　　-XX:+UseSerialGC

串行（SerialGC）是jvm的默認GC方式，一般適用于小型應(yīng)用和單處理器，算法比較簡單，GC效率也較高，但可能會給應(yīng)用帶來停頓。

　　-XX:+UseParallelGC

并行（ParallelGC）是指多個線程并行執(zhí)行GC，一般適用于多處理器系統(tǒng)中，可以提高GC的效率，但算法復(fù)雜，系統(tǒng)消耗較大。（配合使用：-XX:ParallelGCThreads=8，并行收集器的線程數(shù)，此值最好配置與處理器數(shù)目相等）

　　-XX:+UseParNewGC

設(shè)置年輕代為并行收集，JKD5.0以上，JVM會根據(jù)系統(tǒng)配置自行設(shè)置，所以無需設(shè)置此值。

　　-XX:+UseParallelOldGC

設(shè)置年老代為并行收集，JKD6.0出現(xiàn)的參數(shù)選項。

　　-XX:+UseConcMarkSweepGC

并發(fā)（ConcMarkSweepGC）是指GC運行時，對應(yīng)用程序運行幾乎沒有影響（也會造成停頓，不過很小而已），GC和app兩者的線程在并發(fā)執(zhí)行，這樣可以最大限度不影響app的運行。

　　-XX:+UseCMSCompactAtFullCollection

在Full GC的時候，對老年代進行壓縮整理。因為CMS是不會移動內(nèi)存的，因此非常容易產(chǎn)生內(nèi)存碎片。因此增加這個參數(shù)就可以在FullGC后對內(nèi)存進行壓縮整理，消除內(nèi)存碎片。當然這個操作也有一定缺點，就是會增加CPU開銷與GC時間，所以可以通過-XX:CMSFullGCsBeforeCompaction=3 這個參數(shù)來控制多少次Full GC以后進行一次碎片整理。

　　-XX:+CMSInitiatingOccupancyFraction=80

代表老年代使用空間達到80%后，就進行Full GC。CMS收集器在進行垃圾收集時，和應(yīng)用程序一起工作，所以，不能等到老年代幾乎完全被填滿了再進行收集，這樣會影響并發(fā)的應(yīng)用線程的空間使用，從而再次觸發(fā)不必要的Full GC。

　　-XX:+MaxTenuringThreshold=10

垃圾的最大年齡，代表對象在Survivor區(qū)經(jīng)過10次復(fù)制以后才進入老年代。如果設(shè)置為0，則年輕代對象不經(jīng)過Survivor區(qū)，直接進入老年代。

　　JVM啟動參數(shù)共分為三類：

1、標準參數(shù)（-），所有的JVM實現(xiàn)都必須實現(xiàn)這些參數(shù)的功能，而且向后兼容。例如：-verbose:class（輸出jvm載入類的相關(guān)信息，當jvm報告說找不到類或者類沖突時可此進行診斷）；-verbose:gc（輸出每次GC的相關(guān)情況）；-verbose:jni（輸出native方法調(diào)用的相關(guān)情況，一般用于診斷jni調(diào)用錯誤信息）。

2、非標準參數(shù)（-X），默認jvm實現(xiàn)這些參數(shù)的功能，但是并不保證所有jvm實現(xiàn)都滿足，且不保證向后兼容。例如：-Xms512m；-Xmx512m；-Xmn200m；-Xss128k；-Xloggc:file（與-verbose:gc功能類似，只是將每次GC事件的相關(guān)情況記錄到一個文件中，文件的位置最好在本地，以避免網(wǎng)絡(luò)的潛在問題。若與verbose命令同時出現(xiàn)在命令行中，則以-Xloggc為準）。

3、非Stable參數(shù)（-XX），此類參數(shù)各個jvm實現(xiàn)會有所不同，將來可能會隨時取消，需要慎重使用。例如：-XX:PermSize=64m；-XX:MaxPermSize=512m。

不管是YGC還是Full GC,GC過程中都會對導(dǎo)致程序運行中中斷,正確的選擇不同的GC策略,調(diào)整JVM、GC的參數(shù)，可以極大的減少由于GC工作，而導(dǎo)致的程序運行中斷方面的問題，進而適當?shù)奶岣逬ava程序的工作效率。但是調(diào)整GC是以個極為復(fù)雜的過程，由于各個程序具備不同的特點，如：web和GUI程序就有很大區(qū)別（Web可以適當?shù)耐ｎD，但GUI停頓是客戶無法接受的），而且由于跑在各個機器上的配置不同（主要cup個數(shù)，內(nèi)存不同），所以使用的GC種類也會不同(如何選擇見GC種類及如何選擇)。本文將注重介紹JVM、GC的一些重要參數(shù)的設(shè)置來提高系統(tǒng)的性能。  JVM內(nèi)存組成及GC相關(guān)內(nèi)容請見之前的文章:JVM內(nèi)存組成 GC策略&內(nèi)存申請。JVM參數(shù)的含義實例見實例分析如下：

　　并行收集器相關(guān)參數(shù)：

　　CMS相關(guān)參數(shù)：

　　輔助信息：

　　3.1 GC性能方面的考慮

對于GC的性能主要有2個方面的指標：吞吐量throughput（工作時間不算gc的時間占總的時間比）和暫停pause（gc發(fā)生時app對外顯示的無法響應(yīng)）。

1、Total Heap，默認情況下，vm會增加/減少heap大小以維持free space在整個vm中占的比例，這個比例由MinHeapFreeRatio和MaxHeapFreeRatio指定。一般而言，server端的app會有以下規(guī)則：對vm分配盡可能多的memory；將Xms和Xmx設(shè)為一樣的值。如果虛擬機啟動時設(shè)置使用的內(nèi)存比較小，這個時候又需要初始化很多對象，虛擬機就必須重復(fù)地增加內(nèi)存。處理器核數(shù)增加，內(nèi)存也跟著增大。

2、The Young Generation，另外一個對于app流暢性運行影響的因素是young generation的大小。younggeneration越大，minor collection越少；但是在固定heap size情況下，更大的young generation就意味著小的tenured generation，就意味著更多的major collection(major collection會引發(fā)minor collection)。NewRatio反映的是young和tenured generation的大小比例。NewSize和MaxNewSize反映的是young generation大小的下限和上限，將這兩個值設(shè)為一樣就固定了young generation的大?。ㄍ琗ms和Xmx設(shè)為一樣）。如果希望，SurvivorRatio也可以優(yōu)化survivor的大小，不過這對于性能的影響不是很大。SurvivorRatio是eden和survior大小比例。一般而言，server端的app會有以下規(guī)則：首先決定能分配給vm的最大的heap size，然后設(shè)定最佳的young generation的大小；如果heap size固定后，增加young generation的大小意味著減小tenured generation大小。讓tenured generation在任何時候夠大，能夠容納所有l(wèi)ive的data（留10%-20%的空余）。

　　3.2 經(jīng)驗&規(guī)則

　　1、年輕代大小選擇：響應(yīng)時間優(yōu)先的應(yīng)用:盡可能設(shè)大,直到接近系統(tǒng)的最低響應(yīng)時間限制(根據(jù)實際情況選擇).在此種情況下,年輕代收集發(fā)生的頻率也是最小的.同時,減少到達年老代的對象；吞吐量優(yōu)先的應(yīng)用:盡可能的設(shè)置大,可能到達Gbit的程度.因為對響應(yīng)時間沒有要求,垃圾收集可以并行進行,一般適合8CPU以上的應(yīng)用；避免設(shè)置過小.當新生代設(shè)置過小時會導(dǎo)致:1.YGC次數(shù)更加頻繁 2.可能導(dǎo)致YGC對象直接進入舊生代,如果此時舊生代滿了,會觸發(fā)FGC.

　　2、年老代大小選擇：響應(yīng)時間優(yōu)先的應(yīng)用:年老代使用并發(fā)收集器,所以其大小需要小心設(shè)置,一般要考慮并發(fā)會話率和會話持續(xù)時間等一些參數(shù).如果堆設(shè)置小了,可以會造成內(nèi)存碎 片,高回收頻率以及應(yīng)用暫停而使用傳統(tǒng)的標記清除方式;如果堆大了,則需要較長的收集時間.最優(yōu)化的方案,一般需要參考以下數(shù)據(jù)獲得，并發(fā)垃圾收集信息、持久代并發(fā)收集次數(shù)、傳統(tǒng)GC信息、花在年輕代和年老代回收上的時間比例。吞吐量優(yōu)先的應(yīng)用:一般吞吐量優(yōu)先的應(yīng)用都有一個很大的年輕代和一個較小的年老代.原因是,這樣可以盡可能回收掉大部分短期對象,減少中期的對象,而年老代盡存放長期存活對象。

　　3、較小堆引起的碎片問題：因為年老代的并發(fā)收集器使用標記,清除算法,所以不會對堆進行壓縮.當收集器回收時,他會把相鄰的空間進行合并,這樣可以分配給較大的對象.但是,當堆空間較小時,運行一段時間以后,就會出現(xiàn)"碎片",如果并發(fā)收集器找不到足夠的空間,那么并發(fā)收集器將會停止,然后使用傳統(tǒng)的標記,清除方式進行回收.如果出現(xiàn)"碎片",可能需要進行如下配置:-XX:+UseCMSCompactAtFullCollection:使用并發(fā)收集器時,開啟對年老代的壓縮；-XX:CMSFullGCsBeforeCompaction=0:上面配置開啟的情況下,這里設(shè)置多少次Full GC后,對年老代進行壓縮。

4、使用CMS的好處是用盡量少的新生代，經(jīng)驗值是128M－256M， 然后老生代利用CMS并行收集， 這樣能保證系統(tǒng)低延遲的吞吐效率。實際上cms的收集停頓時間非常的短，2G的內(nèi)存， 大約20－80ms的應(yīng)用程序停頓時間

5、系統(tǒng)停頓的時候可能是GC的問題也可能是程序的問題，多用jmap和jstack查看，或者killall -3 java，然后查看java控制臺日志，能看出很多問題。(相關(guān)工具的使用方法將在后面的blog中介紹)。

6、仔細了解自己的應(yīng)用，如果用了緩存，那么年老代應(yīng)該大一些，緩存的HashMap不應(yīng)該無限制長，建議采用LRU算法的Map做緩存，LRUMap的最大長度也要根據(jù)實際情況設(shè)定。

7、采用并發(fā)回收時，年輕代小一點，年老代要大，因為年老大用的是并發(fā)回收，即使時間長點也不會影響其他程序繼續(xù)運行，網(wǎng)站不會停頓。

8、JVM參數(shù)的設(shè)置(特別是 –Xmx –Xms –Xmn-XX:SurvivorRatio -XX:MaxTenuringThreshold等參數(shù)的設(shè)置沒有一個固定的公式，需要根據(jù)PV old區(qū)實際數(shù)據(jù) YGC次數(shù)等多方面來衡量。為了避免promotion faild可能會導(dǎo)致xmn設(shè)置偏小，也意味著YGC的次數(shù)會增多，處理并發(fā)訪問的能力下降等問題。每個參數(shù)的調(diào)整都需要經(jīng)過詳細的性能測試，才能找到特定應(yīng)用的最佳配置。

　　3.3 PromotionFailed:

垃圾回收時promotionfailed是個很頭痛的問題，一般可能是兩種原因產(chǎn)生，第一個原因是救助空間不夠，救助空間里的對象還不應(yīng)該被移動到年老代，但年輕代又有很多對象需要放入救助空間；第二個原因是年老代沒有足夠的空間接納來自年輕代的對象；這兩種情況都會轉(zhuǎn)向Full GC，網(wǎng)站停頓時間較長。

　　解決方方案一：

第一個原因我的最終解決辦法是去掉救助空間，設(shè)置-XX:SurvivorRatio=65536 -XX:MaxTenuringThreshold=0即可，第二個原因我的解決辦法是設(shè)置CMSInitiatingOccupancyFraction為某個值（假設(shè)70），這樣年老代空間到70%時就開始執(zhí)行CMS，年老代有足夠的空間接納來自年輕代的對象。

　　解決方案一的改進方案：

又有改進了，上面方法不太好，因為沒有用到救助空間，所以年老代容易滿，CMS執(zhí)行會比較頻繁。我改善了一下，還是用救助空間，但是把救助空間加大，這樣也不會有promotion failed。具體操作上，32位Linux和64位Linux好像不一樣，64位系統(tǒng)似乎只要配置MaxTenuringThreshold參數(shù)，CMS還是有暫停。為了解決暫停問題和promotion failed問題，最后我設(shè)置-XX:SurvivorRatio=1 ，并把MaxTenuringThreshold去掉，這樣即沒有暫停又不會有promotoin failed，而且更重要的是，年老代和永久代上升非常慢（因為好多對象到不了年老代就被回收了），所以CMS執(zhí)行頻率非常低，好幾個小時才執(zhí)行一次，這樣，服務(wù)器都不用重啟了。

-Xmx4000M -Xms4000M -Xmn600M-XX:PermSize=500M -XX:MaxPermSize=500M -Xss256K -XX:+DisableExplicitGC-XX:SurvivorRatio=1 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC-XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0-XX:+CMSClassUnloadingEnabled -XX:LargePageSizeInBytes=128M-XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly-XX:CMSInitiatingOccupancyFraction=80 -XX:SoftRefLRUPolicyMSPerMB=0-XX:+PrintClassHistogram -XX:+PrintGCDetails -XX:+PrintGCTimeStamps-XX:+PrintHeapAtGC -Xloggc:log/gc.log

　　3.4 CMSInitiatingOccupancyFraction值與Xmn的關(guān)系公式

上面介紹了promontionfaild產(chǎn)生的原因是EDEN空間不足的情況下將EDEN與From survivor中的存活對象存入To survivor區(qū)時,To survivor區(qū)的空間不足，再次晉升到old gen區(qū)，而old gen區(qū)內(nèi)存也不夠的情況下產(chǎn)生了promontion faild從而導(dǎo)致full gc.那可以推斷出：eden+from survivor < old gen區(qū)剩余內(nèi)存時，不會出現(xiàn)promontion faild的情況，即：

(Xmx-Xmn)*(1-CMSInitiatingOccupancyFraction/100)>=(Xmn-Xmn/(SurvivorRatior+2))  進而推斷出：CMSInitiatingOccupancyFraction<=((Xmx-Xmn)-(Xmn-Xmn/(SurvivorRatior+2)))/(Xmx-Xmn)*100

例如：當xmx=128 xmn=36SurvivorRatior=1時CMSInitiatingOccupancyFraction<=((128.0-36)-(36-36/(1+2)))/(128-36)*100=73.913;

當xmx=128 xmn=24SurvivorRatior=1時CMSInitiatingOccupancyFraction<=((128.0-24)-(24-24/(1+2)))/(128-24)*100=84.615…

當xmx=3000 xmn=600SurvivorRatior=1時 CMSInitiatingOccupancyFraction<=((3000.0-600)-(600-600/(1+2)))/(3000-600)*100=83.33

CMSInitiatingOccupancyFraction低于70% 需要調(diào)整xmn或SurvivorRatior值。

以上是“JVM常用內(nèi)存參數(shù)配置有哪些”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對大家有所幫助，如果還想學習更多知識，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道！

分享標題：JVM常用內(nèi)存參數(shù)配置有哪些
URL標題：http://bm7419.com/article32/pcippc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供全網(wǎng)營銷推廣、品牌網(wǎng)站建設(shè)、做網(wǎng)站、云服務(wù)器、營銷型網(wǎng)站建設(shè)、服務(wù)器托管

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)