深刻了解JVW

時間 2019-11-11

標籤深刻瞭解 jvw 简体版

原文原文鏈接

Java內存組成介紹：堆(Heap)和非堆(Non-heap)內存html

按照官方的說法：「Java 虛擬機具備一個堆，堆是運行時數據區域，全部類實例和數組的內存均今後處分配。堆是在 Java 虛擬機啓動時建立的。」「在JVM中堆以外的內存稱爲非堆內存(Non-heap memory)」。能夠看出JVM主要管理兩種類型的內存：堆和非堆。簡單來講堆就是Java代碼可及的內存，是留給開發人員使用的；非堆就是JVM留給本身用的，因此方法區、JVM內部處理或優化所需的內存(如JIT編譯後的代碼緩存)、每一個類結構(如運行時常數池、字段和方法數據)以及方法和構造方法的代碼都在非堆內存中。java

組成圖linux

方法棧&本地方法棧:
線程建立時產生,方法執行時生成棧幀
方法區
存儲類的元數據信息常量等
堆
java代碼中全部的new操做
native Memory(C heap)
Direct Bytebuffer JNI Compile GC;

堆內存分配程序員

JVM初始分配的內存由-Xms指定，默認是物理內存的1/64；JVM最大分配的內存由-Xmx指定，默認是物理內存的1/4。默認空餘堆內存小於40%時，JVM就會增大堆直到-Xmx的最大限制；空餘堆內存大於70%時，JVM會減小堆直到 -Xms的最小限制。所以服務器通常設置-Xms、-Xmx相等以免在每次GC 後調整堆的大小。對象的堆內存由稱爲垃圾回收器的自動內存管理系統回收。web

組成	詳解
Young Generation	即圖中的Eden + From Space + To Space
Eden算法	存放新生的對象
Survivor Spaceapi	有兩個，存放每次垃圾回收後存活的對象
Old Generation	Tenured Generation 即圖中的Old Space 主要存放應用程序中生命週期長的存活對象

非堆內存分配
JVM使用-XX:PermSize設置非堆內存初始值，默認是物理內存的1/64；由XX:MaxPermSize設置最大非堆內存的大小，默認是物理內存的1/4。數組

組成	詳解
Permanent Generation	保存虛擬機本身的靜態(refective)數據主要存放加載的Class類級別靜態對象如class自己，method，field等等 permanent generation空間不足會引起full GC(詳見HotSpot VM GC種類)
Code Cache	用於編譯和保存本地代碼（native code）的內存 JVM內部處理或優化

JVM內存限制(最大值)緩存

JVM內存的最大值跟操做系統有很大的關係。簡單的說就32位處理器雖然可控內存空間有4GB,可是具體的操做系統會給一個限制，這個限制通常是2GB-3GB（通常來講Windows系統下爲1.5G-2G，Linux系統下爲2G-3G），而64bit以上的處理器就不會有限制了。服務器

JVM裏的GC(Garbage Collection)的算法有不少種，如標記清除收集器，壓縮收集器，分代收集器等等,詳見HotSpot VM GC 的種類

如今比較經常使用的是分代收集（generational collection,也是SUN VM使用的,J2SE1.2以後引入），即將內存分爲幾個區域，將不一樣生命週期的對象放在不一樣區域裏:young generation，tenured generation和permanet generation。絕大部分的objec被分配在young generation(生命週期短)，而且大部分的object在這裏die。當young generation滿了以後，將引起minor collection(YGC)。在minor collection後存活的object會被移動到tenured generation(生命週期比較長)。最後，tenured generation滿以後觸發major collection。major collection（Full gc）會觸發整個heap的回收，包括回收young generation。permanet generation區域比較穩定，主要存放classloader信息。

young generation有eden、2個survivor 區域組成。其中一個survivor區域一直是空的，是eden區域和另外一個survivor區域在下一次copy collection後活着的objecy的目的地。object在survivo區域被複制直到轉移到tenured區。

咱們要儘可能減小 Full gc 的次數(tenured generation 通常比較大,收集的時間較長,頻繁的Full gc會致使應用的性能收到嚴重的影響)。

無論是YGC仍是Full GC,GC過程當中都會對致使程序運行中中斷,正確的選擇不一樣的GC策略,調整JVM、GC的參數，能夠極大的減小因爲GC工做，而致使的程序運行中斷方面的問題，進而適當的提升Java程序的工做效率。可是調整GC是以個極爲複雜的過程，因爲各個程序具有不一樣的特色，如：web和GUI程序就有很大區別（Web能夠適當的停頓，但GUI停頓是客戶沒法接受的），並且因爲跑在各個機器上的配置不一樣（主要cup個數，內存不一樣），因此使用的GC種類也會不一樣(如何選擇見GC種類及如何選擇)。本文將注重介紹JVM、GC的一些重要參數的設置來提升系統的性能。

