1、 前言
JVM就是Java虚拟机，说白了就是为了屏蔽底层操作系统的不一致而设计出来的一个虚拟机，让用户更加专注上层，而不用在乎下层的一个产品。这就是JVM的跨平台，一次编译，到处运行。
而JVM中的核心功能其实就是自动化的垃圾回收机制。
在Java中你使用对象，使用内存，不用担心回收，只管new对象就行了，不用管垃圾的回收。
因为Java当中是自动化的垃圾回收机制。JVM有专门的垃圾回收器，把垃圾回收这件事给干了。
2、分代收集理论
当前虚拟机的垃圾收集都采用分代收集算法，根据对象存活周期的不同将内存分为几块。一般将java堆分为新生代和老年代，这样我们就可以根据各个年代的特点选择合适的垃圾收集算法。
新生代：每次收集都会有大量对象(近99%)死去，所以可以选择复制算法，只需要付出少量对象的复制成本就可以完成每次垃圾收集。就比如新生代中的 S0 和 S1 区域。
老年代：对象存活几率是比较高的，而且没有额外的空间对它进行分配担保，所以我们必须选择“标记-清除”或“标记-整理”算法进行垃圾收集。
PS：标记-清除”或“标记-整理”算法会比复制算法慢10倍以上。
2.1、垃圾收集算法
标记-复制算法
标记-复制算法是把内存分为大小相等的两块，每次使用其中的一块，当这块内存使用完以后，就会把还存活的对象放到另外一块内存中去，清理刚才使用到的那块空间。分为标记和复制两个阶段：
第一阶段：标记；就是根据Gc Roots标记存活的对象。
第二阶段：复制；把存活的对象复制到另外一块内存中。
缺点：会浪费多余的存储空间。
2.2、标记-清除算法
标记-清除算法分为标记和清除两个阶段：
第一阶段：标记；就是根据Gc Roots标记存活的对象。
第二阶段：清除；统一回收未被标记的对象。
缺点：
效率问题 (如果需要标记的对象太多，效率不高) ；
空间问题（标记清除后会产生大量不连续的碎片）。
2.3、标记-整理算法
标记-整理算法是根据老年代的特点设计出的一种标记算法。他的标记过程和标记清除算法一样的，后续不同的是，它会先把所有存活的对象规整的移动到一起，然后把边界外的对象统一回收。
3、垃圾回收中的STW
对于Java项目来说，JVM进行垃圾收集会有一个很大的问题，就是STW（Stop The World）。
就是在垃圾回收的时候会把应用线程（项目中运行的线程）给停止，然后进行垃圾回收，如果STW的时间过程，用户就会感觉到明显的卡顿现象。
3.1、STW带来的问题
1）安卓手机系统的卡顿
Google 主导的 Android 系统需要解决的一大问题就是显示卡顿问题，通过对 GC 算法的不断演进，停顿时间控制在几个ms 级别。所以这也是Android与苹果IOS系统竞争的一大利器。
2）证券交易系统的实时性
证券交易系统的实时性要求很高，一般都是需要低卖高卖，差之毫厘谬以千里，如果STW的时间很长，到达几秒钟的级别，这几秒钟后的市场完全不同了。所以用Java来做证券系统，STW的时间越短越好。
3.2、垃圾收集器的发展
为了满足不同的业务场景，Java的GC算法和垃圾收集器都在不同的迭代，对于这些延迟敏感的应用来说，GC停顿已经成为了阻碍Java发展的一大顽疾。
近些年来，服务器的性能越来越好，各种应用可以使用的堆内存也越来越大，其实垃圾收集器的发展都是为了解决STW的停顿时间而一直迭代。为了让STW的停顿时间也跟随着堆大小的增长而不呈现指数级的增长而努力，推出了一系列垃圾收集器。
4、垃圾收集器
如果说垃圾回收算法是内存收回的理论，那么垃圾收集器就是内存回收的具体实现。
虽然我们对各个收集器进行比较，但并非为了挑选出一个最好的收集器。因为直到现在为止还没有最好的垃圾收集器出现，更加没有万能的垃圾收集器， 我们能做的就是根据具体应用场景选择适合自己的垃圾收集器 。
4.1、单线程垃圾收集器
1）Serial
Serial（串行）垃圾收集器，一看名字就知道它是一个单线程收集器。它的单线程的意义不仅仅意味着它只会使用一条垃圾收集线程去完成垃圾手机工作，更重要的是它在进行垃圾手机工作的时候还必须暂停其他的所有工作线程（STW），直到它收集结束。
新生代采用标记-复制算法，老年代采用标记-整理算法。
Serial 虽然是单线程，STW的时间有点长，但是它简单且高效（与其它垃圾收集器相比），它没有线程交互的开销，自然而然的可以获得很高的单线程收集效率。
参数设置：-XX:+UseSerialGC(年轻代) -XX:+UseSerialOldGC(老年代)
2）Serial Old
Serial Old收集器是Serial收集器的老年代版本，它同样是单线程收集器。
两大用途：
一种用途是在JDK1.5 以及以前的版本中与Parallel Scavenge收集器搭配使用。
一种用途是作为CMS收集器的后备方案。
4.2、多线程垃圾收集器
1）Parallel Scavenge
Parallel收集器是Serial收集器的多线程版本，除了使用多线程垃圾收集以外，其余和Serial收集器类似。默认的收集线程数跟cpu核数相同，当然也可以用参数(-XX:ParallelGCThreads)指定收集线程数，但是一般不推荐修改。
Parallel Scavenge收集器关注点是吞吐量（高效率的利用CPU）。所谓吞吐量就是CPU中用于运行用户代码的时间与CPU总消耗时间的比值。
新生代采用标记-复制算法，老年代采用标记-整理算法。参数设置：-XX:+UseParallelGC(年轻代),-XX:+UseParallelOldGC(老年代)
2）Parallel Old
Parallel Old收集器是Parallel Scavenge收集器的老年代版本。
使用多线程和“标记-整理”算法。在注重吞吐量以及 CPU资源的场合，都可以优先考虑 Parallel Scavenge收集器和Parallel Old收集器(JDK8默认的新生代和老年代收集器)。
3）ParNew
ParNew收集器其实跟Parallel收集器很类似，区别主要在于它可以和CMS收集器配合使用。
新生代采用标记-复制算法，老年代采用标记-整理算法。
参数设置：-XX:+UseParNewGC
4.3、多线程+并发收集器
1）CMS
CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。它非常符合在注重用户体 验的应用上使用，它是HotSpot虚拟机第一款真正意义上的并发收集器，它第一次实现了让垃圾收集线程与用户线程（基本上）同时工作。
从它的名字中可以看出它是一种 “标记-清除” 算法的实现
GC步骤：
初始标记（STW）：暂停所有的其它线程，期间会STW，并记录GC Roots直接能引用的对象，速度很快。
并发标记：并发标记阶段就是从GC Roots的直接关联对象开始遍历整个对象图的过程， 这个过程耗时较长但 是不需要停顿用户线程， 可以与垃圾收集线程一起并发运行。因为用户程序继续运行，可能会有导致已经标记过的对象状态发生改变。
重新标记（STW）：重新标记阶段就是为了修正并发标记期间因为用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段的时间稍长，远远比并发标记阶段时间短。主要用到三色标记里的增量更新算法做重新标记。
并发清理：开启用户线程，同时GC线程开始对未标记的区域做清扫。这个阶段如果有新增对象会被标记为黑色不做任何处理。
并发重置：重置本次GC过程中的标记数据。
优点：并发收集、低停顿。
缺点：
对CPU资源敏感（会和服务抢资源）；
无法处理浮动垃圾(在并发标记和并发清理阶段又产生垃圾，这种浮动垃圾只能等到下一次gc再清理了)；
它使用的回收算法-“标记-清除”算法会导致收集结束时会有大量空间碎片产生，当然通过参数(- XX:+UseCMSCompactAtFullCollection)可以让jvm在执行完标记清除后再做整理 。
执行过程中的不确定性，会存在上一次垃圾回收还没执行完，然后垃圾回收又被触发的情况，特别是在并 发标记和并发清理阶段会出现，一边回收，系统一边运行，也许没回收完就再次触发full gc，也就是"concurrent mode failure"，此时会进入STW，用serial old垃圾收集器来回收。
核心参数设置：
参数 含义
-XX:+UseConcMarkSweepGC 启用CMS
-XX:ConcGCThreads 并发的GC线程数
-XX:+UseCMSCompactAtFullCollection FullGC之后做压缩整理（减少碎片）
-XX:CMSFullGCsBeforeCompaction 多少次FullGC之后压缩一次，默认是0，代表每次FullGC后都会压缩一次
-XX:CMSInitiatingOccupancyFraction 当老年代使用达到该比例时会触发FullGC（默认是92，这是百分比）
-XX:+UseCMSInitiatingOccupancyOnly
只使用设定的回收阈值
(-XX:CMSInitiatingOccupancyFraction设定的值)，如果不指定，JVM仅在第一次使用设定值，后续则会自动调整
-XX:+CMSScavengeBeforeRemark 在CMS GC前启动一次minor gc，目的在于减少老年代对年轻代的引 用，降低CMS GC的标记阶段时的开销，一般CMS的GC耗时 80%都在标记阶段
-XX:+CMSParallellnitialMarkEnabled 表示在初始标记的时候多线程执行，缩短STW
-XX:+CMSParallelRemarkEnabled 在重新标记的时候多线程执行，缩短STW
4.4、G1收集器
G1垃圾收集器的工作原理和特性：
G1垃圾收集器是一种面向服务器的垃圾收集器，它将堆划分为多个大小相等的独立区域（Region），这些Region可以是年轻代或老年代。G1保留了年轻代和老年代的概念，但它们不再是物理隔阂，而是Region的集合。G1通过监视应用程序的行为和垃圾收集暂停信息来建立相关成本模型，以实现可预测的暂停时间目标。它采用分步递增和并行的方式来执行空间回收，以缩短停顿时间。
大内存应用：G1垃圾收集器适用于堆大小约为6GB或更大的应用程序。当堆大小超过50%的Java堆内存被实时数据占用时，G1能够提供更好的性能。
多处理器机器：G1垃圾收集器特别适合配备多颗处理器的服务器，因为它能够利用多核处理器的优势，实现高效的垃圾收集。
需要稳定且可预测的暂停时间：G1垃圾收集器旨在实现稳定的暂停时间目标，通常不超过0.5秒，这对于需要低延迟的应用程序非常重要。
对象分配和晋升速率变化显著：在堆中，对象分配和晋升的速率可能会随时间显著变化，G1能够适应这种变化，提供更好的性能。
存在大量碎片：当堆中存在大量碎片时，G1能够通过分步递增和并行的方式来执行空间回收，减少碎片化对性能的影响。
使用G1垃圾收集器的命令行参数：
-XX:+UseG1GC：显式启用G1垃圾收集器。
-XX:G1HeapRegionSize：手动指定Region的大小。
-XX:G1NewSizePercent：设置新生代初始占比。
-XX:G1MaxNewSizePercent：调整新生代的最大占比。
这些参数可以帮助用户根据具体需求调整G1垃圾收集器的行为，以优化应用程序的性能和暂停时间。
4.5、ZGC
jdk11 低延迟，浮动垃圾多，适合几百G 以上
5 总结
本章主要讲了JVM中垃圾收集器的发展，从单线程到多线程，再到GC线程和用户线程并发收集的垃圾收集器。
如何选择垃圾收集器：
优先调整堆的大小让服务器自己来选择
如果内存小于100M，使用串行收集器
如果是单核，并且没有停顿时间的要求，串行或JVM自己选择
如果允许停顿时间超过1秒，选择并行或者JVM自己选
如果响应时间最重要，并且不能超过1秒，使用并发收集器
4G以下可以用parallel，4-8G可以用ParNew+CMS，8G以上可以用G1，几百G以上用ZGC。