jvm內存設置

JVM有不少個內存管理命令，整體而言，分爲兩類：

　　一、-X開頭的管理命令：這些選項在JDK升級時不會通知修改；

　　二、-XX開頭的管理命令：這些選項不夠穩定，因此建議少用。

JVM參數的含義：　　

參數名稱	含義	默認值
-Xms	初始堆大小	物理內存的1/64(<1GB)	默認(MinHeapFreeRatio參數能夠調整)空餘堆內存小於40%時，JVM就會增大堆直到-Xmx的最大限制.
-Xmx	最大堆大小	物理內存的1/4(<1GB)	默認(MaxHeapFreeRatio參數能夠調整)空餘堆內存大於70%時，JVM會減小堆直到 -Xms的最小限制
-Xmn	年輕代大小(1.4or lator)		注意：此處的大小是（eden+ 2 survivor space).與jmap -heap中顯示的New gen是不一樣的。 整個堆大小=年輕代大小 + 年老代大小 + 持久代大小. 增大年輕代後,將會減少年老代大小.此值對系統性能影響較大,Sun官方推薦配置爲整個堆的3/8
-XX:NewSize	設置年輕代大小(for 1.3/1.4)
-XX:MaxNewSize	年輕代最大值(for 1.3/1.4)
-XX:PermSize	設置持久代(perm gen)初始值	物理內存的1/64
-XX:MaxPermSize	設置持久代最大值	物理內存的1/4
-Xss	每一個線程的堆棧大小		JDK5.0之後每一個線程堆棧大小爲1M,之前每一個線程堆棧大小爲256K.更具應用的線程所需內存大小進行 調整.在相同物理內存下,減少這個值能生成更多的線程.可是操做系統對一個進程內的線程數仍是有限制的,不能無限生成,經驗值在3000~5000左右 通常小的應用， 若是棧不是很深， 應該是128k夠用的 大的應用建議使用256k。這個選項對性能影響比較大，須要嚴格的測試。（校長） 和threadstacksize選項解釋很相似,官方文檔彷佛沒有解釋,在論壇中有這樣一句話:"」 -Xss is translated in a VM flag named ThreadStackSize」 通常設置這個值就能夠了。
-XX:ThreadStackSize	Thread Stack Size		(0 means use default stack size) [Sparc: 512; Solaris x86: 320 (was 256 prior in 5.0 and earlier); Sparc 64 bit: 1024; Linux amd64: 1024 (was 0 in 5.0 and earlier); all others 0.]
-XX:NewRatio	年輕代(包括Eden和兩個Survivor區)與年老代的比值(除去持久代)		-XX:NewRatio=4表示年輕代與年老代所佔比值爲1:4,年輕代佔整個堆棧的1/5 Xms=Xmx而且設置了Xmn的狀況下，該參數不須要進行設置。
-XX:SurvivorRatio	Eden區與Survivor區的大小比值		設置爲8,則兩個Survivor區與一個Eden區的比值爲2:8,一個Survivor區佔整個年輕代的1/10
-XX:LargePageSizeInBytes	內存頁的大小不可設置過大， 會影響Perm的大小		=128m
-XX:+UseFastAccessorMethods	原始類型的快速優化
-XX:+DisableExplicitGC	關閉System.gc()		這個參數須要嚴格的測試
-XX:MaxTenuringThreshold	垃圾最大年齡		若是設置爲0的話,則年輕代對象不通過Survivor區,直接進入年老代. 對於年老代比較多的應用,能夠提升效率.若是將此值設置爲一個較大值,則年輕代對象會在Survivor區進行屢次複製,這樣能夠增長對象再年輕代的存活 時間,增長在年輕代即被回收的機率 該參數只有在串行GC時纔有效.
-XX:+AggressiveOpts	加快編譯
-XX:+UseBiasedLocking	鎖機制的性能改善
-Xnoclassgc	禁用垃圾回收
-XX:SoftRefLRUPolicyMSPerMB	每兆堆空閒空間中SoftReference的存活時間	1s	softly reachable objects will remain alive for some amount of time after the last time they were referenced. The default value is one second of lifetime per free megabyte in the heap
-XX:PretenureSizeThreshold	對象超過多大是直接在舊生代分配	0	單位字節 新生代採用Parallel Scavenge GC時無效 另外一種直接在舊生代分配的狀況是大的數組對象,且數組中無外部引用對象.
-XX:TLABWasteTargetPercent	TLAB佔eden區的百分比	1%
-XX:+CollectGen0First	FullGC時是否先YGC	false

