前言

今天就來介紹一下從小白到大神的跌宛，JVM不得不知道的一些參數(shù)配置

JVM 參數(shù)詳解

通用 JVM 參數(shù)

-server

如果不配置該參數(shù)预愤，JVM 會根據(jù)應(yīng)用服務(wù)器硬件配置自動選擇不同模式角虫，server 模式啟動比較慢淋叶，但是運行期 速度得到了優(yōu)化躏仇，適合于服務(wù)器端運行的 JVM牙躺。

-client

啟動比較快书聚，但是運行期響應(yīng)沒有 server 模式的優(yōu)化唧领，適合于個人 PC 的服務(wù)開發(fā)和測試。

-Xmx

設(shè)置 java heap 的最大值雌续，默認是機器物理內(nèi)存的 1/4斩个。這個值決定了最多可用的 Java 堆內(nèi)存：分配過少就會在 應(yīng)用中需要大量內(nèi)存作緩存或者臨時對象時出現(xiàn) OOM（Out Of Memory）的問題；如果分配過大驯杜，那么就會因 PermSize 過小而引起的另外一種 Out Of Memory受啥。所以如何配置還是根據(jù)運行過程中的分析和計算來確定，如果不 能確定還是采用默認的配置鸽心。

-Xms

設(shè)置 Java 堆初始化時的大小滚局，默認情況是機器物理內(nèi)存的 1/64。這個主要是根據(jù)應(yīng)用啟動時消耗的資源決定顽频，分配少了申請起來會降低運行速度藤肢，分配多了也浪費。

-XX:PermSize

初始化永久內(nèi)存區(qū)域大小糯景。永久內(nèi)存區(qū)域全稱是 Permanent Generation space嘁圈，是指內(nèi)存的永久保存區(qū)域，程序 運行期不對 PermGen space 進行清理蟀淮，所以如果你的 APP 會 LOAD 很多 CLASS 的話,就很可能出現(xiàn) PermGen space 錯誤最住。這種錯誤常見在 web 服務(wù)器對 JSP 進行 pre compile 的時候。如果你的 WEB APP 下用了大量的第三方 jar怠惶，其大小超過了 jvm 默認的 PermSize 大小(4M)那么就會產(chǎn)生此錯誤信息了温学。

-XX:MaxPermSize

設(shè)置永久內(nèi)存區(qū)域最大大小。

-Xmn

直接設(shè)置青年代大小甚疟。整個 JVM 可用內(nèi)存大小=青年代大小 + 老年代大小 + 持久代大小 仗岖。持久代一般固定 大小為 64m，所以增大年輕代后览妖，將會減小老年代大小轧拄。此值對系統(tǒng)性能影響較大，Sun 官方推薦配置為整個堆的 3/8讽膏。
按照 Sun 的官方設(shè)置比例檩电，則上面的例子中年輕代的大小應(yīng)該為 2048*3/8=768M。

-XX:NewRatio

控制默認的 Young 代的大小，例如俐末，設(shè)置-XX:NewRatio=3 意味著 Young 代和老年代的比率是 1:3料按。換句話說， Eden 和 Survivor 空間總和是整個堆大小的 1/4卓箫。

如圖中的實際設(shè)置载矿，-XX:NewRatio=2，-Xmx=2048烹卒，則年輕代和老年代的分配比例為 1:2闷盔，即年輕代的大小為 682M， 而老年代的大小為 1365M旅急。查看實際系統(tǒng)的 jvm 監(jiān)控結(jié)果為：

內(nèi)存池名稱: Tenured Gen
Java 虛擬機最初向操作系統(tǒng)請求的內(nèi)存量: 3,538,944 字節(jié)
Java 虛擬機實際能從操作系統(tǒng)獲得的內(nèi)存量: 1,431,699,456 字節(jié)
Java 虛擬機可從操作系統(tǒng)獲得的最大內(nèi)存量: 1,431,699,456 字節(jié)逢勾。請注意，并不一定能獲得該內(nèi)存量藐吮。
Java 虛擬機此時使用的內(nèi)存量: 1,408,650,472 字節(jié)
即：1,408,650,472 字節(jié)=1365M溺拱，證明了上面的計算是正確的。

