2019獨角獸企業(yè)重金招聘Python工程師標準>>>

堆配置

-Xms:初始堆大小 -Xms：最大堆大小 -XX:NewSize=n:設(shè)置年輕代大小 -XX:NewRatio=n:設(shè)置年輕代和年老代的比值。如：為3表示年輕代和年老代比值為1：3，年輕代占整個年輕代年老代和的1/4 -XX:SurvivorRatio=n:年輕代中Eden區(qū)與兩個Survivor區(qū)的比值。注意Survivor區(qū)有兩個。如3表示Eden： 3 Survivor：2，一個Survivor區(qū)占整個年輕代的1/5 -XX:MaxPermSize=n:設(shè)置持久代大小

說明：
1、一般初始堆和最大堆設(shè)置一樣，因為：現(xiàn)在內(nèi)存不是什么稀缺的資源，但是如果不一樣，從初始堆到最大堆的過程會有一定的性能開銷，所以一般設(shè)置為初始堆和最大堆一樣。64位系統(tǒng)理論上可以設(shè)置為無限大，但是一般設(shè)置為4G,因為如果再大，JVM進行垃圾回收出現(xiàn)的暫停時間會比較長，這樣全GC過長，影響JVM對外提供服務(wù)，所以不能太大。一般設(shè)置為4G。
2、-XX:NewRaio和-XX:SurvivorRatio這兩個參數(shù)，都是設(shè)置年輕代和年老代的大小的，設(shè)置一個即可，第一是設(shè)置年輕代的大小，第二個是設(shè)置比值，理論上設(shè)置一個既可以滿足需求

收集器設(shè)置：

-XX:+UseSerialGC:設(shè)置串行收集器-XX:+UseParallelGC:設(shè)置并行收集器-XX:+UseParalledlOldGC:設(shè)置并行年老代收集器-XX:+UseConcMarkSweepGC:設(shè)置并發(fā)收集器

垃圾回收統(tǒng)計信息

打印GC回收的過程日志信息

-XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:filename

并行收集器設(shè)置

-XX:ParallelGCThreads=n:設(shè)置并行收集器收集時使用的CPU數(shù)。并行收集線程數(shù) -XX:MaxGCPauseMillis=n:設(shè)置并行收集最大的暫停時間（如果到這個時間了，垃圾回收器依然沒有回收完，也會停止回收） -XX:GCTimeRatio=n:設(shè)置垃圾回收時間占程序運行時間的百分比。公式為：1/(1+n) -XX:+CMSIncrementalMode:設(shè)置為增量模式。適用于單CPU情況 -XX:ParallelGCThreads=n:設(shè)置并發(fā)收集器年輕代手機方式為并行收集時，使用的CPU數(shù)。并行收集線程數(shù)

典型配置舉例

以下配置主要針對分代收集回收算法而言

堆大小設(shè)置

年輕代的設(shè)置很關(guān)鍵
JVM中最大堆大小有三方面限制：相關(guān)操作系統(tǒng)的數(shù)據(jù)模型(32bit還是64bit)限制：系統(tǒng)的可用虛擬內(nèi)存限制；系統(tǒng)的可用物理內(nèi)存限制。32位系統(tǒng)下，一般限制在1.5G-2G;64位操作系統(tǒng)對內(nèi)存沒有限制。在Windows Server 2003系統(tǒng)，3.5G物理內(nèi)存，JDK5.0下測試，最大設(shè)置為1478m。

典型設(shè)置：