並行收集器相關參數

-XX:+UseParallelGC	Full GC採用parallel MSC (此項待驗證)		選擇垃圾收集器爲並行收集器.此配置僅對年輕代有效.即上述配置下,年輕代使用併發收集,而年老代仍舊使用串行收集.(此項待驗證)
-XX:+UseParNewGC	設置年輕代爲並行收集		可與CMS收集同時使用 JDK5.0以上,JVM會根據系統配置自行設置,因此無需再設置此值
-XX:ParallelGCThreads	並行收集器的線程數		此值最好配置與處理器數目相等 一樣適用於CMS
-XX:+UseParallelOldGC	年老代垃圾收集方式爲並行收集(Parallel Compacting)		這個是JAVA 6出現的參數選項
-XX:MaxGCPauseMillis	每次年輕代垃圾回收的最長時間(最大暫停時間)		若是沒法知足此時間,JVM會自動調全年輕代大小,以知足此值.
-XX:+UseAdaptiveSizePolicy	自動選擇年輕代區大小和相應的Survivor區比例		設置此選項後,並行收集器會自動選擇年輕代區大小和相應的Survivor區比例,以達到目標系統規定的最低相應時間或者收集頻率等,此值建議使用並行收集器時,一直打開.
-XX:GCTimeRatio	設置垃圾回收時間佔程序運行時間的百分比		公式爲1/(1+n)
-XX:+ScavengeBeforeFullGC	Full GC前調用YGC	true	Do young generation GC prior to a full GC. (Introduced in 1.4.1.)

CMS相關參數

-XX:+UseConcMarkSweepGC	使用CMS內存收集		測試中配置這個之後,-XX:NewRatio=4的配置失效了,緣由不明.因此,此時年輕代大小最好用-Xmn設置.???
-XX:+AggressiveHeap			試圖是使用大量的物理內存 長時間大內存使用的優化，能檢查計算資源（內存， 處理器數量） 至少須要256MB內存 大量的CPU／內存， （在1.4.1在4CPU的機器上已經顯示有提高）
-XX:CMSFullGCsBeforeCompaction	多少次後進行內存壓縮		因爲併發收集器不對內存空間進行壓縮,整理,因此運行一段時間之後會產生"碎片",使得運行效率下降.此值設置運行多少次GC之後對內存空間進行壓縮,整理.
-XX:+CMSParallelRemarkEnabled	下降標記停頓
-XX+UseCMSCompactAtFullCollection	在FULL GC的時候， 對年老代的壓縮		CMS是不會移動內存的， 所以， 這個很是容易產生碎片， 致使內存不夠用， 所以， 內存的壓縮這個時候就會被啓用。 增長這個參數是個好習慣。 可能會影響性能,可是能夠消除碎片
-XX:+UseCMSInitiatingOccupancyOnly	使用手動定義初始化定義開始CMS收集		禁止hostspot自行觸發CMS GC
-XX:CMSInitiatingOccupancyFraction=70	使用cms做爲垃圾回收 使用70％後開始CMS收集	92	爲了保證不出現promotion failed(見下面介紹)錯誤,該值的設置須要知足如下公式CMSInitiatingOccupancyFraction計算公式
-XX:CMSInitiatingPermOccupancyFraction	設置Perm Gen使用到達多少比率時觸發	92
-XX:+CMSIncrementalMode	設置爲增量模式		用於單CPU狀況
-XX:+CMSClassUnloadingEnabled

輔助信息

 

