Java垃圾收集器之G1介绍（一）

末蓝、 2022-09-22 01:12 105阅读 0赞

![ab189c74-f12c-3d7c-8ccd-da0bcfd93884.jpg][]  
先来看下Oracle HotSpot JVM的体系结构：  
   
  
![dd297258-afbd-328a-817f-7a08fee9a252.png][]   
  
  
JVM主要组件包括，类加载器，运行时内存区，以及执行引擎，程序员主要关注的应该是运行时区域这块了，  
回顾下类加载器的顺序：  
  
\->Boostrap ClassLoad 引导类，加载java规范定义和接口声明主要是/jre/lib/rt.jar  
\-> Ext ClassLoad 加载扩展类 /jre/lib/ext/\*jar  
\-> (System Class Path)App ClassLoad 加载class path环境内的jar  
\-> (User Difine ClassLoad) //用户自定义的加载器 需要继承ClassLoad抽象类，重写其中的一些方法  
  
  
在Java的应用程序里面，主要有两大类：  
A：追求快速响应类程序 解释：在极短时间内，快速响应  
主要体现场景：  
（1）绑定在event上的事件能够快速响应，例如GUI程序  
（2）对于一个网站能够快速响应展示一个动态页面  
（2）更快的数据库查询  
  
这些场景都集中在快速响应时间上面，长时间的等待是不能被接受的  
  
B：追求大吞吐量类程序 解释： 在指定时间内，能够处理的最大工作量  
主要体现场景：  
（1）在指定时间内处理的事务量  
（2）在指定时间内能处理多少批处理job  
（3）在指定时间内能查询或者写入数据库多少次  
  
这些场景，主要追求指定时间内的吞吐量或者叫生产量，吞吐率，生产能力，所以不关注响应时间，只关注生产能力，所以长时间的等待是可以接受的  
  
明白了这个，相信再理解OLTP和OLAP概念就非常容易了，因为他们就对应  
一个吞吐量，一个响应时间  
  
下面进入正题，学习下G1垃圾收集器：  
  
一：G1垃圾收集器介绍  
  
G1垃圾收集器是服务端的垃圾回收器，它的应用目标主要是在多CPU和大内存的应用场景中，旨在大多数情况下，在可预测的垃圾回收时间内，获得更大的吞吐量为目标，G1垃圾收集器全面支持JDK7 update 4 及之后的版本，G1 的设计场景主要是：  
  
（1）应用在高并发应用程序中像CMS垃圾收集器一样，快速响应  
（2）在整理内存碎片空间上花费更短的停顿时间  
（3）可预测的GC停顿时间  
（4）更高的吞吐量  
（5）小内存的Java堆也可以用G1  
  
G1收集器的长远目标旨在替代CMS垃圾收集器，当然现在G1还不太成熟，CMS垃圾收集器，仍是电商类，B/S网站类，搜索类应用程序的首选垃圾收集器，不过如果你的内存足够大的话，也可以尝试下G1收集器。  
  
G1对比CMS垃圾收集器，主要有两个部分的不同区别：  
  
A：使用更紧凑粗粒度的内存区域划分，简称region，它简化了收集管理，消除了之前垃圾收集器潜在的内存碎片问题  
B：相比CMS，G1提供了可预测的GC停顿时间，允许用户指定渴望的暂定周期  
  
  
二：G1操作概述  
  
旧的垃圾收集器serial，parallel，CMS所有的结构都在堆里面划分三个主要区域：新生代，老年代，和永久代，  
结构如下：  
   
  
![e89c89af-8850-3ee0-ac97-5bf4f97077d3.png][]   
  
  
所有的对象都生存在这三个区域之一。  
  
G1的分配方式与之前的不同，如下图：  
   
  
![d7d2ca5c-34e1-33bd-8252-44c6a429e535.png][]   
  
  
  
  
G1划分成多个同样大小的region，每个连续范围的虚拟内存空间，可以分配一样的角色（eden，survivor，old）但是每个角色的大小不是固定的，这样就提供了比较大的灵活性。  
  
在发生gc时，g1收集器的方式和cms大致一致：  
  
首先并发标记在整个堆里面存活的对象，当标记完成之后，G1知道大部分region是空闲的有哪些，然后首先回收这些空间生成更大数量的自由内存空间，这也是G1（grabage first）名字的来历，然后G1从一个或多个region区域中拷贝对象进入单个region区域，接着会并行的方式压缩整理内存空间，为了减少gc时间和增加吞吐量。  
  
G1持续的运行，在用户定义停顿时间内，不断的合并整理内存碎片，这是之前的两种垃圾收集器可能缺少的考虑，比如CMS垃圾收集器在收集完成后，不会压缩整理内存空间，而ParallelOld会合并整理内存空间，但是，是在整个堆区域的，这样就没法保证gc停顿时间，最后需要说明的是G1并不是实时的垃圾收集器，Full GC的时候也是单线程的，并且会暂停所有的用户线程，不过按照Oracle官网的说法，只要你能合理  
的配置GC策略，完全是可以避免Full GC的。  
  
  
三：推荐使用G1的场景  
  
G1垃圾收集器集中几种的应用场景是在应用程序有大内存并且要求极小的延迟的情况下，这意味着堆内存应该至少6G以上，稳定的可预测的停顿时间在0.5秒以下。  
  
如果在使用CMS或者c垃圾收集器出现以下的情况时，切换G1垃圾收集器可以带来更好的效果：  
  
（1）Full GC 太长或者太频繁  
（2）对象的分配内存空间率或者晋升频率差异很大  
（3）追求更快的响应时间，当停顿时间大于0.5秒之1秒时  
  
注意：如果你使用CMS或者ParallelOldGC 的gc时间可以接受，最好的方式  
仍然使用当前的GC垃圾收集器，此外改为G1垃圾收集器，并不意味着，你就要一定升级到最新的JDK版本，当然如果可以的话，还是尽量使用当然最新最稳定的版本。  
  
  
参考文档：[http://www.oracle.com/technetwork/tutorials/tutorials-1876574.html][http_www.oracle.com_technetwork_tutorials_tutorials-1876574.html]  
   
  
有什么问题可以扫码关注微信公众号：我是攻城师(woshigcs)，在后台留言咨询。  
技术债不能欠，健康债更不能欠， 求道之路，与君同行。  
   
![3214000f-5633-3c17-a3d7-83ebda9aebff.jpg][]

[ab189c74-f12c-3d7c-8ccd-da0bcfd93884.jpg]: /images/20220721/c6df65cabff741a5971072e154f45d52.png
[dd297258-afbd-328a-817f-7a08fee9a252.png]: /images/20220721/24148c86369d42f9b0de88ab66fcceb9.png
[e89c89af-8850-3ee0-ac97-5bf4f97077d3.png]: /images/20220721/36c8129f5cce4fc48c0732d21768f4c7.png
[d7d2ca5c-34e1-33bd-8252-44c6a429e535.png]: /images/20220721/f994c68c60b14dc682ed3fcf91e87f08.png
[http_www.oracle.com_technetwork_tutorials_tutorials-1876574.html]: http://www.oracle.com/technetwork/tutorials/tutorials-1876574.html
[3214000f-5633-3c17-a3d7-83ebda9aebff.jpg]: /images/20220721/db6743ef527e4440934a49713b04f57e.png