java-Xmx3550m -Xms3550m-Xmn2g -Xss128k -Xmx3550m:設(shè)置JVM最大可用內(nèi)存為3550m -Xms3550m:設(shè)置JVM初始內(nèi)存為3550m，此值可以設(shè)置-Xmx相同，以避免每次垃圾回收完成以后JVM重新分配內(nèi)存 -Xmn2g:設(shè)置年輕代大小為2G。整個堆大小=年輕代大小+年老代大小+持久代大小。持久代一般固定為64M,所以增大年輕代后，將會減少年老代大小，此值對系統(tǒng)性能影響比較大，Sun官方推薦配置為整個堆的3/8 -Xss128k:設(shè)置每個線程的堆棧大小。JDK5.0以后每個線程棧大小為1M，以前每個線程堆棧大小為256k。根據(jù)應(yīng)用的線程所需要內(nèi)存大小進行調(diào)整。在相同物理內(nèi)存下，減少這個值能夠生成更多的線程。但是操作系統(tǒng)對一個進程內(nèi)的線程還是有限制的，不能無限生成，經(jīng)驗值在3000-5000左右。 java -Xmx3550m-Xms3550m-Xss128k-XX:NewRatio=4-XX:SurvivorRatio=4 -XX:MaxPermSize=16m-XX:MaxTenuringThreshold=0-XX:NewRatio=4:設(shè)置年輕代（包括Eden和兩個Survivor區(qū)）與年老代的比值（除去持久代）。設(shè)置為4，則年輕代和年老代所占比值為1：4，年輕代占整個堆棧的1/5 -XX:SurvivorRatio=4:設(shè)置年輕代中Eden區(qū)與Survivor區(qū)的大小比值。設(shè)置為4，則兩個Survivor區(qū)與一個Eden區(qū)的比值為2:4,一個Survivor區(qū)占整個年輕代的1/6 -XX:MaxPermSize=16m:設(shè)置持久代大小為16m -XX：MaxTenuringThreshold=0：設(shè)置垃圾最大年齡。如果設(shè)置為0，則年輕代對象不經(jīng)過Survivor區(qū)，直接進入年老代。對于年老代比較多的應(yīng)用，提高效率，如果將此值設(shè)置為一個較大值，則年輕代對象會在Survivor區(qū)進行多次復(fù)制，這樣可以增加對象在年輕代的存活時間。

回收器的選擇

JVM給了三種選擇：串行收集器，并行收集器，并發(fā)收集器，但是串行收集器只適用于小數(shù)據(jù)量的情況，一般不考慮使用了，所以這里只針對并行收集器和并發(fā)收集器。默認情況下，JDK5.0以前是使用的串行收集器，如果想使用其他收集器需要在啟動時加入相應(yīng)的參數(shù)，JDK5.0以后，JVM會根據(jù)系統(tǒng)當前的配置進行判斷

吞吐量優(yōu)先的并行收集器
并行收集器主要以到達一定的吞吐量為目標，適用于后臺處理

java -Xmx3550m-Xms3550m-Xss128k-XX:+UseParallelGC -XX:ParallelGCThreads=20 -XX:+UseParallelGC:選擇垃圾收集器為并行收集器。次配置僅對年輕代有效。即上述配置下，年輕代使用并行收集，而年老代仍舊使用串行收集。 -XX：PARALLELgcThreads=20:配置并行收集器的線程數(shù)，即：同時多少個線程一起進行垃圾回收。此值最好配置與處理器數(shù)目相同。 -XX:+UseParallelOldGC:配置年老代來及收集方式為并行收集，JDK6.0支持對年老代并行收集 -XX:MaxGCPauseMillis=100:設(shè)置每次年輕代垃圾回收的最長時間，如果無法滿足此時間，JVM會自動調(diào)整年輕代大小，以滿足此值 -XX:+UseAdaptiveSizePolicy:設(shè)置此選項以后，并行收集器會自動選擇年輕代區(qū)大小和相應(yīng)的Survivor區(qū)比例，以達到目標系統(tǒng)規(guī)定的最低響應(yīng)時間或者收集頻率等，此值建議使用并行收集器時，一直打開

響應(yīng)時間優(yōu)先的并發(fā)收集器
并發(fā)收集器主要是保證系統(tǒng)的響應(yīng)時間，減少垃圾收集時的停頓時間。適用于應(yīng)用服務(wù)器、電信領(lǐng)域等。

-XX:CMSFullGCsBeforeCompaction=5 -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction:由于并發(fā)收集器不對內(nèi)存空間進行壓縮、整理、所以運行一段時間以后會產(chǎn)生“碎片”，使得運行效率降低。此值設(shè)置運行多少次GC以后對內(nèi)存空間進行壓縮、整理 -XX:+UseCMSCompactAtFullCollection：打開對年老代的壓縮?？赡軙绊懶阅?#xff0c;但是可以消除碎片

調(diào)優(yōu)總結(jié)：

年輕代大小選擇
響應(yīng)時間優(yōu)先的應(yīng)用：盡可能設(shè)置大，直到接近系統(tǒng)的最低響應(yīng)時間限制（根據(jù)實際情況選擇）。在此種情況下，年輕代收集發(fā)生的頻率也是最小的。同時減少到達年老代的對象。
吞吐量優(yōu)先的應(yīng)用：盡可能的設(shè)置大，可能到達Gbit的成都，因為對響應(yīng)時間沒有要求，垃圾收集可以并行進行，一般適合8核CPU以上應(yīng)用。