-XX:SurvivorRatio

設(shè)置年輕代中 Eden 區(qū)域 Survivor 區(qū)的大小比值谣辞。設(shè)置為 4迫摔，則兩個 Survivor 區(qū)域一個 Eden 區(qū)的比值為 2:4， 一個 Survivor 區(qū)占整個年輕代的 1/6潦闲。越大的 survivor 空間可以允許短期對象盡量在年青代消亡攒菠；如果 Survivor 空 間太小迫皱，Copying 收集將直接將其轉(zhuǎn)移到老年代中歉闰，這將加快老年代的空間使用速度，引發(fā)頻繁的完全垃圾回收卓起。

SurvivorRatio 的值設(shè)為 3和敬，Xmn 為 768M，則每個 Survivor 空間的大小為 768M/5=153.6M戏阅。

-XX:NewSize

為了實現(xiàn)更好的性能昼弟，您應(yīng)該對包含短期存活對象的池的大小進行設(shè)置，以使該池中的對象的存活時間不會超過一個垃圾回收循環(huán)奕筐。新生成的池的大小由 NewSize 和 MaxNewSize 參數(shù)確定舱痘。通過這個選項可以設(shè)置 Java 新對象生產(chǎn)堆內(nèi)存。在通常情況下這個選項的數(shù)值為 1024 的整數(shù)倍并且大于 1MB离赫。這個值的取值規(guī)則為芭逝，一般情況下這個值-XX:NewSize 是最大堆內(nèi)存（maximum heap size）的四分之一。增加這個選項值的大小是為了增大較大數(shù)量的短生命周期對象渊胸。增加 Java 新對象生產(chǎn)堆內(nèi)存相當于增加了處理器的數(shù)目旬盯。并且可以并行地分配內(nèi)存，但是請注意內(nèi)存的垃圾回收卻是不可以并行處理的。作用跟-XX:NewRatio 相似胖翰，-XX:NewRatio 是設(shè)置比例而-XX:NewSize 是設(shè)置精確的數(shù)值接剩。

-XX:MaxNewSize

通過這個選項可以設(shè)置最大 Java 新對象生產(chǎn)堆內(nèi)存。通常情況下這個選項的數(shù)值為 1024 的整數(shù)倍并且大于 1MB萨咳，其功用與上面的設(shè)置新對象生產(chǎn)堆內(nèi)存-XX:NewSize 相同懊缺。一般要將 NewSize 和 MaxNewSize 設(shè)成一致。

-XX:MaxTenuringThreshold

設(shè)置垃圾最大年齡某弦。如果設(shè)置為 0 的話桐汤，則年輕代對象不經(jīng)過 Survivor 區(qū)，直接進入老年代靶壮。對于老年代比較多的應(yīng)用怔毛，可以提高效率。如果將此值設(shè)置為一個較大值腾降，則年輕代對象會在 Survivor 區(qū)進行多次復(fù)制拣度，這樣可以增加對象在年輕代的存活時間，增加在年輕代即被回收的概率螃壤。

-XX:MaxTenuringThreshold 參數(shù)被設(shè)置成 5抗果，表示對象會在 Survivor 區(qū)進行 5 次復(fù)制后如果還沒有被回收才會 被復(fù)制到老年代。

-XX:GCTimeRatio

設(shè)置垃圾回收時間占程序運行時間的百分比奸晴。該參數(shù)設(shè)置為 n 的話冤馏，則垃圾回收時間占程序運行時間百分比的公式為 1/(1+n) ，如果 n=19 表示 java 可以用 5%的時間來做垃圾回收寄啼，1/(1+19)=1/20=5%逮光。

-XX:TargetsurvivorRatio

該值是一個百分比，控制允許使用的救助空間的比例墩划，默認值是 50涕刚。該參數(shù)設(shè)置較大的話可提高對 survivor 空間的使用率。當較大的堆棧使用較低的 SurvivorRatio 時乙帮，應(yīng)增加該值到 80 至 90杜漠，以更好利用救助空間。

-Xss