-XX:+PrintGC			輸出形式: [GC 118250K->113543K(130112K), 0.0094143 secs] [Full GC 121376K->10414K(130112K), 0.0650971 secs]
-XX:+PrintGCDetails			輸出形式:[GC [DefNew: 8614K->781K(9088K), 0.0123035 secs] 118250K->113543K(130112K), 0.0124633 secs] [GC [DefNew: 8614K->8614K(9088K), 0.0000665 secs][Tenured: 112761K->10414K(121024K), 0.0433488 secs] 121376K->10414K(130112K), 0.0436268 secs]
-XX:+PrintGCTimeStamps
-XX:+PrintGC:PrintGCTimeStamps			可與-XX:+PrintGC -XX:+PrintGCDetails混合使用 輸出形式:11.851: [GC 98328K->93620K(130112K), 0.0082960 secs]
-XX:+PrintGCApplicationStoppedTime	打印垃圾回收期間程序暫停的時間.可與上面混合使用		輸出形式:Total time for which application threads were stopped: 0.0468229 seconds
-XX:+PrintGCApplicationConcurrentTime	打印每次垃圾回收前,程序未中斷的執行時間.可與上面混合使用		輸出形式:Application time: 0.5291524 seconds
-XX:+PrintHeapAtGC	打印GC先後的詳細堆棧信息
-Xloggc:filename	把相關日誌信息記錄到文件以便分析. 與上面幾個配合使用
-XX:+PrintClassHistogram	garbage collects before printing the histogram.
-XX:+PrintTLAB	查看TLAB空間的使用狀況
XX:+PrintTenuringDistribution	查看每次minor GC後新的存活週期的閾值		Desired survivor size 1048576 bytes, new threshold 7 (max 15) new threshold 7即標識新的存活週期的閾值爲7。

關於JVM的內存：

　　分爲三個域Generation：新域、舊域和持久域。

一、新域包括一個eden和兩個生存空間survivor，eden是用來存儲新建立的對象的，當eden存滿時，會將對象複製到from survivor中，當from survivor滿時，會轉移到to survivor中；

二、當對象循環到必定週期時，新域中的對象會轉移到舊域中，說明此對象不會被常常性的銷燬，生存週期相對比較長；

三、持久域是用來存儲從程序開始執行一直到結束時都存在的那些對象，好比類和方法等；持久域有時並不算入堆heap的範疇，能夠另分爲一個單獨的空間。

 

關於垃圾回收GC的方法：

　　通常而言，有兩種垃圾回收機制：

　　一、引用計數：存儲每一個對象的全部引用數，當引用數爲零時，GC便開始對對象進行垃圾回收；

　　二、對象引用樹：這是目前大多數JVM都在使用的垃圾回收機制。對象引用遍歷樹是對每一個存在於堆中的對象進行反向的尋址，在棧stack裏尋找引用地址，若是能找到此對象的棧中引用的地址，則說明此對象目前正在被引用，不進行銷燬處理，反之，即引用不可到達時，則說明此對象爲空引用，能夠進行銷燬處理；

在JVM刪除廢對象時，有兩個機制：

　　一、清除sweeping：即JVM簡單的掃描堆棧，刪除廢對象，並釋放他們的內存以便用來生成新的對象；可是這個方法有個弊端，就是內存會被分割成好多的小碎片，單個看來是不利於生成新對象的，可是合併起來倒是很大，所以，便觸發了另外一種機制；

　　二、壓縮compact：便是JVM將heap，確切說是新域中的eden和from servivor，中的對象進行從新組織，至關於格式化，重排，從而造成可利用的富足的空間；

 

GC的類型：

　　要實現垃圾的收集，就要先實現一個垃圾收集器。一個JVM中能夠有不少個垃圾收集器。垃圾收集器GC有如下7種：

　　一、標記-清除收集器：使用對象引用樹的方式進行篩選垃圾並清除；這種GC通常使用單線程工做並中止其餘的操做；

　　二、標記-壓縮收集器：又叫作標記-清除-壓縮收集器；第一階段使用前一種GC，第二階段是壓縮堆棧；也會中止其餘的操做；