JVM內存組成及GC相關內容請見以前的文章:JVM內存組成 GC策略&內存申請。

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。

GC性能方面的考慮

對於GC的性能主要有2個方面的指標：吞吐量throughput（工做時間不算gc的時間佔總的時間比）和暫停pause（gc發生時app對外顯示的沒法響應）。

1. Total Heap

默認狀況下，vm會增長/減小heap大小以維持free space在整個vm中佔的比例，這個比例由MinHeapFreeRatio和MaxHeapFreeRatio指定。

通常而言，server端的app會有如下規則：

對vm分配儘量多的memory；
將Xms和Xmx設爲同樣的值。若是虛擬機啓動時設置使用的內存比較小，這個時候又須要初始化不少對象，虛擬機就必須重複地增長內存。
處理器核數增長，內存也跟着增大。

2. The Young Generation

另一個對於app流暢性運行影響的因素是young generation的大小。young generation越大，minor collection越少；可是在固定heap size狀況下，更大的young generation就意味着小的tenured generation，就意味着更多的major collection(major collection會引起minor collection)。

NewRatio反映的是young和tenured generation的大小比例。NewSize和MaxNewSize反映的是young generation大小的下限和上限，將這兩個值設爲同樣就固定了young generation的大小（同Xms和Xmx設爲同樣）。

若是但願，SurvivorRatio也能夠優化survivor的大小，不過這對於性能的影響不是很大。SurvivorRatio是eden和survior大小比例。

通常而言，server端的app會有如下規則：

首先決定能分配給vm的最大的heap size，而後設定最佳的young generation的大小；
若是heap size固定後，增長young generation的大小意味着減少tenured generation大小。讓tenured generation在任什麼時候候夠大，可以容納全部live的data（留10%-20%的空餘）。

經驗&&規則

年輕代大小選擇
- 響應時間優先的應用:儘量設大,直到接近系統的最低響應時間限制(根據實際狀況選擇).在此種狀況下,年輕代收集發生的頻率也是最小的.同時,減小到達年老代的對象.
- 吞吐量優先的應用:儘量的設置大,可能到達Gbit的程度.由於對響應時間沒有要求,垃圾收集能夠並行進行,通常適合8CPU以上的應用.
- 避免設置太小.當新生代設置太小時會致使:1.YGC次數更加頻繁 2.可能致使YGC對象直接進入舊生代,若是此時舊生代滿了,會觸發FGC.
年老代大小選擇
1. 響應時間優先的應用:年老代使用併發收集器,因此其大小須要當心設置,通常要考慮併發會話率和會話持續時間等一些參數.若是堆設置小了,能夠會形成內存碎片,高回收頻率以及應用暫停而使用傳統的標記清除方式;若是堆大了,則須要較長的收集時間.最優化的方案,通常須要參考如下數據得到:
  併發垃圾收集信息、持久代併發收集次數、傳統GC信息、花在年輕代和年老代回收上的時間比例。