設(shè)置每個線程的堆棧大小察净，根據(jù)應(yīng)用的線程所需內(nèi)存大小進行調(diào)整驾茴，在相同物理內(nèi)存下，減小這個值能生成更 多的線程氢卡。
但是操作系統(tǒng)對一個進程內(nèi)的線程數(shù)還是有限制的锈至，不能無限生成，經(jīng)驗值在 3000~5000 左右异吻。當這個選項被設(shè)置的較大（>2MB）時將會在很大程度上降低系統(tǒng)的性能裹赴。因此在設(shè)置這個值時應(yīng)該格外小心喜庞，調(diào)整后要注意觀察系統(tǒng)的性能，不斷調(diào)整以期達到最優(yōu)棋返。
JDK5.0 以后每個線程堆棧大小為 1M延都，以前每個線程堆棧大小為 256K。

-Xnoclassgc

這個選項用來取消系統(tǒng)對特定類的垃圾回收睛竣。它可以防止當這個類的所有引用丟失之后晰房，這個類仍被引用時不會再一次被重新裝載，因此這個選項將增大系統(tǒng)堆內(nèi)存的空間射沟。禁用類垃圾回收殊者，性能會高一點；

串行收集器參數(shù)

-XX:+UseSerialGC

設(shè)置串行收集器 验夯。

并行收集器參數(shù)

-XX:+UseParallelGC

選擇垃圾收集器為并行收集器猖吴，此配置僅對年輕代有效，即上述配置下挥转，年輕代使用并行收集海蔽，而老年代仍舊使用串行收集。采用了多線程并行管理和回收垃圾對象绑谣，提高了回收效率党窜，提高了服務(wù)器的吞吐量，適合于多處理器的服務(wù)器借宵。

-XX:ParallelGCThreads

配置并行收集器的線程數(shù)幌衣，即：同時多少個線程一起進行垃圾回收。此值最好配置與處理器數(shù)目相等壤玫。

-XX:+UseParallelOldGC

采用對于老年代并發(fā)收集的策略豁护，可以提高收集效率。JDK6.0 支持對老年代并行收集垦细。

-XX:MaxGCPauseMillis

設(shè)置每次年輕代并行收集最大暫停時間择镇，如果無法滿足此時間挡逼，JVM 會自動調(diào)整年輕代大小以滿足此值括改。

-XX:+UseAdaptiveSizePolicy

設(shè)置此選項后，并行收集器會自動選擇年輕代區(qū)大小和相應(yīng)的 Survivor 區(qū)比例家坎，以達到目標系統(tǒng)規(guī)定的最低響 應(yīng)時間或者收集頻率等嘱能，此值建議使用并行收集器時，一直打開虱疏。

并發(fā)收集器參數(shù)

-XX:+UseConcMarkSweepGC

指定在 老年代 使用 concurrent cmark sweep gc惹骂。gc thread 和 app thread 并行 ( 在 init-mark 和 remark 時 pause app thread)。app pause 時間較短 , 適合交互性強的系統(tǒng) , 如 web server做瞪。它可以并發(fā)執(zhí)行收集操作对粪，降低應(yīng)用停止時間右冻，同時它也是并行處理模式，可以有效地利用多處理器的系統(tǒng)的多進程處理著拭。

-XX:+UseParNewGC

指定在 New Generation 使用 parallel collector, 是 UseParallelGC 的 gc 的升級版本 , 有更好的性能或者優(yōu)點 , 可以和 CMS gc 一起使用

-XX:+UseCMSCompactAtFullCollection

打開對老年代的壓縮纱扭。可能會影響性能儡遮，但是可以消除碎片,在 FULL GC 的時候乳蛾，壓縮內(nèi)存，CMS 是不會移動內(nèi)存的鄙币，因此肃叶，這個非常容易產(chǎn)生碎片，導(dǎo)致內(nèi)存不夠用十嘿，因此因惭，內(nèi)存的壓縮這個時候就會被啟用。增加這個參數(shù)是個好習(xí)慣绩衷。

-XX:+CMSIncrementalMode

設(shè)置為增量模式筛欢。適用于單 CPU 情況

-XX:CMSFullGCsBeforeCompaction

由于并發(fā)收集器不對內(nèi)存空間進行壓縮、整理唇聘，所以運行一段時間以后會產(chǎn)生“碎片”版姑，使得運行效率降低。此值設(shè)置運行多少次 GC 以后對內(nèi)存空間進行壓縮迟郎、整理剥险。