年老代大小選擇
響應(yīng)時間優(yōu)先的應(yīng)用：年老代使用并發(fā)收集器，所以其大小需要小心設(shè)置，一般要考慮并發(fā)會話率和會話持續(xù)時間等一些參數(shù)。如果堆設(shè)置小了，可能會造成內(nèi)存碎片、高回收頻率以及應(yīng)用暫停而使用傳統(tǒng)的標記清除方式；如果堆大了，則需要較長的收集時間。最優(yōu)化的方案，一般需要參考一下數(shù)據(jù)獲得：
1、并發(fā)垃圾收集信息
2、持久代并發(fā)收集次數(shù)
3、傳統(tǒng)GC信息
4、花在年輕代和年老代回收上的時間比例減少年輕代和年老代花費的時間，一般會提高應(yīng)用的效率

吞吐量優(yōu)先的應(yīng)用
一般吞吐量優(yōu)先的應(yīng)用都有一個很大的年輕代和一個較小的年老代。原因是，這樣可以盡可能回收掉大部分短期對象，減少中期對象，而年老代盡存放長期存活的對象

較小堆引起的碎片問題
因為年老代的并發(fā)收集器使用標記、清除算法，所以不會對堆進行壓縮。當收集器回收時，他會把相鄰的空間進行合并，這樣可以分配給較大的對象。但是當堆空間較小時，運行一段時間以后，就會出現(xiàn)“碎片”，如果并發(fā)收集器找不到足夠的空間，那么并發(fā)收集器將會停止，然后使用傳統(tǒng)的標記、清除方式進行回收。如果出現(xiàn)“碎片”，可能需要進行如下配置：

-XX:+UseCMSCompactAtFullCollection:使用并發(fā)收集器時，開啟對年老代的壓縮 -XX:CMSFullGCsBeforeCompaction=0:上面配置開啟的情況下，這里設(shè)置多少次FullGc后，對年老代進行壓縮

調(diào)優(yōu)方法

調(diào)優(yōu)工具

Jconsole,jProfile,VisualVM

Jconsole:jdk自帶， 功能簡單，但是可以再系統(tǒng)有一定負荷的情況下使用，對垃圾回收算法有很詳細的跟蹤。
JProfiler：商業(yè)軟件，需要付費，但是功能強大
VisualVM:JDK自帶，功能強大，與Jprofiler類似，推薦

如何調(diào)優(yōu)

觀察內(nèi)存釋放情況、集合類檢查，對象樹
上面這些調(diào)優(yōu)工具都提供了強大的功能，但是總的來說一般分為以下幾類功能：

1、堆的信息查看（年輕代、年老代、持久代分配）
2、提供即時的垃圾回收功能呢
3、垃圾監(jiān)控，長時間監(jiān)控

內(nèi)存泄露檢查

一般就是根據(jù)垃圾回收前后情況對比，同時根據(jù)對象引用情況（常見的集合對象引用）分析，基本都可以找到泄漏點。

持久代沾滿處理：
1、-XX:MaxPermSize=16m
2、換JDK比如：JRocket

系統(tǒng)內(nèi)存被沾滿：
一般是因為沒有足夠的資源產(chǎn)生線程造成的，系統(tǒng)創(chuàng)建線程時，除了要在Java堆中分配內(nèi)存外，操作系統(tǒng)本身也需要分配資源來創(chuàng)建線程。因此，當線程數(shù)量大的一定程度以后，堆中或許還有空間，但是操作系統(tǒng)分配不出資源來了，出現(xiàn)異常。
分配給Java虛擬機的內(nèi)存越多，系統(tǒng)剩余的資源就越少，因此，當系統(tǒng)內(nèi)存固定時，分配給Java虛擬機的內(nèi)存越多，那么，系統(tǒng)總共能夠產(chǎn)生的線程也就越少，兩者成反比。同事，可以通過修改-Xss來減少分配給單個線程的空間，也可以增加系統(tǒng)總共生產(chǎn)的線程數(shù)。

java程序內(nèi)存問題的診斷方法：

1、jstat可以查看垃圾回收情況：jstat -gcutil pid
2、jmap可以將java內(nèi)存dump出來
3、jstack -l 進程id
4、eclipse插件MAT可以有效的分析內(nèi)存占用情況

jmap -h

查看jmap的命令參數(shù)，幫助查看堆信息

轉(zhuǎn)載于:https://my.oschina.net/u/1458864/blog/2046311

《新程序員》：云原生和全面數(shù)字化實踐50位技術(shù)專家共同創(chuàng)作，文字、視頻、音頻交互閱讀

總結(jié)

以上是生活随笔為你收集整理的JVM调优常用参数配置的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。