JVM 垃圾收集器看这篇就够了！！！

1.垃圾收集器

1.1.Serial 垃圾收集器

是JVM最早的一种垃圾收集器, 他最好的地方就是简单, 单线程gc串行执行垃圾回收, 适合单核CPU, 他可以收集的内存区域不会特别大, 几十M到100M顶天了;

年轻代配置:-XX:+UseSerialGC

老年代配置:-XX:+UseSerialOldGC

1.2.Parallel 垃圾收集器

并行垃圾收集器, 说白了就是Serial垃圾收集器的多线程版本, 他关注的是吞量, 也就是更高效的利用多核CPU; 收集算法和回收策略等跟Serial没啥区别; 它适用于内存在2~4G这样, 如果再大就不行了, 那样STW时间会很长;

Parallel是JDK8默认的垃圾收集器

STW的时候可以多线程去执行垃圾收集, 当你的CPU是多核的时候,它收集垃圾的效率会非常高,STW时候更短;

1.3.ParNew收集器

ParNew垃圾收集器跟Parallel很类似, 区别主是它可以和CMS收集器配合使用,而Parallel不行, 这个跟JVM的早期实现有关系, ParNew我们可以理解为他是在Parallel的基础上改了一些东西, 使得可以兼容CMS, ParNew负责年轻代, CMS负责老年代;

ParNew和CMS的组合是很长一段时间很多公司都在用的垃圾收集器组合;

1.4.CMS(Concurrent Mark Sweep)

并发标记清除简称CMS, 它是一种以获取最短回收停顿时间为目标的收集器; 它非常符合在注重用户体验的应用上使用, 它是HotSpot虚拟机第一款真正意义上的并发收集器, 它第一次实现了让垃圾收集线程与用户线程同时工作;

从名字中的Mark Sweep我们可以看出, CMS收集器是一种标记-清除算法实现的, 它的运作过程相比于前面几种垃圾收集器来说更加复杂一些, 整个过程分为四个步骤:

1.4.1.CMS跟Parallel的区别

CMS更适合内存大一点的使用, 因为是应用线程和gc线程并发执行, 所以用户的体验会更好, 为了让STW时间更短而设计;

而Parallel只支持2~4G的堆内存, 并且他在gc的过程中, 应用线程是不能执行的, 所以要是垃圾比较多或内存比较大的话,那么STW时间会很长;

1.4.2.CMS缺点

从它的名字就可以看出它是一款优秀的垃圾收集器，主要优点：并发收集、低停顿。但是它有下面几个明显的缺点：

对CPU资源敏感（会和服务抢资源）；

无法处理浮动垃圾(在并发标记和并发清理阶段又产生垃圾，这种浮动垃圾只能等到下一次gc再清理了)；

它使用的回收算法-“标记-清除”算法会导致收集结束时会有大量空间碎片产生，当然通过参数-

XX:+UseCMSCompactAtFullCollection可以让jvm在执行完标记清除后再做整理;

执行过程中的不确定性，会存在上一次垃圾回收还没执行完，然后垃圾回收又被触发的情况(因为会有用户线程并发执行产生新的垃圾)，特别是在并发标记和并发清理阶段会出现，一边回收，系统一边运行，也许没回收完就再次触发full gc，也就是"concurrent

mode failure(并发失败)"，此时会直接进入stop the world，用serial old垃圾收集器单线程来回收,这个需要通过参数配置来解决

1.4.3.CMS核心参数

1.-XX:+UseConcMarkSweepGC：启用cms;

2.-XX:ConcGCThreads：并发的GC线程数;

3.-XX:+UseCMSCompactAtFullCollection：FullGC之后做压缩整理（整理碎片,也就是浮动垃圾）;

4.-XX:CMSFullGCsBeforeCompaction：多少次FullGC之后压缩一次，默认是0，代表每次FullGC后都会压缩一次;

5.-XX:CMSInitiatingOccupancyFraction: 当老年代内存使用达到该比例时会触发FullGC（默认是92，这是百分比）==> 解决concurrent mode failure问题, 让其不会等到内存快用完了,才去做full gc

6.-XX:+UseCMSInitiatingOccupancyOnly：只使用设定的回收阈值(-XX:CMSInitiatingOccupancyFraction设

定的值)，如果不指定，JVM仅在第一次使用设定值，后续则会自动调整百分比;

7.-XX:+CMSScavengeBeforeRemark：在CMS GC前启动一次minor gc，目的在于减少老年代对年轻代的引用，降低CMS GC的标记阶段时的开销，一般CMS的GC耗时 80%都在标记阶段;

8.-XX:+CMSParallellnitialMarkEnabled：表示在初始标记的时候多线程执行，缩短STW;

9.-XX:+CMSParallelRemarkEnabled：在重新标记的时候多线程执行，缩短STW;

NewParallel跟CMS的组合是很多公司在JDK8中用的比较多的垃圾收集器；

1.5.G1垃圾收集器

1.5.1.G1 简介

G1及后续的一些垃圾收集器都是从CMS演变而来的， 它是JDK9的默认垃圾收集器；

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

