47.JVM的內存結構，Eden和Survivor比例
49.JVM中一次完整的GC流程是怎樣的，對象如何晉升到老年代，說說你知道的幾種主要的JVM參數
50.-XX:+CMSScavengeBeforeRemark
51.JVM調優——之CMS 常見參數解析
52.你知道哪幾種垃圾收集器，各自的優缺點，重點講下cms和G1，包括原理，流程，優缺點

47.JVM的內存結構，Eden和Survivor比例

eden 和 survior 是按8比1分配的
http://blog.csdn.net/lojze_ly/article/details/49456255

49.JVM中一次完整的GC流程是怎樣的，對象如何晉升到老年代，說說你知道的幾種主要的JVM參數

對象誕生即新生代->eden，在進行minor gc過程中，如果依舊存活，移動到from，變成Survivor，進行標記代數，如此檢查一定次數后，晉升為老年代，
http://www.cnblogs.com/redcreen/archive/2011/05/04/2037056.html
http://ifeve.com/useful-jvm-flags/
https://wangkang007.gitbooks.io/jvm/content/jvmcan_shu_xiang_jie.html

50.-XX:+CMSScavengeBeforeRemark

https://www.zhihu.com/question/61090975

51.JVM調優——之CMS 常見參數解析

最近在學習使用CMS這個GC,這里記錄下常用的參數。

UseCMSCompactAtFullCollection 與 CMSFullGCsBeforeCompaction

有一點需要注意的是：CMS并發GC不是“full GC”。HotSpot VM里對concurrent collection和full collection有明確的區分。所有帶有“FullCollection”字樣的VM參數都是跟真正的full GC相關，而跟CMS并發GC無關的。
CMSFullGCsBeforeCompaction這個參數在HotSpot VM里是這樣聲明的：

product(bool, UseCMSCompactAtFullCollection, true, \"Use mark sweep compact at full collections") \\ product(uintx, CMSFullGCsBeforeCompaction, 0, \"Number of CMS full collection done before compaction if > 0") \

然后這樣使用的：

*should_compact =UseCMSCompactAtFullCollection &&((_full_gcs_since_conc_gc >= CMSFullGCsBeforeCompaction) ||GCCause::is_user_requested_gc(gch->gc_cause()) ||gch->incremental_collection_will_fail(true /* consult_young */));

CMS GC要決定是否在full GC時做壓縮，會依賴幾個條件。其中，
第一種條件，UseCMSCompactAtFullCollection 與 CMSFullGCsBeforeCompaction 是搭配使用的；前者目前默認就是true了，也就是關鍵在后者上。
第二種條件是用戶調用了System.gc()，而且DisableExplicitGC沒有開啟。
第三種條件是young gen報告接下來如果做增量收集會失敗；簡單來說也就是young gen預計old gen沒有足夠空間來容納下次young GC晉升的對象。
上述三種條件的任意一種成立都會讓CMS決定這次做full GC時要做壓縮。

CMSFullGCsBeforeCompaction 說的是，在上一次CMS并發GC執行過后，到底還要再執行多少次full GC才會做壓縮。默認是0，也就是在默認配置下每次CMS GC頂不住了而要轉入full GC的時候都會做壓縮。 把CMSFullGCsBeforeCompaction配置為10，就會讓上面說的第一個條件變成每隔10次真正的full GC才做一次壓縮（而不是每10次CMS并發GC就做一次壓縮，目前VM里沒有這樣的參數）。這會使full GC更少做壓縮，也就更容易使CMS的old gen受碎片化問題的困擾。 本來這個參數就是用來配置降低full GC壓縮的頻率，以期減少某些full GC的暫停時間。CMS回退到full GC時用的算法是mark-sweep-compact，但compaction是可選的，不做的話碎片化會嚴重些但這次full GC的暫停時間會短些；這是個取舍。

-XX:CMSInitiatingOccupancyFraction=70 和-XX:+UseCMSInitiatingOccupancyOnly
這兩個設置一般配合使用,一般用于『降低CMS GC頻率或者增加頻率、減少GC時長』的需求

-XX:CMSInitiatingOccupancyFraction=70 是指設定CMS在對內存占用率達到70%的時候開始GC(因為CMS會有浮動垃圾,所以一般都較早啟動GC);

-XX:+UseCMSInitiatingOccupancyOnly 只是用設定的回收閾值(上面指定的70%),如果不指定,JVM僅在第一次使用設定值,后續則自動調整.

-XX:+CMSScavengeBeforeRemark
在CMS GC前啟動一次ygc，目的在于減少old gen對ygc gen的引用，降低remark時的開銷-----一般CMS的GC耗時 80%都在remark階段

52.你知道哪幾種垃圾收集器，各自的優缺點，重點講下cms和G1，包括原理，流程，優缺點

Serial、parNew、ParallelScavenge、SerialOld、ParallelOld、CMS、G1
https://wangkang007.gitbooks.io/jvm/content/chapter1.html

總結

以上是生活随笔為你收集整理的JVM的内存结构，Eden和Survivor比例；JVM中一次完整的GC流程，对象如何晋升到老年代，说说你知道的几种主要的JVM参数；CMS 常见参数解析；.你知道哪几种垃圾收集器，各自的优缺点的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。