G1垃圾收集器設計目標與改良手段【純理論】

在以前已經詳細對CMS垃圾回收器進行了學習，今天準備要學習另外一個全新的垃圾收集器---G1（Garbage First Collector 垃圾優先的收集器），說是一種全新的，其實G1垃圾收集器已經出現了N多年了，只是從發展到成熟是須要經歷必定的過程，oracle官方計劃在jdk9中將G1變成默認的垃圾收集器，以替代CMS， 可見G1確定有它獨特的地方，它跟咱們以前所學的各類垃圾底層是徹底不同的，好比最明顯的不一樣是之前的分代收集方式是將堆劃分爲新生代、老年代兩個區域，而新生代又劃分爲Eden和兩個Survivor，也就是從物理的結構就明確的作了區域劃分，可是！！！G1它依據的物理形態跟咱們以前所接觸的垃圾收集器徹底不同了，也就是明顯會感受到G1裏面的堆內存沒有明顯的區域劃分的，也就是這一塊區域是新生代，那一塊區域就是老年代了，因此接下來也是從理論開始學習，以後再用實踐來論證理論：

吞吐量：

• 吞吐量關注的是，在一個指定的時間內，最大化一個應用的工做量。
• 以下方式來衡量一個系統吞吐量的好壞：
  一、在一個小時內同一個事務（或者任務、請求）完成的次數（tps，實際中還會常常見qps，每秒查詢率QPS是對一個特定的查詢服務器在規定時間內所處理流量多少的衡量標準）。
  二、數據庫一小時能夠完成多少次查詢。
• 對於關注吞吐量的系統，卡頓是能夠接受的，由於這個系統關注長時間的大量任務的執行能力，單次快速的響應並不值得考慮。

響應能力：

• 響應能力指一個程序或者系統對請求是否可以及時響應，好比：
  一、一個桌面UI能多快地響應一個事件。
  二、一個網站可以多快返回一個頁面請求。
  三、數據庫可以多快返回查詢的數據。
• 對於這類對響應能力敏感的場景，長時間的停頓是沒法接受的。

以上是用來評價一個系統的兩個很重要的指標，介紹這兩個指標的緣由是由於G1就是用來解決這樣的問題而應運而生的。

G1 Garbage Collector：

• g1收集器是一個面向服務端的垃圾收集器，適用於多核處理器、大內存容量的服務端系統。
• 它知足短期gc停頓的同時達到一個較高的吞吐量。
• JDK7以上版本適用【經過配置JVM的參數來指定既可】。

以上能夠看到G1在吞吐量和響應能力上都進行了兼顧。

G1收集器的設計目標：

• 與應用線程同時工做，幾乎【注意措辭】不須要stop the world(與CMS相似)；
• 整理剩餘空間，不產生內存碎片（CMS只能在Full GC時，用stop the world整理內存碎片）。
• GC停頓更加可控；【對於CMS來講若是出現了Full GC時，則會對新生代和老年代的堆內存進行完整的整理，停頓時間就不可控了】
• 不犧牲系統的吞吐量；
• gc不要求額外的內存空間（CMS須要預留空間存儲浮動垃圾【這個在學習CMS中已經闡述過了，其實就是CMS回收的過程跟用戶線程是併發進行的，所在在標記或者清除的同時對象的引用還會被改變，使得原來對象原本不是垃圾，當CMS清理時該對象已經變成了垃圾了，可是CMS認爲它還不是垃圾，因此該對象的清除工做就會放到下一次了，因此將這種對象則稱之爲浮動垃圾】）