垃圾回收算法

实验性GC算法

并发压缩 ZGC & Shenandoah

@G1 & CMS在新生代上面都没有并发回收，回收新生代需要暂停所有应用程序。
G1 GC
老年代的压缩是Mixed GC周期的结果，在目标区域中，没有被释放的对象会被压缩到空的区域
G1的停顿有三种
较长的Full GC,如果优化的足够好则不会出现
较短的YoungGC 包括回收和压缩部分老年代的混合回收
较短的标记线程停顿
CMS
当老年代太过碎片化而无法容纳新分配的对象，老年代会被压缩，新生代也会被压缩一部分，是将存活的对象移动S或O空间
@在压缩过程中，对象在内存中的位置会移动。这是JVM在该操作期间暂停所有应用程序线程的主要原因。
如果应用程序暂停，更细内存引用的算法就会简单。能够处理静态的引用而不用担心其他顾虑。
所以应用程序的停顿时间取决于移动对象的时间和取保对象的引用已更新的时间
Full GC时间中的变量问题

使用实验回收器需要开启的标志，替换GC算法
-XX:UnlockExperimentalVMOption 默认false
-XX:+UseZGC
-XX:+UseShenandoahGC

实验性回收堆都可以进行并发压缩，在不暂停应用程序线程的情况下移动堆中对象
1.堆不在需要分代设计，只有一个堆。在回收的过程中应用程序线程不需要暂停而新生代的需求就消失了
2.应用程序线程的操作延迟预期会减少
REST cell it and then 如果垃圾回收G1发生中断，回收耗时500mm,这些调用延迟会影响系统的整体性能。

两种回收都会出现非常短的标记线程停顿，目标是将停顿时间保持在非常短的水平，10mm
会在单个线程的操作中引入延迟
应用程序对对象的访问由一个屏障守护
如果对象处于移动的过程，应用线程会在屏障出等待，直到移动完成
如果应用程序正在访问对象，则GC需要在屏障等待，直到可以重新定位对象
类似对对象引用使用锁的一种形式。对应用程序的吞吐量影响不大。

并发压缩对延迟的影响

FullGC停顿时间
新生代停顿时间
并发回收的最小停顿
垃圾回收的停顿一般是造成延迟异常的最大原因，还有服务器和客户端之间的临时拥塞和OS调度

并发压缩回收对于吞吐量的影响

依赖于后台线程扫描和处理堆。
如果后台线程没能够获得足够的CPU，回收器会出现之前的并发失败，最终发生FULL GC
并发线程更加依赖于后台线程进行GC处理
如果CPU足够。则吞吐量提升。

无回收 Epsilon GC

对象永远不会被回收，直到堆填满之后抛出内存溢出错误提示
设计目的
1.存活时间非常短的对象应用程序
2.重复使用内存并且永不执行分配操作