JVM学习之八---垃圾收集器G1

G1收集器(-XX:+UseG1GC)

G1(Garbage-First)是一款面向服务器的垃圾收集器，主要针对配备多颗处理器及大容量内存的机器。以极高的概率满足GC停顿时间要求的同时，还具备高吞吐量性能特征。

G1将Java堆划分为多个大小相等的独立区域(Region)，jvm最多可以有2018个Region。
一般Region大小等于堆大小/2048,比如堆大小为4096M,则Region大小为2M。G1保留了年轻代和老年代的概率，但不再是物理隔阂了，他们都是Region的集合。默认年轻代对堆内存的占比是5%。Survivor对应的region跟之前一样，默认也是8:1:1。

G1垃圾收集器对于对象什么时候会转移到老年代跟之前的一样，唯一不同的是对大对象的处理。G1有专门分配的大对象的Region叫Humongous区，而不是让大对象直接进入老年代的Region中。在G1中，大对象的判定规则就是一个大对象超过了一个Region大小的50%。按照上面计算，如果大对象超过了1M，就会被放入Humongous中，而且一个大对象如果太大，可能会横跨多个Region来存放。

G1收集器一次GC的运作过程大致分为如下几个步骤：

• 初始标记(initial mark,STW):暂停所有的其他线程，并记录下GC Roots直接能引用的对象，速度很快；

• 并发标记(Concurrent Marking):同CMS的并发标记

• 最终标记(Remark ,STW):同CMS的重新标记

• 筛选回收(Cleanup,STW):筛选回收阶段首先对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间来制定回收计划。（-XX：MaxGCPauseMillis）。回收算法主要用的是复制算法，将一个Region中的存活对象复制到另一个Region中，这种不会像CMS那样回收完因为有很多内存碎片还需要整理一次，G1采用复制算法回收几乎不会有太多内存碎片。
  
  G1收集器后台维护了一个优先列表，每次根据允许的收集时间，有限选择回收价值最大的Region(Garbage-First的由来)。保证了G1收集器在有限时间内可以尽可能高的收集效率。
  G1特点：

• 并行与并发：G1能充分利用CPU，多核环境下的硬件优势，使用多个CPU来缩短Stop The World停顿时间。

• 分代收集: 虽然G1可以不需要其他收集器配合就可以独立管理GC堆，但是还是保留了分代的概念

• 空间整合: 与CMS的“标记–清除”算法不同，G1从整体来看是基于"标记整理"算法实现的收集器；从局部上来看是基于"复制"算法实现的。

• 可预测的停顿: 这是G1与CMS的另外一个优势，降低停顿时间是G1和CMS共同的关注点，但G1除了追求停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段完成垃圾收集。

G1的垃圾收集分类
Young GC
youngGc 并不是现有的Eden区放满了就会马上触发，G1会计算下现在Eden区回收大概要多久时间，如果回收时间远小于参数-XX:MaxGCPauseMills设定的值，那么增加年轻代的Region，继续给新对象存放，不会马上做Young GC,知道下一次的Eden区放满。G1计算回收时间接近参数的设定值，就会触发mininor gc

Mixed GC
不是Full GC，老年代的堆占有率大搞参数-XX:InitatingHeapOccupancyPercent设置的值触发，回收所有的Young和部分Old 以及大对象区，正常情况下G1的垃圾收集是先做MixedGC,主要使用复制算法，需要把各个Region中存活的对象拷贝到别的Region中，拷贝过程中如果发现没有足够的空Region能够承载拷贝对象就会触发一次Full GC

Full GC
停止系统程序，然后采用单线程进行标记、清理和压缩整理，好空闲出来一批Region供下一次MixedGC使用，这个过程是非常的耗时。

G1收集器参数设置:

• -XX:+UseG1GC:使用G1收集器
• -XX:ParallelGCThreads:指定GC工作的线程数量
• -XX:G1HeapRegionSize:指定分区大小(1MB~32MB，且必须是2的N次幂)，默认将整堆划分为2048个分区
• -XX:MaxGCPauseMillis:目标暂停时间(默认200ms) -XX:G1NewSizePercent:新生代内存初始空间(默认整堆5%)
• -XX:G1MaxNewSizePercent:新生代内存最大空间
• -XX:TargetSurvivorRation:Survivor区的填充容量(默认50%),Survivor区域里的一批对象总和超过了Survivor区域的50%，此时就会把年龄n以上的对象放到老年代
• -XX:MaxTenuringThreashold:最大年龄阈值(默认15)
• -XX:InitatingHeapOccupancyPercent:老年代占用空间达到整堆内存阈值(默认45%),则执行新生代和老年代的混合收集(MixedGC).
• -XX:G1MixedGCLiveThresholdPercent(默认85%)Region中存活对象低于这个值时才会回收该Region，如果超过这个值，存活对象过多，回收的意义不大。
• -XX:G1MixedGCCountTarget:在一次回收过程中指定做几次筛选回收(默认8次)，在最后一个节点筛选回收阶段可以回收一会，然后暂停回收，恢复系统，一会再开始回收，可以让系统单词停顿的时间不用过长。

G1垃圾收集器优化建议
假设参数 -XX:MaxGCPauseMills 设置的值很大，导致系统运行很久，年轻代可能都占用了堆内存的60%了，此时才 触发年轻代gc。
那么存活下来的对象可能就会很多，此时就会导致Survivor区域放不下那么多的对象，就会进入老年代中。
或者是你年轻代gc过后，存活下来的对象过多，导致进入Survivor区域后触发了动态年龄判定规则，达到了Survivor 区域的50%，也会快速导致一些对象进入老年代中。
所以这里核心还是在于调节 -XX:MaxGCPauseMills 这个参数的值，在保证他的年轻代gc别太频繁的同时，还得考虑 每次gc过后的存活对象有多少,避免存活对象太多快速进入老年代，频繁触发mixed gc

什么场景使用G1

• 50%以上的堆被存活对象占用
• 对象分配和晋升的速度变化非常大
• 垃圾回收时间特别长，超过1秒
• 8GB以上的堆内存(建议值)
• 停顿时间是500ms以内

每秒几十万并发的系统如何优化JVM
Kafka类似的支撑高并发消息系统大家肯定不陌生，对于kafka来说，每秒处理几万甚至几十万消息时很正常的，一般 来说部署kafka需要用大内存机器(比如64G)，也就是说可以给年轻代分配个三四十G的内存用来支撑高并发处理。
这里就 涉及到一个问题了，我们以前常说的对于eden区的young gc是很快的，这种情况下它的执行还会很快吗？
很显然，不可 能，因为内存太大，处理还是要花不少时间的，假设三四十G内存回收可能最快也要几秒钟，按kafka这个并发量放满三 四十G的eden区可能也就一两分钟吧，那么意味着整个系统每运行一两分钟就会因为young gc卡顿几秒钟没法处理新消 息，显然是不行的。
那么对于这种情况如何优化了，我们可以使用G1收集器，设置 -XX:MaxGCPauseMills 为50ms，
假 设50ms能够回收三到四个G内存，然后50ms的卡顿其实完全能够接受，用户几乎无感知，那么整个系统就可以在卡顿几 乎无感知的情况下一边处理业务一边收集垃圾。
G1天生就适合这种大内存机器的JVM运行，可以比较完美的解决大内存垃圾回收时间过长的问题。