-XX:+CMSClassUnloadingEnabled

使 CMS 收集持久代的類，而不是 fullgc

-XX:+CMSPermGenSweepingEnabled

使 CMS 收集持久代的類宪肖，而不是 fullgc表制。

-XX:-CMSParallelRemarkEnabled

在使用 UseParNewGC 的情況下 , 盡量減少 mark 的時間

-XX:CMSInitiatingOccupancyFraction

說明老年代到百分之多少滿的時候開始執(zhí)行對老年代的并發(fā)垃圾回收（CMS），這個參數(shù)設(shè)置有很大技巧控乾，基本上滿足公式：

時就不會出現(xiàn) promotion failed么介。在我的應(yīng)用中 Xmx 是 6000，Xmn 是 500蜕衡，那么 Xmx-Xmn 是 5500 兆壤短，也就是老年代有 5500 兆，CMSInitiatingOccupancyFraction=90 說明老年代到 90%滿的時候開始執(zhí)行對老年代的并發(fā)垃圾回 收（CMS）慨仿，這時還剩 10%的空間是 兆久脯，所以即使 Xmn（也就是年輕代共 500 兆）里所有對象都搬到老年代里，550 兆的空間也足夠了镰吆，所以只要滿足上面的公式帘撰，就不會出現(xiàn)垃圾回收時的 promotion failed；

如果按照 Xmx=2048,Xmn=768 的比例計算万皿，則 CMSInitiatingOccupancyFraction 的值不能超過 40摧找，否則就容易 出現(xiàn)垃圾回收時的 promotion failed核行。

-XX:+UseCMSInitiatingOccupancyOnly

指示只有在老年代在使用了初始化的比例后 concurrent collector 啟動收集

-XX:SoftRefLRUPolicyMSPerMB

相對于客戶端模式的虛擬機（-client 選項），當使用服務(wù)器模式的虛擬機時（-server 選項）蹬耘，對于軟引用（soft reference）的清理力度要稍微差一些钮科。可以通過增大-XX:SoftRefLRUPolicyMSPerMB 來降低收集頻率婆赠。默認值是 1000绵脯，也就是說每秒一兆字節(jié)。Soft reference 在虛擬機中比在客戶集中存活的更長一些休里。其清除頻率可以用命令行 參數(shù) -XX:SoftRefLRUPolicyMSPerMB= 來控制蛆挫，這可以指定每兆堆空閑空間的 soft reference 保持存活（一旦 它不強可達了）的毫秒數(shù)，這意味著每兆堆中的空閑空間中的 soft reference 會（在最后一個強引用被回收之后） 存活 1 秒鐘妙黍。注意悴侵，這是一個近似的值，因為 soft reference 只會在垃圾回收時才會被清除拭嫁，而垃圾回收并不總在 發(fā)生可免。

-XX:LargePageSizeInBytes

內(nèi)存頁的大小，不可設(shè)置過大做粤，會影響 Perm 的大小浇借。

-XX:+UseFastAccessorMethods

原始類型的快速優(yōu)化，get,set 方法轉(zhuǎn)成本地代碼怕品。

-XX:+DisableExplicitGC

禁止 java 程序中的 full gc, 如 System.gc() 的調(diào)用妇垢。最好加上防止程序在代碼里誤用了，對性能造成沖擊肉康。

-XX:+AggressiveHeap

特別說明下：(我感覺對于做 java cache 應(yīng)用有幫助)
試圖是使用大量的物理內(nèi)存
長時間大內(nèi)存使用的優(yōu)化闯估，能檢查計算資源（內(nèi)存，處理器數(shù)量）
至少需要 256MB 內(nèi)存大量的 CPU／內(nèi)存吼和， （在 1.4.1 在 4CPU 的機器上已經(jīng)顯示有提升）

-XX:+AggressiveOpts

加快編譯

-XX:+UseBiasedLocking

鎖機制的性能改善

感謝諸君的觀看涨薪，文中如有紕漏，歡迎在評論區(qū)來交流炫乓。如果這篇文章幫助到了你刚夺，歡迎點贊??關(guān)注。