　　三、複製收集器：將堆棧分爲兩個域，成爲半空間，每次僅使用一個半空間；在GC運行時，將新對象放在一個半空間中，將可到達的對象複製到另外一個半空間中，從而壓縮了堆棧；此方式適用於短生存週期的對象，持續複製長生存週期的對象會致使效率下降；

　　四、增量收集器：把堆棧分爲多個域，每次僅從一個域收集垃圾；這會形成較小的程序中斷；

　　五、分代收集器：把堆棧分爲兩個或多個域，用於存放不一樣壽命的對象。這個也是當前JVM使用的GC機制。將新對象放在新域中，經歷了數個GC週期的對象存放在舊域，持久對象存放在永久域中；分代收集器對不一樣的域使用不一樣的算法以優化性能；

　　六、併發收集器：使用了第二種收集方式，使用併發的形式進行，因此程序中斷的實際時間大大下降了；

　　七、並行收集器：使用傳統的算法，結合多線程並行地執行工做，在多CPU機器上使用可顯著的提升程序的可擴展性；

 

經常使用的內存區域配置命令：

　　JAVA的JVM的GC使用的是分代收集器，它將內存分爲三大塊：堆heap、棧stack和永久域。

堆heap配置命令：

　　　　設置初始大小：-Xms（start）

　　　　　　java -Xms128m

　　　　設置最大值：-Xmx（max）

　　　　　　java -Xmx128m

　　ps：通常而言，Xms和Xmx的大小最好設置爲相同，以免程序動態的增長堆的大小，浪費cup時間。

新域或舊域的配置命令：（三種方法）

　　　　一、設置新域大小：-Xmn（new）

　　　　　　java -Xms256m -Xmx256m -Xmn64m

　　　　二、設置新域的初始值和最大值（通常設置爲相同值）：-XX:NewSize、-XX:MaxNewSize

　　　　　　java -Xms256m -Xmx256m -XX:NewSize=64m -XX:MaxNewSize=64m

　　　　三、設置新域與舊域的比例：-XX:NewRatio

　　　　　　java -Xms256m -Xmx256m -XX:NewRatio=3

　　ps：新域通常爲heap的1/4大小；增大新域的值，可減小fullGC的次數；

永久域的配置命令：-XX:MaxPermSize(最大值)、-XX:PermSize(初始大小)

　　　　　　java -Xms256m -Xmx256m -XX:PermSize=32m -XX:MaxPermSize=64m

配置新域的eden和兩個survivor空間命令：-XX:SurvivorRatio(肯定eden和survivor空間的比值)

　　　　　　java -Xms256m -Xmx256m -Xmn64m -XX:SurvivorRatio=2　　(eden爲32m，兩個survivor均爲16m)

 

JVM調優：

　　原則爲：一次徹底的GC的時間最好控制在3~5s。根據不一樣業務需求進行調整。

設置方法：

一、在windows環境變量中修改：加上JAVA_OPTS=-Xms800m -Xmx800m

二、如使用tomcat服務器，可在catalina.bat中修改：加上set JAVA_OPTS=-Xms800m -Xmx800m

三、如是Linux，在tomcat的catalina.sh中修改：在前面加上set JAVA_OPTS='-Xms800m -Xmx800m'

PS：

一、通常來講，堆棧的大小應爲物理內存的80%；

二、默認狀況下，JVM在啓動時會自動設置堆的值，其初始空間爲物理內存的1/64，最大空間爲1/4；

三、在JVM中，若是98%的時間是用於GC且可用的HeapSize不足2%時，系統將會拋出異常信息：java.lang.OutOfMemoryError:Java heap space;

四、heapsize最大不要超過可用物理內存的80%；

五、通常的新域是整個heapsize的1/4大小，新域的minor收集率在70%以上，具體狀況具體分析；

六、GC時間越長，系統反應越慢，minor的計算方法爲：應用線程被中斷的總時長/（應用執行的總時間+應用線程被中斷的總時長）；

 

謝謝