G1将Java堆划分为多个大小相等的独立区域（Region），JVM最多可以有2048个Region。

一般Region大小等于堆大小除以2048，比如堆大小为4096M，则Region大小为2M，当然也可以用参数"-

XX:G1HeapRegionSize"手动指定Region大小，但是推荐默认的计算方式。

默认年轻代对堆内存的占比是5%，如果堆大小为4096M，那么年轻代占据200MB左右的内存，对应大概是100个

Region，可以通过“-XX:G1NewSizePercent”设置新生代初始占比，在系统运行中，JVM会不停的给年轻代增加更多的Region，但是最多新生代的占比不会超过60%，可以通过“-XX:G1MaxNewSizePercent”调整。年轻代中的Eden 和 Survivor 对应的region也跟之前一样，默认8:1:1，假设年轻代现在有1000个region，eden区对应800个，s0对应100个，s1对应100个。

一个Region可能之前是年轻代，如果Region进行了垃圾回收，之后可能又会变成老年代，也就是说Region的区域功能可能会动态变化。

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

Humongous区专门存放短期巨型对象，不用直接进老年代，可以节约老年代的空间，避免因为老年代空间不够的GC开销。

Full GC的时候除了收集年轻代和老年代之外，也会将Humongous区一并回收。

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

初始标记（initial mark，STW）：暂停所有的其他线程，并记录下gc roots直接能引用的对象，速度很快 ；

并发标记（Concurrent Marking）：同CMS的并发标记 ；

最终标记（Remark，STW）：同CMS的重新标记 ；

筛选回收（Cleanup，STW）：筛选回收阶段首先对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间(可以用JVM参数 -XX:MaxGCPauseMillis指定)来制定回收计划，比如说老年代此时有1000个Region都满了，但是因为根据预期停顿时间，本次垃圾回收可能只能停顿200毫秒，那么通过之前回收成本计算得 知，可能回收其中800个Region刚好需要200ms，那么就只会回收800个Region(Collection Set，要回收的集 合)，尽量把GC导致的停顿时间控制在我们指定的范围内。这个阶段其实也可以做到与用户程序一起并发执行，但 是因为只回收一部分Region，时间是用户可控制的，而且停顿用户线程将大幅提高收集效率。不管是年轻代或是老 年代，回收算法主要用的是复制算法，将一个region中的存活对象复制到另一个region中，这种不会像CMS那样回收完因为有很多内存碎片还需要整理一次，G1采用复制算法回收几乎不会有太多内存碎片。(注意：CMS回收阶段是跟用户线程一起并发执行的，G1因为内部实现太复杂暂时没实现并发回收，不过到了Shenandoah就实现了并发收集，Shenandoah可以看成是G1的升级版本)

G1收集器在后台维护了一个优先列表，每次根据允许的收集时间，优先选择回收价值最大的Region(这也就是它的名字Garbage-First的由来)，比如一个Region花200ms能回收10M垃圾，另外一个Region花50ms能回收20M垃圾，在回收时间有限情况下，G1当然会优先选择后面这个Region回收。这种使用Region划分内存空间以及有优先级的区域回收方式，保证了G1收集器在有限时间内可以尽可能高的收集效率。

1.5.3.G1具备以下特点

这些是它被视为JDK1.7以上版本Java虚拟机的一个重要进化特征；

1、并行与并发：

G1能充分利用CPU、多核环境下的硬件优势，使用多个CPU（CPU或者CPU核心）来缩短Stop- The-World停顿时间。部分其他收集器原本需要停顿Java线程来执行GC动作，G1收集器仍然可以通过并发的方式 让java程序继续执行。

2、分代收集：

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

3、空间整合：

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

4、可预测的停顿：

这是G1相对于CMS的另一个大优势，降低停顿时间是G1 和 CMS 共同的关注点，但G1 除了 追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段(通过参数"-XX:MaxGCPauseMillis"指定)内完成垃圾收集。

毫无疑问， 可以由用户指定期望的停顿时间是G1收集器很强大的一个功能， 设置不同的期望停顿时间， 可使得G1在不同应用场景中取得关注吞吐量和关注延迟之间的最佳平衡。 不过， 这里设置的“期望值”必须是符合实际的， 不能异想 天开， 毕竟G1是要冻结用户线程来复制对象的， 这个停顿时间再怎么低也得有个限度。 它默认的停顿目标为两百毫秒， 一般来说， 回收阶段占到几十到一百甚至接近两百毫秒都很 正常， 但如果我们把停顿时间调得非常低， 譬如设置为二十毫秒， 很可能出现的结果就是由于停顿目标时间太短， 导致每次选出来的回收集只占堆内存很小的一部分， 收集器收集的速度逐渐跟不上分配器分配的速度， 导致垃圾慢慢堆积。 很可能一开始收集器还能从空闲的堆内存中获得一些喘息的时间， 但应用运行时间一长就不行了， 最终占满堆引发Full GC反而降低性能， 所以通常把期望停顿时间设置为一两百毫秒或者两三百毫秒会是比较合理的。