2. 吞吐量優先的應用:通常吞吐量優先的應用都有一個很大的年輕代和一個較小的年老代.緣由是,這樣能夠儘量回收掉大部分短時間對象,減小中期的對象,而年老代盡存放長期存活對象.
較小堆引發的碎片問題
由於年老代的併發收集器使用標記,清除算法,因此不會對堆進行壓縮.當收集器回收時,他會把相鄰的空間進行合併,這樣能夠分配給較大的對象.可是,當堆空間較小時,運行一段時間之後,就會出現"碎片",若是併發收集器找不到足夠的空間,那麼併發收集器將會中止,而後使用傳統的標記,清除方式進行回收.若是出現"碎片",可能須要進行以下配置:
-XX:+UseCMSCompactAtFullCollection:使用併發收集器時,開啓對年老代的壓縮.
-XX:CMSFullGCsBeforeCompaction=0:上面配置開啓的狀況下,這裏設置多少次Full GC後,對年老代進行壓縮
用64位操做系統，Linux下64位的jdk比32位jdk要慢一些，可是吃得內存更多，吞吐量更大
XMX和XMS設置同樣大，MaxPermSize和MinPermSize設置同樣大，這樣能夠減輕伸縮堆大小帶來的壓力
使用CMS的好處是用盡可能少的新生代，經驗值是128M－256M，而後老生代利用CMS並行收集，這樣能保證系統低延遲的吞吐效率。實際上cms的收集停頓時間很是的短，2G的內存，大約20－80ms的應用程序停頓時間
系統停頓的時候多是GC的問題也多是程序的問題，多用jmap和jstack查看，或者killall -3 java，而後查看java控制檯日誌，能看出不少問題。(相關工具的使用方法將在後面的blog中介紹)
仔細瞭解本身的應用，若是用了緩存，那麼年老代應該大一些，緩存的HashMap不該該無限制長，建議採用LRU算法的Map作緩存，LRUMap的最大長度也要根據實際狀況設定。
採用併發回收時，年輕代小一點，年老代要大，由於年老大用的是併發回收，即便時間長點也不會影響其餘程序繼續運行，網站不會停頓
JVM參數的設置(特別是 –Xmx –Xms –Xmn -XX:SurvivorRatio -XX:MaxTenuringThreshold等參數的設置沒有一個固定的公式，須要根據PV old區實際數據 YGC次數等多方面來衡量。爲了不promotion faild可能會致使xmn設置偏小，也意味着YGC的次數會增多，處理併發訪問的能力降低等問題。每一個參數的調整都須要通過詳細的性能測試，才能找到特定應用的最佳配置。

promotion failed:

垃圾回收時promotion failed是個很頭痛的問題，通常多是兩種緣由產生，第一個緣由是救助空間不夠，救助空間裏的對象還不該該被移動到年老代，但年輕代又有不少對象須要放入救助空間；第二個緣由是年老代沒有足夠的空間接納來自年輕代的對象；這兩種狀況都會轉向Full GC，網站停頓時間較長。

解決方方案一：

第一個緣由個人最終解決辦法是去掉救助空間，設置-XX:SurvivorRatio=65536 -XX:MaxTenuringThreshold=0便可，第二個緣由個人解決辦法是設置CMSInitiatingOccupancyFraction爲某個值（假設70），這樣年老代空間到70%時就開始執行CMS，年老代有足夠的空間接納來自年輕代的對象。

解決方案一的改進方案：

又有改進了，上面方法不太好，由於沒有用到救助空間，因此年老代容易滿，CMS執行會比較頻繁。我改善了一下，仍是用救助空間，可是把救助空間加大，這樣也不會有promotion failed。具體操做上，32位Linux和64位Linux好像不同，64位系統彷佛只要配置MaxTenuringThreshold參數，CMS仍是有暫停。爲了解決暫停問題和promotion failed問題，最後我設置-XX:SurvivorRatio=1 ，並把MaxTenuringThreshold去掉，這樣即沒有暫停又不會有promotoin failed，並且更重要的是，年老代和永久代上升很是慢（由於好多對象到不了年老代就被回收了），因此CMS執行頻率很是低，好幾個小時才執行一次，這樣，服務器都不用重啓了。

-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

CMSInitiatingOccupancyFraction值與Xmn的關係公式

上面介紹了promontion faild產生的緣由是EDEN空間不足的狀況下將EDEN與From survivor中的存活對象存入To survivor區時,To survivor區的空間不足，再次晉升到old gen區，而old gen區內存也不夠的狀況下產生了promontion faild從而致使full gc.那能夠推斷出：eden+from survivor < old gen區剩餘內存時，不會出現promontion faild的狀況，即：
(Xmx-Xmn)*(1-CMSInitiatingOccupancyFraction/100)>=(Xmn-Xmn/(SurvivorRatior+2)) 進而推斷出：

CMSInitiatingOccupancyFraction <=((Xmx-Xmn)-(Xmn-Xmn/(SurvivorRatior+2)))/(Xmx-Xmn)*100

例如：

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

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

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

CMSInitiatingOccupancyFraction低於70% 須要調整xmn或SurvivorRatior值。

令：

Java application項目（非web項目）

改進前：

-Xms128m
-Xmx128m
-XX:NewSize=64m
-XX:PermSize=64m
-XX:+UseConcMarkSweepGC
-XX:CMSInitiatingOccupancyFraction=78
-XX:ThreadStackSize=128
-Xloggc:logs/gc.log
-Dsun.rmi.dgc.server.gcInterval=3600000
-Dsun.rmi.dgc.client.gcInterval=3600000
-Dsun.rmi.server.exceptionTrace=true

問題:

permsize 設置較小,很容易達到報警範圍(0.8)
沒有設置MaxPermSize，堆增加會帶來額外壓力。
NewSize較大，old gen 剩餘空間64m，一方面可能會帶來old區容易增加到報警範圍（監控數據顯示oldgenused長期在50m左右，接近78%，容易出現full gc）,另外一方面也存在promontion fail風險

改進後：

-Xms128m
-Xmx128m
-Xmn24m
-XX:PermSize=80m
-XX:MaxPermSize=80m
-Xss256k
-XX:SurvivorRatio=1
-XX:MaxTenuringThreshold=20
-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
-XX:CMSInitiatingOccupancyFraction=75
-XX:+UseCMSCompactAtFullCollection
-XX:+CMSParallelRemarkEnabled
-XX:CMSFullGCsBeforeCompaction=2
-XX:SoftRefLRUPolicyMSPerMB=0
-XX:+PrintClassHistogram
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-XX:+PrintHeapAtGC
-Xloggc:logs/gc.log
-Dsun.rmi.dgc.server.gcInterval=3600000
-Dsun.rmi.dgc.client.gcInterval=3600000
-Dsun.rmi.server.exceptionTrace=true

修改點：

PermSize與MaxPermSize都設置爲80，一方面避免non heap warn(報警閥值0.8 非對內存通常佔用到60M之內），一方面避免堆伸縮帶來的壓力
經過設置Xmn=24M及SurvivorRatio=1 使得Eden區=from space=to space=8M,下降了Eden區大小，下降YGC的時間(下降到3-4ms左右),同時經過設MaxTenuringThreshold=20，使得old gen的增加很緩慢。帶來的問題是YGC的次數明顯提升了不少。
其餘參數優化修改後帶來的好處見JVM參數設置

再次改進後

-Xms128m
-Xmx128m
-Xmn36m
-XX:PermSize=80m
-XX:MaxPermSize=80m
-Xss256k
-XX:SurvivorRatio=1
-XX:MaxTenuringThreshold=20
-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
-XX:CMSInitiatingOccupancyFraction=73
-XX:+UseCMSCompactAtFullCollection
-XX:+CMSParallelRemarkEnabled
-XX:CMSFullGCsBeforeCompaction=2
-XX:SoftRefLRUPolicyMSPerMB=0
-XX:+PrintClassHistogram
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-XX:+PrintHeapAtGC
-Xloggc:logs/gc.log
-Dsun.rmi.dgc.server.gcInterval=3600000
-Dsun.rmi.dgc.client.gcInterval=3600000
-Dsun.rmi.server.exceptionTrace=true

修改點：

在上面的基礎上調整Xmn大小到36M，設置CMSInitiatingOccupancyFraction=73。

Dden區與Survivor區大小都增長到12M，經過 CMSInitiatingOccupancyFraction計算公式,計算得出value爲73是，能夠避免promotion faild問題，同時知足堆內存監控報警值在80%：內存大小128M*80%=102.4M 102.4M-36M=66.4M(老生代達到此值報警）老生代達到67.15M（92M*0.73）將發生Full GC，因此在老生代大小達到66.4M時也就是WARN報警時將頗有可能出現Full GC。

增大了Eden和Survivor區的值，會減少YGC的次數，但因爲空間變大理論上也會相應的增長YGC的時間，不過因爲新生代自己就很小（才36M）這點兒變化能夠忽略掉。實際的監控值顯示YGC的時間在4-5ms之間。是能夠接受範圍。

SurvivorRatio 這個值還得在仔細考慮下,有待優化中

網上某個牛人的配置 :天天幾百萬pv一點問題都沒有，網站沒有停頓

$JAVA_ARGS
.=
"
-Dresin.home=$SERVER_ROOT
-server
-Xms6000M
-Xmx6000M
-Xmn500M
-XX:PermSize=500M
-XX:MaxPermSize=500M
-XX:SurvivorRatio=65536
-XX:MaxTenuringThreshold=0
-Xnoclassgc
-XX:+DisableExplicitGC
-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
-XX:+UseCMSCompactAtFullCollection
-XX:CMSFullGCsBeforeCompaction=0
-XX:+CMSClassUnloadingEnabled
-XX:-CMSParallelRemarkEnabled
-XX:CMSInitiatingOccupancyFraction=90
-XX:SoftRefLRUPolicyMSPerMB=0
-XX:+PrintClassHistogram
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-XX:+PrintHeapAtGC
-Xloggc:log/gc.log
";

說明一下， -XX:SurvivorRatio=65536 -XX:MaxTenuringThreshold=0就是去掉了救助空間；

-Xnoclassgc禁用類垃圾回收，性能會高一點；

-XX:+DisableExplicitGC禁止System.gc()，省得程序員誤調用gc方法影響性能；

-XX:+UseParNewGC，對年輕代採用多線程並行回收，這樣收得快；

帶CMS參數的都是和併發回收相關的，不明白的能夠上網搜索；

CMSInitiatingOccupancyFraction，這個參數設置有很大技巧，基本上知足(Xmx-Xmn)*(100-CMSInitiatingOccupancyFraction)/100>=Xmn就不會出現promotion failed。在個人應用中Xmx是6000，Xmn是500，那麼Xmx-Xmn是5500兆，也就是年老代有5500兆，CMSInitiatingOccupancyFraction=90說明年老代到90%滿的時候開始執行對年老代的併發垃圾回收（CMS），這時還剩10%的空間是5500*10%=550兆，因此即便Xmn（也就是年輕代共500兆）裏全部對象都搬到年老代裏，550兆的空間也足夠了，因此只要知足上面的公式，就不會出現垃圾回收時的promotion failed；

SoftRefLRUPolicyMSPerMB這個參數我認爲可能有點用，官方解釋是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，我以爲不必等1秒；

-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

改進方案：

上面方法不太好，由於沒有用到救助空間，因此年老代容易滿，CMS執行會比較頻繁。我改善了一下，仍是用救助空間，可是把救助空間加大，這樣也不會有promotion failed。
具體操做上，32位Linux和64位Linux好像不同，64位系統彷佛只要配置MaxTenuringThreshold參數，CMS仍是有暫停。爲了解決暫停問題和promotion failed問題，最後我設置-XX:SurvivorRatio=1 ，並把MaxTenuringThreshold去掉，這樣即沒有暫停又不會有promotoin failed，並且更重要的是，年老代和永久代上升很是慢（由於好多對象到不了年老代就被回收了），因此CMS執行頻率很是低，好幾個小時才執行一次，這樣，服務器都不用重啓了。

某網友:

$JAVA_ARGS
.=
"
-Dresin.home=$SERVER_ROOT
-server
-Xmx3000M
-Xms3000M
-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=70
-XX:SoftRefLRUPolicyMSPerMB=0
-XX:+PrintClassHistogram
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-XX:+PrintHeapAtGC
-Xloggc:log/gc.log
";

64位jdk參考設置，年老代漲得很慢，CMS執行頻率變小，CMS沒有停滯，也不會有promotion failed問題，內存回收得很乾淨

前幾篇篇文章介紹了介紹了JVM的參數設置並給出了一些生產環境的JVM參數配置參考方案。正如以前文章中提到的JVM參數的設置須要根據應用的特性來進行設置，每一個參數的設置都須要對JVM進行長時間的監測，並不斷進行調整才能找到最佳設置方案。本文將介紹若是經過工具及Java api來監測JVM的運行狀態,並詳細介紹各工具的使用方法。

須要監測的數據：(內存使用狀況誰使用了內存 GC的情況)

內存使用狀況--heap&PermGen

@ 表示經過jmap –heap pid 能夠獲取的值

# 表示經過jstat –gcutil pid 能夠獲取的值

參數的查看能夠經過多種方法本文中只隨機列出一種。

描述	最大值	當前值	報警值
堆內存	@Heap Configuration::MaxHeapSize sum(eden+servivor+old)	sum(eden+servivor+old)	自設
非堆內存	sum(perm+native)		無
Eden	@Eden Space::capacity	@Eden Space::used	無
Survivor0	@From Space::capacity	@From Space::used	無
Survivor1	@To Space::capacity	@To Space::used	無
New gen (注意區別於Xmn參數設置)	@New Generation::capacity Eden + 1 Survivor Space	@New Generation::used	無
Old gen	@concurrent mark-sweep generation::capacity (CMS是對old區的gc,因此此處即表示old gen)	@concurrent mark-sweep generation::capacity(CMS)::used	自設
Perm Gen	@Perm Generation::capacity	@Perm Generation::used	自設

內存使用狀況--config

描述	配置值
MaxTenuringThreshold	jinfo -flag MaxTenuringThreshold pid
MinHeapFreeRatio	@Heap Configuration::MinHeapFreeRatio
MaxHeapFreeRatio	@Heap Configuration::MaxHeapFreeRatio
new gen gc	@using … in the new generation
old gen gc	new gen gc聲明下方
類總數統計	??

內存使用狀況—C heap

top or ps aux

誰使用了內存

Heap
jmap –histo
jmap –dump ,then mat
C heap
google perftools

GC的情況

描述	收集次數	收集時間	應用暫停時間
Full GC	#FGC	#FGCT	設置-XX:+PrintGCApplicationStoppedTime後在日誌中查看
Young GC	#YGC	#YGCT	同上

-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -XX:+PrintGCApplicationStoppedTime -Xloggc:logs/gc.log

經常使用工具介紹:jinfo jmap jstack jstat

jinfo

能夠從一個給定的java進程或core文件或遠程debug服務器上獲取java配置信息。包括java系統屬性及JVM參數(command line flags)。注意在jvm啓動參數中沒有配置的參數也可以使用jinfo –flag xxx pid輸出默認值(頗有用,但貌似一些簡寫的參數查不出來)。
能夠修改運行時的java 進程的opts。
只有solaris和linux的JDK版本里有。
使用方式可以使用jinfo –h 查詢。

jmap

觀察運行中的jvm物理內存的佔用狀況。

若是連用SHELL jmap -histo pid>a.log能夠將其保存到文本中去，在一段時間後，使用文本對比工具，能夠對比出GC回收了哪些對象。

參數很簡單，直接查看jmap -h

舉例：

jmap -heap pid

jmap -dump:format=b,file=heap.hprof <pid>

dump文件能夠經過MemoryAnalyzer分析查看.網址： http://www.eclipse.org/mat/，能夠查看dump時對象數量，內存佔用，線程狀況等。

jmap -dump:live爲啥會觸發Full GC

jstack

觀察jvm中當前全部線程的運行狀況和線程當前狀態

若是java程序崩潰生成core文件，jstack工具能夠用來得到core文件的java stack和native stack的信息，從而能夠輕鬆地知道java程序是如何崩潰和在程序何處發生問題。另外，jstack工具還能夠附屬到正在運行的java程序中，看到當時運行的java程序的java stack和native stack的信息, 若是如今運行的java程序呈現hung的狀態，jstack是很是有用的。目前只有在Solaris和Linux的JDK版本里面纔有。

參數很簡單，直接查看jstack -h

舉例：

jstack pid

jstat

JVM監測工具(Java Virtual Machine Statistics Monitoring Tool)。利用了JVM內建的指令對Java應用程序的資源和性能進行實時的命令行的監控，包括各類堆和非堆的大小及其內存使用量、classloader、compiler、垃圾回收情況等。

舉例:

jstat –printcompilation -h10 3024 250 600

每250毫秒打印一次，一共打印600次每隔10行顯示一次head

語法結構:

Usage: jstat -help|-options
       jstat -<option> [-t] [-h<lines>] <vmid> [<interval> [<count>]]

參數介紹：

-h n 每隔幾行輸出標題
vmid VM的進程號，即當前運行的java進程號
-t 在第一列顯示自JVM啓動以來的時間戳
-J 修改java進程的參數。相似jinfo -flag <name>=<value>。例如-J-Xms48m 設置初始堆爲48M。詳見這裏。這個參數挺有用的，能夠在運行中調整參數以方便測試、監測。
-option option爲要檢測的參數。參數列表可經過jstat –options 獲取。下面將分別介紹每一個參數及輸出字段的含義。

class	統計class loader行爲信息
compiler	統計編譯行爲信息
gc	統計jdk gc時heap信息
gccapacity	統計堆內存不一樣代的heap容量信息
gccause	統計gc的狀況（同-gcutil）和引發gc的事件
gcnew	統計gc時新生代的信息(相比gcutil更詳細)
gcnewcapacity	統計gc時新生代heap容量
gcold	統計gc時，老年區的狀況
gcoldcapacity	統計gc時，老年區heap容量
gcpermcapacity	統計gc時，permanent區heap容量
gcutil	統計gc時，heap狀況
printcompilation	統計編譯行爲信息

-class option:Class Loader Statistics

Column	Description
Loaded	Number of classes loaded.
Bytes	Number of Kbytes loaded.
Unloaded	Number of classes unloaded.
Bytes	Number of Kbytes unloaded.
Time	Time spent performing class load and unload operations.

-compiler:HotSpot Just-In-Time Compiler Statistics

Column	Description
Compiled	Number of compilation tasks performed.
Failed	Number of compilation tasks that failed.
Invalid	Number of compilation tasks that were invalidated.
Time	Time spent performing compilation tasks.
FailedType	Compile type of the last failed compilation.
FailedMethod	Class name and method for the last failed compilation.

-gc Option:Garbage-collected heap statistics

Column	Description
S0C	Current survivor space 0 capacity (KB).
S1C	Current survivor space 1 capacity (KB).
S0U	Survivor space 0 utilization (KB).
S1U	Survivor space 1 utilization (KB).
EC	Current eden space capacity (KB).
EU	Eden space utilization (KB).
OC	Current old space capacity (KB).
OU	Old space utilization (KB).
PC	Current permanent space capacity (KB).
PU	Permanent space utilization (KB).
YGC	Number of young generation GC Events.
YGCT	Young generation garbage collection time.
FGC	Number of full GC events.
FGCT	Full garbage collection time.
GCT	Total garbage collection time.

-gccapacity Option:Memory Pool Generation and Space Capacities

Column	Description
NGCMN	Minimum new generation capacity (KB).
NGCMX	Maximum new generation capacity (KB).
NGC	Current new generation capacity (KB).
S0C	Current survivor space 0 capacity (KB).
S1C	Current survivor space 1 capacity (KB).
EC	Current eden space capacity (KB).
OGCMN	Minimum old generation capacity (KB).
OGCMX	Maximum old generation capacity (KB).
OGC	Current old generation capacity (KB).
OC	Current old space capacity (KB).
PGCMN	Minimum permanent generation capacity (KB).
PGCMX	Maximum Permanent generation capacity (KB).
PGC	Current Permanent generation capacity (KB).
PC	Current Permanent space capacity (KB).
YGC	Number of Young generation GC Events.
FGC	Number of Full GC Events.

-gccause Option:Garbage Collection Statistics, Including GC Events

Column	Description
LGCC	Cause of last Garbage Collection.
GCC	Cause of current Garbage Collection.

前面的字段與gcutil相同.

-gcnew Option:New Generation Statistics

Column	Description
S0C	Current survivor space 0 capacity (KB).
S1C	Current survivor space 1 capacity (KB).
S0U	Survivor space 0 utilization (KB).
S1U	Survivor space 1 utilization (KB).
TT	Tenuring threshold.
MTT	Maximum tenuring threshold.
DSS	Desired survivor size (KB).
EC	Current eden space capacity (KB).
EU	Eden space utilization (KB).
YGC	Number of young generation GC events.
YGCT	Young generation garbage collection time.

-gcnewcapacity Option:New Generation Space Size Statistics

Column	Description
NGCMN	Minimum new generation capacity (KB).
NGCMX	Maximum new generation capacity (KB).
NGC	Current new generation capacity (KB).
S0CMX	Maximum survivor space 0 capacity (KB).
S0C	Current survivor space 0 capacity (KB).
S1CMX	Maximum survivor space 1 capacity (KB).
S1C	Current survivor space 1 capacity (KB).
ECMX	Maximum eden space capacity (KB).
EC	Current eden space capacity (KB).
YGC	Number of young generation GC events.
FGC	Number of Full GC Events.

-gcold Option:Old and Permanent Generation Statistics

Column	Description
PC	Current permanent space capacity (KB).
PU	Permanent space utilization (KB).
OC	Current old space capacity (KB).
OU	old space utilization (KB).
YGC	Number of young generation GC events.
FGC	Number of full GC events.
FGCT	Full garbage collection time.
GCT	Total garbage collection time.

-gcoldcapacity Option:Old Generation Statistics

Column	Description
OGCMN	Minimum old generation capacity (KB).
OGCMX	Maximum old generation capacity (KB).
OGC	Current old generation capacity (KB).
OC	Current old space capacity (KB).
YGC	Number of young generation GC events.
FGC	Number of full GC events.
FGCT	Full garbage collection time.
GCT	Total garbage collection time.

-gcpermcapacity Option: Permanent Generation Statistics

Column	Description
PGCMN	Minimum permanent generation capacity (KB).
PGCMX	Maximum permanent generation capacity (KB).
PGC	Current permanent generation capacity (KB).
PC	Current permanent space capacity (KB).
YGC	Number of young generation GC events.
FGC	Number of full GC events.
FGCT	Full garbage collection time.
GCT	Total garbage collection time.

-gcutil Option:Summary of Garbage Collection Statistics

Column	Description
S0	Survivor space 0 utilization as a percentage of the space's current capacity.
S1	Survivor space 1 utilization as a percentage of the space's current capacity.
E	Eden space utilization as a percentage of the space's current capacity.
O	Old space utilization as a percentage of the space's current capacity.
P	Permanent space utilization as a percentage of the space's current capacity.
YGC	Number of young generation GC events.
YGCT	Young generation garbage collection time.
FGC	Number of full GC events.
FGCT	Full garbage collection time.
GCT	Total garbage collection time.

-printcompilation Option: HotSpot Compiler Method Statistics

Column	Description
Compiled	Number of compilation tasks performed.
Size	Number of bytes of bytecode for the method.
Type	Compilation type.
Method	Class name and method name identifying the compiled method. Class name uses "/" instead of "." as namespace separator. Method name is the method within the given class. The format for these two fields is consistent with the HotSpot -XX:+PrintComplation option.

Java api方式監測

jre中提供了一些查看運行中的jvm內部信息的api，這些api包含在java.lang.management包中，此包中的接口是在jdk 5中引入的，因此只有在jdk 5及其以上版本中才能經過這種方式訪問這些信息。下面簡單介紹一下這包括哪些信息，以及如何訪問。

能夠經過此api訪問到運行中的jvm的類加載的信息、jit編譯器的信息、內存分配的狀況、線程的相關信息以及運行jvm的操做系統的信息。java.lang.management包中提供了9個接口來訪問這些信息，使用ManagementFactory的靜態get方法能夠得到相應接口的實例，能夠經過這些實例來獲取你須要的相關信息。

更詳細的關於MBean的介紹參見Java SE 6 新特性: JMX 與系統管理

demo1:查看一下當前運行的jvm中加載了多少個類。想詳細瞭解如何使用這些api，能夠參考java.lang.management包中的詳細api文檔。

public class ClassLoaderChecker {
    public static void main( String[] args ) throws Exception {
      ClassLoadingMXBean bean = ManagementFactory.getClassLoadingMXBean();
      System.out.println( bean.getLoadedClassCount() );
    }
}

demo2:自定義Mbean Type,記錄的數據可經過jconsole等工具或自寫代碼查看,

//工具方法

public static ObjectName register(String name, Object mbean) { try { ObjectName objectName = new ObjectName(name); MBeanServer mbeanServer = ManagementFactory .getPlatformMBeanServer(); try { mbeanServer.registerMBean(mbean, objectName); } catch (InstanceAlreadyExistsException ex) { mbeanServer.unregisterMBean(objectName); mbeanServer.registerMBean(mbean, objectName); } return objectName; } catch (JMException e) { throw new IllegalArgumentException(name, e); } }

//步驟一:定義Mbean接口:

//隨便定義

public interface DemoMBean {

public AtomicLong getInvokeCount();

}

//步驟二:實現接口,並註冊:

public class DemoImpl implements DemoMBean{

public final static String DEFAULT_OBJECT_NAME_PREFIX = "com.redcreen.demo:type=demo";

}

//能夠經過jconsole中查看數據了

堆內存GC
JVM(採用分代回收的策略)，用較高的頻率對年輕的對象(young generation)進行YGC，而對老對象(tenuredgeneration)較少(tenuredgeneration 滿了後才進行)進行Full GC。這樣就不須要每次GC都將內存中全部對象都檢查一遍。

非堆內存不GC

GC不會在主程序運行期對PermGen Space進行清理，因此若是你的應用中有不少CLASS(特別是動態生成類，固然permgen space存放的內容不只限於類)的話,就極可能出現PermGen Space錯誤。

內存申請、對象衰老過程
1、內存申請過程

JVM會試圖爲相關Java對象在Eden中初始化一塊內存區域；
當Eden空間足夠時，內存申請結束。不然到下一步；
JVM試圖釋放在Eden中全部不活躍的對象（minor collection），釋放後若Eden空間仍然不足以放入新對象，則試圖將部分Eden中活躍對象放入Survivor區；
Survivor區被用來做爲Eden及old的中間交換區域，當OLD區空間足夠時，Survivor區的對象會被移到Old區，不然會被保留在Survivor區；
當old區空間不夠時，JVM會在old區進行major collection；
徹底垃圾收集後，若Survivor及old區仍然沒法存放從Eden複製過來的部分對象，致使JVM沒法在Eden區爲新對象建立內存區域，則出現"Out of memory錯誤"；

2、對象衰老過程

新建立的對象的內存都分配自eden。Minor collection的過程就是將eden和在用survivor space中的活對象copy到空閒survivor space中。對象在young generation裏經歷了必定次數(能夠經過參數配置)的minor collection後，就會被移到old generation中，稱爲tenuring。

GC觸發條件

GC類型

觸發條件

觸發時發生了什麼

注意

查看方式

YGC

eden空間不足

清空Eden+from survivor中全部no ref的對象佔用的內存
將eden+from sur中全部存活的對象copy到to sur中
一些對象將晉升到old中:
to sur放不下的
存活次數超過turning threshold中的
從新計算tenuring threshold(serial parallel GC會觸發此項)

從新調整Eden 和from的大小(parallel GC會觸發此項)

全過程暫停應用
是否爲多線程處理由具體的GC決定

jstat –gcutil
gc log

FGC

old空間不足
perm空間不足
顯示調用System.GC, RMI等的定時觸發
YGC時的悲觀策略
dump live的內存信息時(jmap –dump:live)

清空heap中no ref的對象
permgen中已經被卸載的classloader中加載的class信息

如配置了CollectGenOFirst,則先觸發YGC(針對serial GC)
如配置了ScavengeBeforeFullGC,則先觸發YGC(針對serial GC)

全過程暫停應用
是否爲多線程處理由具體的GC決定

是否壓縮須要看配置的具體GC