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

吞吐量：

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

響應能力：

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

以上是用來評價一個系統的兩個很重要的指標，介紹這兩個指標的原因是因為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認為它還不是垃圾，所以該對象的清除工作就會放到下一次了，所以將這種對象則稱之為浮動垃圾】）

轉載于:https://www.cnblogs.com/webor2006/p/11123522.html

總結

以上是生活随笔為你收集整理的G1垃圾收集器设计目标与改良手段【纯理论】的全部內容，希望文章能夠幫你解決所遇到的問題。

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