垃圾收集器
收集算法是内存回收的方法论（理论），垃圾收集器是内存回收的具体实现
注意:并没有一种垃圾收集器是万能的，能够做到的是根据具体场景选择适合的垃圾收集器。各个垃圾收集器各有各的特点，直到现在为止还没有最好的垃圾收集器出现。
Serial收集器（串行收集器）
-XX:+UseSerialGC -XX:+UseSerialOldGC
Serial（串行）收集器是最基础,最老的垃圾收集器，该收集器是一个单线程收集器。
新生代采用复制算法，老年代采用标记整理算法
特点
- 只使用一条垃圾收集线程去完成垃圾收集
- 进行垃圾收集时必须暂停其他所有工作进程（“Stop The World”）,直到它收集结束。
优点
- 简单而高效（与其他收集器的单线程相比）没有切换线程的开销，获得很高的单线程收集效率
Serial Old收集器是Serial收集器的老年代版本，同样是一个单线程收集器
用途
- JDK1.5及以前版本与Paralle Scavenge收集器搭配使用。
- 作为CMS收集器的后备方案。
Parallel Scavenge收集器（新生代）
-XX:+UseParallelGC(年轻代)
-XX:+UseParallelOldGC(老年代)
JDK8默认收集器
Parallel收集器就是Serial收集器的多线程版本
与Serial区别
- 使用多线程进行垃圾收集
- 默认使用与cpu核数相同的收集线程数
- 可使用
- XX:ParallelGCThreads指定收集线程数，不推荐修改
优点
- 高吞吐量（高效率的利用CPU)
与CMS等多线程垃圾收集器相比Parallel Scavenge收集器更加关注吞吐量（高效的利用CPU）。
吞吐量：CPU用于运行用户代码的时间于CPU总消耗时间的比值
新生代采用复制算法，老年代采用标记-整理算法
Parallel Old收集器（老年代）
JDK8默认收集器
Paralle Scavenge收集器的老年版本，使用多线程于
标记-整理算法，同样注重高吞吐量。
ParNew收集器
-XX:+UseParNewGC
ParNew收集器其实于Parallel收集器类似，主要区别在于能够与CMS收集器配合使用。
算法：新生代采用复制算法，老年代采用标记-整理算法
优势：除了Serial收集器外，只有它能够与CMS收集器配合工作
CMS收集器
-XX:+UseConcMarkSweepGC
CMS收集器是一种针对最短回收停顿时间为目标的收集器，更加注重用户体验的应用上使用该收集器，是HopSpot虚拟机第一款真正意义的并发收集器，它实现了垃圾收集线程与用户线程并发。
- CMS收集器采用
标记-清除算法，具体过程：- 初始标记(暂停):
暂停所有其他线程(STW),记录gc roots直接引用对象速度很快 - 并发标记(并发):
从GC Roots的直接引用对象开始遍历对象图，耗时较长但是并不需要暂停用户线程，但是会导致已经标记过的对象状态发生变化。 - 重新标记(暂停):
该阶段就是为了修正并发标记期间因为用户程序运行而导致发生标记变化的对象进行标记记录，该阶段停顿时间一般会比初始标记的时间稍长，但远远比并发标记阶段时间短。主要用到三色标记中的增量更新算法做到重新标记 - 并发清理(并发):
用户线程与GC线程同时进行，GC线程开始对未标记的区域做清理。该阶段新增对象会被标记为黑色不做任何处理。 - 并发重置(并发):重置本次GC过程的标记。
- 初始标记(暂停):
优点：
- 并发收集，停顿少（STW时间短）
缺点:
- 争抢CPU资源（会抢服务的资源）
- 无法回收浮动垃圾（即在并发标记和并发清理阶段产生的垃圾，只能等到下一次GC再进行清理）
- "标记-清理"算法会导致垃圾收集结束时会产生大量空间碎片。可以通过参数让jvm在执行完清理后进行整理。
-XX:+UseCMSCompactAtFullCollection - GC中触发GC，造成缓慢，可能会存在上一次垃圾回收还没有执行完，垃圾回收又被触发的情况。特别是在并发收集和清理阶段会出现，用户线程运行产生的垃圾,还没等上一次GC结束，就触发了full GC造成“concurrent mode failure”（收集器无法处理浮动垃圾），此时会进行Stop the World,用Serial old垃圾收集器进行回收。
CMS核心：三色标记法（并发标记与清除的基础）
CMS相关收集器核心参数
-
启动CMS
添加即为启动-XX:+UseConcMarkSweepGC -
设置并发的GC线程数（默认为机器核心数量）
-XX:ConcGCThreads -
FullGC之后做压缩整理（减少空间碎片）
添加即为启动-XX:+UseCMSCompactAtFullCollection -
设置FullGC多少次后进行压缩一次，默认值为0（即每次FullGC后都会进行压缩一次）
-XX:CMSFullGCsBeforeCompaction -
当老年代使用达到该比例会触发FullGC (
默认为92，单位是%)-XX:CMSInitiatingOccupancyFraction=92 -
只使用设置的回收阈值即第5条↑中设置的百分比，不指定则JVM仅仅在第一次使用设定值，后续自动调整。
添加即为启动该设置-XX:+UseCMSInitiatingOccupancyOnly -
在CMS GC前启动一次minor gc，目的减少老年代对年轻代的引用，降低CMS GC的标记阶段的开销，
一般CMS的GC耗时80%都在标记阶段。-XX:+CMSScavengeBeforeRemark -
初始标记时多线程执行，缩短停顿时间（STW）
添加即为启动该设置-XX:+CMSParallellnitialMarkEnabled -
重新标记时多线程执行，缩短停顿时间（STW）
添加即为启动该设置-XX:+CMSParallelRemarkEnabled
G1收集器
启动参数
-XX:+UseG1GC
该收集器相对于前面CMS等收集器，内存分布完全不同，该收集器主要针对配备了多颗处理器以及大容量内存的机器，以极高概率满足GC停顿时间要求的同时，还具备高吞吐量性能特征。
内存划分与CMS的区别
-
堆划分为多个大小相等的独立区域（Region），JVM最多可以有2048个Region。
手动指定Region大小，但是推荐默认的计算方式-XX:G1HeapRegionSize一般Region大小等于堆大小除以2048，比如堆大小为4096M，则Region大小为2M。
-
保留分代算法，但不再物理隔阂。各代为Region的集合，且可不连续。
设置新生代初始占比-XX:G1NewSizePercent新生代的占比不会超过60%,可通过该参数调整-XX:G1MaxNewSizePercent -
对大对象的处理不同，G1存在专门分配大对象的Region叫Humongous区。
大对象的判定规则：一个大对象超过了一个Region大小的50%， 一个对象太大，可能会横跨多个Region来存放。
Humongous区专门存放短期巨型对象，不用直接进老年代，可以节约老年代的空间，避免因为老年代空间不够的GC开销。Full GC的时候除了收集年轻代和老年代之外，也会将Humongous区一并回收。 -
G1收集器在后台维护了一个优先列表，每次根据允许的收集时间，优先选择回收价值最大的Region(这也就是它的名字 Garbage-First的由来)。
比如一个Region花200ms能回收10M垃圾，另外一个Region花50ms能回收20M垃圾，在回 收时间有限情况下，G1当然会优先选择后面这个Region回收。这种使用Region划分内存空间以及有优先级的区域回收方式，保证了G1收集器在有限时间内可以尽可能高的收集效率。
流程
- 初始标记（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，时间是用户可控制的，而且停顿用户线程将大幅提高收集效率。
GC算法
- 回收算法主要用的是复制算法，将一个region中的存活对象复制到另一个region中，这种不会像CMS那样 回收完因为有很多内存碎片还需要整理一次，G1采用复制算法回收几乎不会有太多内存碎片。
注意：CMS回收阶 段是跟用户线程一起并发执行的，G1因为内部实现太复杂暂时没实现并发回收，不过到了Shenandoah就实现了并发收集，Shenandoah可以看成是G1的升级版本
G1垃圾收集分类
- YoungGC
YoungGC并不是说现有的Eden区放满了就会马上触发，G1会计算下现在Eden区回收大概要多久时间，如果回收时间
远远小于参数-XX:MaxGCPauseMills设定的值，那么增加年轻代的region，继续给新对象存放，不会马上做Young GC，直到下一次Eden区放满，G1计算回收时间接近参数-XX:MaxGCPauseMills设定的值，那么就会触发Young GC - MixedGC
不是FullGC，老年代的堆占有率达到参数-XX:InitiatingHeapOccupancyPercent设定的值则触发，回收所有的 Young和部分Old(根据期望的GC停顿时间确定old区垃圾收集的优先顺序)以及大对象区，正常情况G1的垃圾收集是先做MixedGC，主要使用复制算法，需要把各个region中存活的对象拷贝到别的region里去，拷贝过程中如果发现没有足够的空region能够承载拷贝对象就会触发一次Full GC - Full GC
停止系统(STW)程序，然后采用单线程进行标记、清理和压缩整理，好空闲出来一批Region来供下一次MixedGC使用，这 个过程是非常耗时的。(Shenandoah优化成多线程收集了)
特点
- 并行与并发：G1能
充分利用CPU、多核环境下的硬件优势，使用多个CPU（CPU或者CPU核心）来缩短Stop- The-World停顿时间。部分其他收集器原本需要停顿Java线程来执行GC动作，G1收集器仍然可以通过并发的方式 让java程序继续执行。 - 分代收集：虽然G1可以不需要其他收集器配合就能
独立管理整个GC堆，但是还是保留了分代的概念。 - 空间整合：与CMS的“标记–清理”算法不同，G1从
整体来看是基于“标记整理”算法实现的收集器；从局部上来看是基于“复制”算法实现的。 - 可预测的停顿：这是G1相对于CMS的另一个大优势，降低停顿时间是G1 和 CMS 共同的关注点，但G1 除了 追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段(通过参数"- XX:MaxGCPauseMillis"指定)内完成垃圾收集。
核心参数
使用G1收集器
-XX:+UseG1GC
指定GC工作的线程数量
-XX:ParallelGCThreads
指定分区大小(1MB~32MB，且必须是2的N次幂)，默认将整堆划分为2048个分区
-XX:G1HeapRegionSize
目标暂停时间(默认200ms)
-XX:MaxGCPauseMillis
新生代内存初始空间(默认整堆5%)
-XX:G1NewSizePercent
新生代内存最大空间
-XX:G1MaxNewSizePercent
Survivor区的填充容量(默认50%)，Survivor区域里的一批对象(年龄1+年龄2+年龄n的多个 年龄对象)总和超过了Survivor区域的50%，此时就会把年龄n(含)以上的对象都放入老年代
-XX:TargetSurvivorRatio
最大年龄阈值(默认15)
-XX:MaxTenuringThreshold
老年代占用空间达到整堆内存阈值(默认45%)，则执行新生代和老年代的混合 收集(MixedGC)，比如我们之前说的堆默认有2048个region，如果有接近1000个region都是老年代的region，则可能 就要触发MixedGC了
-XX:InitiatingHeapOccupancyPercent
(默认85%) region中的存活对象低于这个值时才会回收该region，如果超过这 个值，存活对象过多，回收的的意义不大。
-XX:G1MixedGCLiveThresholdPercent
在一次回收过程中指定做几次筛选回收(默认8次)，在最后一个筛选回收阶段可以回收一会，然后暂停回收，恢复系统运行，一会再开始回收，这样可以让系统不至于单次停顿时间过长。
-XX:G1MixedGCCountTarget
(默认5%)gc过程中空出来的region是否充足阈值，在混合回收的时候，对Region回收都 是基于复制算法进行的，都是把要回收的Region里的存活对象放入其他Region，然后这个Region中的垃圾对象全部清 理掉，这样的话在回收过程就会不断空出来新的Region，一旦空闲出来的Region数量达到了堆内存的5%，此时就会立即停止混合回收，意味着本次混合回收就结束了。
-XX:G1HeapWastePercent
优化建议
假设参数
-XX:MaxGCPauseMills设置的值很大，导致系统运行很久，年轻代可能都占用了堆内存的60%了，此时才触发年轻代gc。 那么存活下来的对象可能就会很多，此时就会导致Survivor区域放不下那么多的对象，就会进入老年代中。 或者是你年轻代gc过后，存活下来的对象过多，导致进入Survivor区域后触发了动态年龄判定规则，达到了Survivor区域的50%，也会快速导致一些对象进入老年代中。
核心还是在于调节 -XX:MaxGCPauseMills 这个参数的值，在保证他的年轻代gc别太频繁的同时，还得考虑 每次gc过后的存活对象有多少,避免存活对象太多快速进入老年代，频繁触发mixed gc.
适合场景
- 50%以上的堆被存活对象占用
- 对象分配和晋升的速度变化非常大
- 垃圾回收时间特别长，超过1秒
- 8GB以上的堆内存(建议值)
- 停顿时间是500ms以内
案例场景
Kafka类似的支撑高并发消息系统大家肯定不陌生，对于kafka来说，每秒处理几万甚至几十万消息时很正常的，一般 来说部署kafka需要用大内存机器(比如64G)，也就是说可以给年轻代分配个三四十G的内存用来支撑高并发处理，这里就 涉及到一个问题了，我们以前常说的对于eden区的young gc是很快的，这种情况下它的执行还会很快吗？很显然，不可 能，因为内存太大，处理还是要花不少时间的，假设三四十G内存回收可能最快也要几秒钟，按kafka这个并发量放满三 四十G的eden区可能也就一两分钟吧，那么意味着整个系统每运行一两分钟就会因为young gc卡顿几秒钟没法处理新消 息，显然是不行的。那么对于这种情况如何优化了，我们可以使用G1收集器，设置 -XX:MaxGCPauseMills 为50ms，假 设50ms能够回收三到四个G内存，然后50ms的卡顿其实完全能够接受，用户几乎无感知，那么整个系统就可以在卡顿几 乎无感知的情况下一边处理业务一边收集垃圾。
G1天生就适合这种大内存机器的JVM运行，可以比较完美的解决大内存垃圾回收时间过长的问题。
ZGC
参考文档：http://cr.openjdk.java.net/~pliden/slides/ZGC-OracleDevLive-2020.pdf
ZGC是一款JDK 11中新加入的具有实验性质的低延迟垃圾收集器，并在JDK 15中准备完毕。
该图片来自Oracle官方
主要目标
- 支持TB量级的堆。
我们生产环境的硬盘还没有上TB呢，这应该可以满足未来十年内，所有JAVA应用的需求了吧
- 最大GC停顿时间不超10ms，甚至1ms。
目前一般线上环境运行良好的JAVA应用Minor GC停顿时间在10ms左右， Major GC一般都需要100ms以上（G1可以调节停顿时间，但是如果调的过低的话，反而会适得其反），之所以能做到这一点是因为它的停顿时间主要跟Root扫描有关，而Root数量和堆大小是没有任何关系的。
- 奠定未来GC特性的基础。
- 最糟糕的情况下吞吐量会降低15%。
这都不是事，停顿时间足够优秀。至于吞吐量，通过扩容分分钟解决。 另外，Oracle官方提到了它最大的优点是：它的停顿时间不会随着堆的增大而增长！也就是说，几十G堆的停顿时间是 10ms以下，几百G甚至上T堆的停顿时间也是10ms以下。
281
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