1.5.4.G1 垃圾收集分类

1、YoungGC

YoungGC并不是说现有的Eden区放满了就会马上触发，G1会计算下现在Eden区回收大概要多久时间，如果回收时间远远小于参数 -XX:MaxGCPauseMills 设定的值，那么增加年轻代的region，继续给新对象存放，不会马上做Young GC，直到下一次Eden区放满，G1计算回收时间接近参数 -XX:MaxGCPauseMills 设定的值，那么就会触发Young GC；

2、MixedGC

不是FullGC，老年代的堆占有率达到参数(-XX:InitiatingHeapOccupancyPercent)设定的值则触发，回收所有的Young和部分Old(根据期望的GC停顿时间确定old区垃圾收集的优先顺序)以及大对象区，正常情况G1的垃圾收集是先做MixedGC，主要使用复制算法，需要把各个region中存活的对象拷贝到别的region里去，拷贝过程中如果发现没有足够的空region能够承载拷贝对象就会触发一次Full GC；

3、Full GC

停止系统程序，然后采用单线程进行标记、清理和压缩整理，好空闲出来一批Region来供下一次MixedGC使用，这个过程是非常耗时的。(Shenandoah优化成多线程收集了) ；

1.5.5.G1收集器参数设置

-XX:+UseG1GC:使用G1收集器

-XX:ParallelGCThreads:指定GC工作的线程数量

-XX:G1HeapRegionSize:指定分区大小(1MB~32MB，且必须是2的N次幂)，默认将整堆划分为2048个分区

-XX:MaxGCPauseMillis:目标暂停时间(默认200ms)

-XX:G1NewSizePercent:新生代内存初始空间(默认整堆5%)

-XX:G1MaxNewSizePercent:新生代内存最大空间

-XX:TargetSurvivorRatio:Survivor区的填充容量(默认50%)，Survivor区域里的一批对象(年龄1+年龄2+年龄n的多个年龄对象)总和超过了Survivor区域的50%，此时就会把年龄n(含)以上的对象都放入老年代

-XX:MaxTenuringThreshold:最大年龄阈值(默认15)

-XX:InitiatingHeapOccupancyPercent:老年代占用空间达到整堆内存阈值(默认45%)，则执行新生代和老年代的混合收集(MixedGC)，比如我们之前说的堆默认有2048个region，如果有接近1000个region都是老年代的region，则可能 就要触发MixedGC了

-XX:G1MixedGCLiveThresholdPercent(默认85%) region中的存活对象低于这个值时才会回收该region，如果超过这 个值，存活对象过多，回收的的意义不大。

-XX:G1MixedGCCountTarget:在一次回收过程中指定做几次筛选回收(默认8次)，在最后一个筛选回收阶段可以回收一会，然后暂停回收，恢复系统运行，一会再开始回收，这样可以让系统不至于单次停顿时间过长。

-XX:G1HeapWastePercent(默认5%): gc过程中空出来的region是否充足阈值，在混合回收的时候，对Region回收都 是基于复制算法进行的，都是把要回收的Region里的存活对象放入其他Region，然后这个Region中的垃圾对象全部清理掉，这样的话在回收过程就会不断空出来新的Region，一旦空闲出来的Region数量达到了堆内存的5%，此时就会立即停止混合回收，意味着本次混合回收就结束了。

1.5.6.G1垃圾收集器优化建议

假设参数 -XX:MaxGCPauseMills 设置的值很大，导致系统运行很久，年轻代可能都占用了堆内存的60%了，此时才触发年轻代gc。

那么存活下来的对象可能就会很多，此时就会导致Survivor区域放不下那么多的对象，就会进入老年代中。

或者是你年轻代gc过后，存活下来的对象过多，导致进入Survivor区域后触发了动态年龄判定规则，达到了Survivor区域的50%，也会快速导致一些对象进入老年代中。所以这里核心还是在于调节 -XX:MaxGCPauseMills 这个参数的值，在保证他的年轻代gc别太频繁的同时，还得考虑每次gc过后的存活对象有多少,避免存活对象太多快速进入老年代，频繁触发mixed gc.

1.5.7.什么场景适合使用G1

1.50%以上的堆被存活对象占用

2.对象分配和晋升的速度变化非常大

3.垃圾回收时间特别长，超过1秒

4.8GB以上的堆内存(建议值)

5.停顿时间是500ms以内

1.5.8.每秒几十万并发的系统如何优化JVM

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

G1天生就适合这种大内存机器的JVM运行，可以比较完美的解决大内存垃圾回收时间过长的问题。

1.5.9.如何选择垃圾收集器

1.优先调整堆的大小让服务器自己来选择

2.如果内存小于100M，使用串行收集器

3.如果是单核，并且没有停顿时间的要求，串行或JVM自己选择

4.如果允许停顿时间超过1秒，选择并行或者JVM自己选

5.如果响应时间最重要，并且不能超过1秒，使用并发收集器

6.4G以下可以用parallel，4-8G可以用ParNew+CMS，8G以上可以用G1，几百G以上用ZGC