【JAVA GC垃圾回收器】JAVA GC垃圾回收算法，垃圾回收器，垃圾回收策略总结，可达性分析算法，分代垃圾回收
【JAVA GC垃圾回收器】JAVA GC垃圾回收算法，垃圾回收器，垃圾回收策略总结，可达性分析算法，分代垃圾回收
问个问题：jdk8 默认使用的是什么垃圾回收器
1. 可达性分析算法：
JAVA中确定堆内存对象是否为垃圾通常使用可达性分析算法。该算法通过从根节点（例如栈中的引用、静态变量、常量等）开始遍历对象图，检查每个对象是否可以通过根节点到达。如果一个对象无法通过根节点到达，那么它就被认为是垃圾，需要被回收的对象。
ps： 除了可达性分析算法外还有引用计数算法，也可以标记垃圾对象，但是引用计数法存在一个问题，就是对象循环引用的问题，导致本应该是垃圾的对象不能标记为垃圾。
2. 垃圾回收算法：
1). 标记清除算法， 有内存碎片
2). 复制算法，需要开辟2块区域
3). 标记-整理算法，结合了标记清除算法和复制算法的优点
4). 分代收集算法，年轻代，年老代。年轻代使用复制算法进行垃圾回收，老年代使用标记-压缩算法或标记-清除算法进行垃圾回收
3. 垃圾回收器通常会按照以下步骤工作：
1). 标记阶段
2). 清除阶段
3). 压缩阶段（可选）
4. 垃圾回收器是如何进行内存分配和回收的:
1). 内存分配
2). 对象标记
3). 垃圾回收
4). 内存整理
5). 重复上述过程
5. 垃圾回器：
1). Serial GC
特点：单线程、STW、复制和标记整理算法 （新生代：复制算法，老年代：标记整理算法）
-XX:+UseSerialGC
2). Parallel GC
特点：并发、STW、复制和标记整理算法，JDK8中默认垃圾回收器
-XX:+UseParallelGC
3). CMS GC ，最短停顿时间为目标，提高快速响应为目标, 不是默认的垃圾回收器，因为比如内存碎片，STW，配置成本高等原因导致。
特点：并发、较短STW、标记清除算法有内存碎片，JDK5中引入
-XX:+UseConcMarkSweepGC
初始标记，单线程GC， STW
并发标记，多线程GC， 三色标记：白色（未扫描），灰色（已扫描但是其引用未全部扫描），黑色（已扫描且其引用已全部扫描）
重新标记
并发清理，清理未被标记未黑色的对象
并发重置，将存活对象的标记给清除掉
4). G1 GC， 最短STW，并发，空间整理
JDK7中引入，JDK9默认的垃圾回收器
填补了Parallel GC和CMS GC之间的空白，提供一个低延迟的垃圾回收解决方案
-XX:+UseG1GC
初始标记：GC单线程
并发标记：多个GC线程和用户线程同时工作。三色标记
白色，灰色，黑色。 初始时，所有对象都是白色。
最终标记：多线程STW进行，可以通过增量标记或者写屏障技术来减少需要重新标记的对象数量
筛选回收：计算每个region的回收成本，并按照回收成本排序，然后按照用户期望的停顿时间进行计算，决定应该回收哪些region
5). ZGC
-XX:+UseZGC
ZGC是一种低延迟的垃圾回收器，目前仍在积极开发中。ZGC的设计初衷是为了在大堆内存上工作，并且几乎不产生延迟。这使得它非常适合需要快速响应但是内存占用大的应用程序。
6). Shenandoah GC
-XX:+UseShenandoahGC
Shenandoah GC与ZGC有类似的目标：减少停顿时间，即便是在大堆或者多核心处理器的情况下。Shenandoah通过在GC的许多阶段与应用线程并发执行来实现这一目标。
6.为了减少 GC 对应用程序性能的影响，可以采取以下一些优化措施：
1). 选择合适的垃圾回收器：根据应用程序的特点选择合适的垃圾回收器，例如对于需要低延迟的应用程序，可以选择并发垃圾回收器，比如CMS，G1
2). 调整堆大小：根据应用程序的内存需求和性能要求，合理调整堆的大小，避免频繁的垃圾回收。
3). 避免产生大量临时对象：尽量减少临时对象的创建和使用，避免短生命周期对象的频繁分配和回收。
特别是在性能敏感的区域，临时对象的频繁分配和回收可能导致垃圾回收的开销增加。
4). 优化对象的分配和释放：合理使用对象池、内存缓存等技术，减少对象的频繁分配和释放。
5). 监控和调优：使用性能监控工具监测应用程序的内存使用情况和垃圾回收性能，根据实际情况进行调优。
可以根据监控数据调整垃圾回收器的参数、堆大小等，以优化性能。
6). 优化对象的生命周期：尽量延长对象的生命周期，避免短生命周期对象的频繁创建和销毁。这可以减少垃圾回收的频率和开销。
7). 避免内存泄漏：内存泄漏会导致对象无法被垃圾回收器回收，占据内存空间。定期检查和修复内存泄漏问题，可以避免垃圾回收器的性能下降。
7. 为何CMS不能作为默认垃圾回收器:
CMS（Concurrent Mark-Sweep）收集器是一个以获取最短回收停顿时间为目标的收集器，使用"标记-清除"算法，并且是并发的。但是在JDK版本的迭代中没有任何一个版本使用CMS为一个默认的垃圾回收器。
选择Parallel Scavenge和Parallel Old的原因而不用CMS，通常基于以下考虑：
1). 吞吐量优先： 如果应用不是非常注重服务响应时间，而是更希望在单位时间内完成更多的工作，即追求较高的吞吐量，那么Parallel Scavenge加上Parallel Old垃圾收集器会是一个更合适的选择。
2). 碎片化问题：CMS使用的"标记-清除"算法容易导致内存碎片化，
当碎片化严重到一定程度，CMS需要进行一次完全停顿的垃圾收集以整理内存碎片（Full GC），这可能导致较长时间的停顿。而Parallel Old使用的"标记-整理"算法可以有效避免内存碎片化问题。
3). 更简单稳定： 相较于CMS，Parallel Scavenge和Parallel Old通常来说维护起来比较简单，参数配置也更容易。而CMS有几百个参数需要配置调整，对于维护的成本是非常高的。
8. JDK默认的垃圾回收器:
1) JDK 8（Java Development Kit 8）中默认的垃圾回收器组合为Parallel Scavenge（用于Young Generation）加上Parallel Old（用于Old Generation）。
2) Parallel GC 在 JDK 5 中开始成为默认的垃圾回收器，特点：并行+STW。
3) JDK 9 开始默认垃圾回收器是 G1 (Garbage-First)。
4) Java 11之后，还引入了ZGC和Shenandoah等实验性的低停顿时间垃圾收集器。