JVM篇——GC垃圾回收器总图(GC的发展历程)，深入介绍GC垃圾回收器的发展史，进阶升级版！！！

GC垃圾回收器总图

GC的发展历程

随着内存大小不断增长而演进

GC（Garbage Collection，垃圾回收）是一种自动化的内存管理机制，用于在程序运行过程中自动识别和回收不再使用的内存资源，以避免内存泄漏和内存溢出等问题。下面是JVM中GC垃圾回收器的发展历程的概述。

1. Serial收集器（Serial Collector）：最早的垃圾回收器。它使用单线程进行垃圾回收，通过暂停所有工作线程来进行垃圾回收操作。这种收集器适用于小型或单核处理器的应用程序。

2. Parallel收集器（Parallel Collector）：与Serial收集器相比，Parallel收集器使用多线程进行垃圾回收，可以提高垃圾回收的效率。它在新生代和老年代都可以使用，并且在进行垃圾回收时会暂停所有工作线程。

3. CMS收集器（Concurrent Mark Sweep Collector）：CMS收集器目标是减少垃圾回收造成的应用程序停顿时间。它采用并发的方式来进行垃圾回收，通过多线程进行标记和清理操作，以减少应用程序的停顿时间。CMS收集器适用于具有低停顿时间要求的应用程序。

4. G1收集器（Garbage-First Collector）：G1收集器是JDK 7引入的一种全新的垃圾回收器。它将堆内存划分为多个大小相等的区域，并且使用多线程进行垃圾回收。G1收集器的目标是在保证低停顿时间的同时，尽可能地高效利用可用的系统资源。

5. ZGC收集器（Z Garbage Collector）：ZGC收集器是JDK 11引入的一种低停顿时间的垃圾回收器。它通过并发的方式来进行垃圾回收，并且尽量减少应用程序的停顿时间。ZGC收集器适用于需要较低停顿时间和大内存容量的应用程序。

需要注意的是，以上列举的垃圾回收器并非全部，JVM还有其他一些垃圾回收器，如Serial Old收集器、Parallel Old收集器等，它们在不同的场景下有着不同的应用。此外，随着JVM的发展，垃圾回收器也在不断地进行优化和改进，以提高性能和效率。

几兆~几十兆

1、Serial

单线程STW垃圾回收，GC线程执行垃圾回收的时候，业务线程要阻塞等待。因为内存比较少，年轻代和老年代都是单线程完成

2、Old Serial
针对老年代，采用标记清除 + 标记压缩的算法

几十兆~几百兆（G）

随着数据量增大，单线程就不能解决问题了，这个时候就需要多线程来处理这些垃圾内存。用到了Parallel Scavenge和Parallel Old 的垃圾收集器

这两个回收器会在内存垃圾特别多的时候开始工作，工作完毕，垃圾清理的差不多了，就会继续让单线程的Serial和Old Serial工作。
注意，Parallel Scavenge和Parallel Old是Java虚拟机默认开启的垃圾回收器(如果你的JDK是1.8)

通过下面的命令查看java默认虚拟机开启的垃圾回收器
java -XX:+PrintCommandLineFlags -version

我们发现Java默认的GC是UseParallelGC，那么这个UseParallelGC是什么呢？
答案就是Parallel Scavenge和Parallel Old的组合

几十G

这个时候无论你加多少个线程，都无济于事，效率不会提升很高。这里还涉及到一个问题就是，是不是线程越多，效率越高？
其实不然，我们本身CPU是有内核的，4核就是可以一次性处理4条线程，那么一下子进来10个线程，4个线程执行完毕需要将执行完的线程切换成还未执行的线程，这叫做上下文的切换，这是非常消耗CPU性能的，所以，并不是线程越多，效率越高！

这个时候，就需要用到concurrent GC了
什么是concurrent GC？
concurrent表示并发的意思，通俗的讲就是垃圾回收线程和业务线程可以并发执行

那么上图中有哪些属于concurrent GC呢？
CMS、ParNew、G1、ZGC、Shenandoah都是属于concurrent GC！

至此关于JVM中GC的发展历程介绍完毕，后续还会持续更新相关技术点，敬请期待~~~