前言

  如果您觉得有用的话，记得给博主点个赞，评论，收藏一键三连啊，写作不易啊^ _ ^。
  而且听说点赞的人每天的运气都不会太差，实在白嫖的话，那欢迎常来啊!!!

---

HotSpot 垃圾收集器

HotSpot 虚拟机提供了多种垃圾收集器，每种收集器都有各自的特点，虽然我们要对各个收集器进行比较，但并非为了挑选出一个最好的收集器。我们选择的只是对具体应用最合适的收集器。

1. 查看jdk默认垃圾收集器命令

java -XX:+PrintCommandLineFlags -version

Java 虚拟机通常会根据运行环境和硬件自动选择合适的默认垃圾收集器，但也可以通过配置参数来指定使用特定的垃圾收集器.

2. 查看当前服务使用的是哪个垃圾收集器:

jps: 列出当前正在运行的 Java 进程和它们的 PID

jcmd: jcmd 命令可以用来执行各种诊断命令，包括查看 JVM 参数和运行时信息。你可以使用 jcmd 来查看正在运行的 Java 进程使用的垃圾收集器类型。

jcmd <pid> VM.flags

可以看到使用的是G1垃圾收集器。

3. 常用的垃圾收集器

3.1. 并行垃圾收集器（Parallel Garbage Collector）

优点：

• 通过多线程同时进行垃圾收集，提高了垃圾收集的吞吐量，适合处理需要高吞吐量的应用场景。
• 在多核处理器上表现优异，能够充分利用多核处理器的优势。
• 适合用于后台运行的任务，不会对应用的响应时间造成显著影响。

缺点：

• 由于并行进行垃圾收集，会消耗更多的 CPU 资源，可能导致在一些性能敏感的应用场景中，对响应时间造成不利影响。
• 不够灵活，无法很好地适应大内存和低延迟要求的场景。

3.2. CMS 垃圾收集器（Concurrent Mark-Sweep Garbage Collector）

优点:

• 通过与应用线程并发执行标记和清除过程，减少了垃圾收集时的停顿时间，适合对响应时间要求较高的应用。
• 对于大部分应用，能够提供比并行垃圾收集器更低的停顿时间。

缺点:

• 在进行老年代的清理时，可能会出现“并发模式失败”（Concurrent Mode Failure），需要使用 Serial Old 垃圾收集器进行退化处理，可能导致较长的停顿时间。
• 由于并发执行会占用一定的 CPU 资源，对应用的总吞吐量有一定的影响。

3.3. G1 垃圾收集器（Garbage-First Garbage Collector）

优点：

• 目标是在有限的时间内实现更加可预测的停顿时间，能够在大堆内存下提供更为稳定的性能。
• 通过划分堆空间为多个区域（Region），可以根据应用的特征动态调整垃圾收集的策略，有效控制停顿时间。

缺点：

• 由于复杂的区域管理和垃圾收集策略，可能导致一些性能开销，尤其是在小堆或者低延迟要求的场景中。
• 初始标记和最终标记阶段仍然需要暂停应用线程，虽然停顿时间通常短暂，但对于某些特别要求低延迟的应用仍可能不够理想。