垃圾回收機制

1. 記憶體的組成：堆(Heap)和非堆(Non-heap)記憶體。

堆是執行時資料區域，是由new分配的記憶體，因為不知道大小的，應該有程式自己來申請記憶體空間，所以由堆來分配是留給開發人員使用的；

非堆就是JVM留給自己用的。

2. JVM初始分配的記憶體由-Xms指定，預設是實體記憶體的1/64；JVM最大分配的記憶體由-Xmx指 定，預設是實體記憶體的1/4。預設空餘堆記憶體小於40%時，JVM就會增大堆直到-Xmx的最大限制；空餘堆記憶體大於70%時，JVM會減少堆直到-Xms的最小限制。因此伺服器一般設定-Xms、-Xmx相等以避免在每次GC後調整堆的大小。（這個在後邊jvm

3. 看張圖片：堆記憶體分配（跟後邊說到的GC原理還有jvm調優引數相關聯）

4. 非堆記憶體分配

JVM使用-XX:PermSize設定非堆記憶體初始值，預設是實體記憶體的1/64；由XX:MaxPermSize設定最大非堆記憶體的大小，預設是實體記憶體的1/4。

上邊名詞的定義和解釋，其實跟接下來要說的垃圾回收機制採用的方法相關：

JVM裡的GC(Garbage Collection)的演算法有很多種，這裡就說最常用的一種，分代收集演算法。

5. 分代收集演算法將記憶體分為幾個區域，將不同生命週期的物件放在不同區域裡:young generation，tenured generation

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

7. 我們要儘量減少 Full gc的次數(tenured generation一般比較大,收集的時間較長,頻繁的Full gc會導致應用的效能收到嚴重的影響)。

8. 堆記憶體GC：JVM(採用分代回收的策略)，用較高的頻率對年輕的物件(young generation)進行YGC，而對老物件(tenured generation)較少(tenured generation 滿了後才進行)進行Full GC。這樣就不需要每次GC都將記憶體中所有物件都檢查一遍。

9. 非堆記憶體不GC：GC不會在主程式執行期對PermGen Space進行清理，所以如果你的應用中有很多CLASS(特別是動態生成類，當然permgen space存放的內容不僅限於類)的話,就很可能出現PermGen Space錯誤。

至此：GC的執行流程基本就說完了。接下來，看一些jvm的配置引數，通過配置可以防止GC後出現卡頓的現象。

10. 再說一個專案中的問題：

promotion failed: 垃圾回收時promotion failed是個很頭痛的問題，一般可能是兩種原因產生，第一個原因是救助空間不夠，救助空間裡的物件還不應該被移動到年老代，但年輕代又有很多物件需要放入救助空間；第二個原因是年老代沒有足夠的空間接納來自年輕代的物件；這兩種情況都會轉向Full GC，網站停頓時間較長。

再換一種說法：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。

CMSInitiatingOccupancyFraction低於80%需要調整xmn或SurvivorRatior值。

11．網上推薦的jvm配置的最優方案（僅供參考）

-Xmx256M//最大堆大小

-Xms256M //初始堆大小

-Xmn96M //年輕代大小Sun官方推薦配置為整個堆的3/8

-XX:PermSize=500M //設定持久代(perm gen)初始值 非堆記憶體

-XX:MaxPermSize=500M //設定持久代最大值 --------XMX和XMS設定一樣大，MaxPermSize和MinPermSize設定一樣大，這樣可以減輕伸縮堆大小帶來的壓力。

-Xss256K //每個執行緒的堆疊大小

-XX:+DisableExplicitGC //關閉System.gc(),免得程式設計師誤呼叫gc方法影響效能

-XX:SurvivorRatio=1 //Eden區與Survivor區的大小比值（計算公式）

-XX:+UseConcMarkSweepGC //使用CMS記憶體收集（使用CMS的好處是用盡量少的新生代，經驗值是128M－256M， 然後老生代利用CMS並行收集， 這樣能保證系統低延遲的吞吐效率。 實際上cms的收集停頓時間非常的短，2G的記憶體， 大約20－80ms的應用程式停頓時間）

-XX:+UseParNewGC //設定年輕代為並行收集（使用CMS的好處是用盡量少的新生代，經驗值是128M－256M， 然後老生代利用CMS並行收集， 這樣能保證系統低延遲的吞吐效率。 實際上cms的收集停頓時間非常的短，2G的記憶體， 大約20－80ms的應用程式停頓時間）。

-XX:+CMSParallelRemarkEnabled // 降低標記停頓

-XX:+UseCMSCompactAtFullCollection //在FULL GC的時候，對年老代的壓縮 消除碎片1

-XX:CMSFullGCsBeforeCompaction=0 // 多少次後進行記憶體壓縮2

-XX:+CMSClassUnloadingEnabled

-XX:LargePageSizeInBytes=128M //記憶體頁的大小不可設定過大， 會影響Perm的大小

-XX:+UseFastAccessorMethods //原始型別的快速優化

-XX:+UseCMSInitiatingOccupancyOnly //使用手動定義初始化定義開始CMS收集，禁止hostspot自行觸發CMS GC

-XX:CMSInitiatingOccupancyFraction=80 //使用cms作為垃圾回收 使用80％後開始CMS收集

-XX:SoftRefLRUPolicyMSPerMB=0 //每兆堆空閒空間中SoftReference的存活時間

-XX:+PrintClassHistogram

-XX:+PrintGCDetails

-XX:+PrintGCTimeStamps

-XX:+PrintHeapAtGC //列印GC前後的詳細堆疊資訊