【JVM】对象存活判定算法、GC算法、STW、GC种类详解

【JVM】对象存活判定算法、GC算法、STW、GC种类详解

GC主要关注的区域

垃圾收集主要是针对堆和方法区进行；程序计数器、虚拟机栈和本地方法栈这三个区域属于线程私有的，只存在于线程的生命周期内，线程结束之后也会消失，因此不需要对这三个区域进行垃圾回收。

• 垃圾收集器可以对年轻代回收，也可以对老年代回收，甚至是全栈和方法区的回收。

  • 其中，Java堆是垃圾收集器的工作重点

• 从次数上讲：

  • 频繁收集Young区
  • 较少收集Old区
  • 基本不收集Perm区（元空间）

垃圾标记阶段：对象存活判断

• 在堆里存放着几乎所有的Java对象实例，在GC执行垃圾回收之前，首先需要区分出内存中哪些是存活对象，哪些是已经死亡的对象。只有被标记为己经死亡的对象，GC才会在执行垃圾回收时，释放掉其所占用的内存空间，因此这个过程我们可以称为垃圾标记阶段。
• 那么在JVM中究竟是如何标记一个死亡对象呢？简单来说，当一个对象已经不再被任何的存活对象继续引用时，就可以宣判为已经死亡。
• 判断对象存活一般有两种方式：引用计数算法和可达性分析算法。

标记阶段：引用计数算法

1. 引用计数算法（Reference Counting）比较简单，对每个对象保存一个整型的引用计数器属性。用于记录对象被引用的情况。
2. 对于一个对象A，只要有任何一个对象引用了A，则A的引用计数器就加1；当引用失效时，引用计数器就减1。只要对象A的引用计数器的值为0，即表示对象A不可能再被使用，可进行回收。
3. 优点：实现简单，垃圾对象便于辨识；判定效率高，回收没有延迟性。
4. 缺点：
   1. 它需要单独的字段存储计数器，这样的做法增加了存储空间的开销。
   2. 每次赋值都需要更新计数器，伴随着加法和减法操作，这增加了时间开销。
   3. 引用计数器有一个严重的问题，即无法处理循环引用的情况。这是一条致命缺陷，导致在Java的垃圾回收器中没有使用这类算法。

正因为循环引用的存在，因此 Java 虚拟机不使用引用计数算法。

public class A{
    public B b;
}
public class B{
    public A a;
}
public static void main(String[] args){
    A a = new A();
    B b = new B();
    a.b = b;
    b.a = a;
}

上述案例中存在A、B两个类，A类中存在一个B类型的成员，同样B类中也存在一个A类型的成员，然后在main方法中分别创建出A、B两个类的实例对象a,b，然后让它两之间相互引用，最终产生的引用情况如下：

两个对象因为相互引用的关系，所以各自的引用计数器都会为1，因为还存在一个引用，所以导致GC器无法回收这两个对象，最终造成这两个对象所占用的空间发生内存泄露。

正是因为该问题的存在，所以Java中并没有采用这种算法作为判定对象存活的算法，而是采用了另一种可达性分析的算法实现对象存活判定。

但对于引用计数这种存活判定算法，在其他编程语言中应用也比较广泛，如Python、Redis、Perl、PHP等，它们的对象都是采用该算法进行存活判定。

标记阶段：可达性分析算法

1. 相对于引用计数算法而言，可达性分析算法不仅同样具备实现简单和执行高效等特点，更重要的是该算法可以有效地解决在引用计数算法中循环引用的问题，防止内存泄漏的发生。
2. 相较于引用计数算法，这里的可达性分析就是Java、C#选择的。这种类型的垃圾收集通常也叫作追踪性垃圾收集（Tracing Garbage Collection

基本思路如下：

• 可达性分析算法是以根对象集合（GCRoots）为起始点，按照从上至下的方式搜索被根对象集合所连接的目标对象是否可达。

• 使用可达性分析算法后，内存中的存活对象都会被根对象集合直接或间接连接着，搜索所走过的路径称为引用链（Reference Chain）。

• 如果目标对象没有任何引用链相连，则是不可达的，就意味着该对象己经死亡，可以标记为垃圾对象。

• 在可达性分析算法中，只有能够被根对象集合直接或者间接连接的对象才是存活对象。

GC Roots

GC Roots是根可达算法的基本，而在JVM运行过程中，可以被作为GC Roots的对象有如下四大类：

GC Roots可以是哪些元素？

1. 虚拟机栈中引用的对象
   • 比如：各个线程被调用的方法中使用到的参数、局部变量等。
2. 本地方法栈内JNI（通常说的本地方法）引用的对象
3. 方法区中类静态属性引用的对象
   • 比如：Java类的引用类型静态变量
4. 方法区中常量引用的对象
   • 比如：字符串常量池（StringTable）里的引用
5. 所有被同步锁synchronized持有的对象
6. Java虚拟机内部的引用。
   • 基本数据类型对应的Class对象，一些常驻的异常对象（如：NullPointerException、OutofMemoryError），系统类加载器。
7. 反映java虚拟机内部情况的JMXBean、JVMTI中注册的回调、本地代码缓存等。

对象的finalization机制

对象销毁前的回调函数：finalize()

1. Java语言提供了对象终止（finalization）机制来允许开发人员提供对象被销毁之前的自定义处理逻辑。
2. 当垃圾回收器发现没有引用指向一个对象，即：垃圾回收此对象之前，总会先调用这个对象的finalize()方法。
3. finalize() 方法允许在子类中被重写，用于在对象被回收时进行资源释放。通常在这个方法中进行一些资源释放和清理的工作，比如关闭文件、套接字和数据库连接等。

生存还是死亡？

由于finalize()方法的存在，虚拟机中的对象一般处于三种可能的状态。

1. 如果从所有的根节点都无法访问到某个对象，说明对象己经不再使用了。一般来说，此对象需要被回收。但事实上，也并非是“非死不可”的，这时候它们暂时处于“缓刑”阶段。

   一个无法触及的对象有可能在某一个条件下“复活”自己，如果这样，那么对它立即进行回收就是不合理的。为此，定义虚拟机中的对象可能的三种状态。如下：

   • 可触及的：从根节点开始，可以到达这个对象。

   • 可复活的：对象的所有引用都被释放，但是对象有可能在finalize()中复活。

   • 不可触及的：对象的finalize()被调用，并且没有复活，那么就会进入不可触及状态。不可触及的对象不可能被复活，因为finalize()只会被调用一次。

2. 以上3种状态中，是由于finalize()方法的存在，进行的区分。只有在对象不可触及时才可以被回收。

具体过程

判定一个对象objA是否可回收，至少要经历两次标记过程：

1. 如果对象objA到GC Roots没有引用链，则进行第一次标记。

2. 进行筛选，判断此对象是否有必要执行finalize()方法

   • 如果对象objA没有重写finalize()方法，或者finalize()方法已经被虚拟机调用过，则虚拟机视为“没有必要执行”，objA被判定为不可触及的。
   • 如果对象objA重写了finalize()方法，且还未执行过，那么objA会被插入到F-Queue队列中，由一个虚拟机自动创建的、低优先级的Finalizer线程触发其finalize()方法执行。
   • finalize()方法是对象逃脱死亡的最后机会，稍后GC会对F-Queue队列中的对象进行第二次标记。如果objA在finalize()方法中与引用链上的任何一个对象建立了联系，那么在第二次标记时，objA会被移出“即将回收”集合。之后，对象会再次出现没有引用存在的情况。在这个情况下，finalize()方法不会被再次调用，对象会直接变成不可触及的状态，也就是说，一个对象的finalize()方法只会被调用一次。

但需要值的注意是：

①执行过一次finalize()方法的对象再也没有机会进入到F-Queue队列中，当执行过一次之后finalize()方法不会再次被调用，对象会直接变成不可触及的状态。
②finalize()方法的执行具备不确定性，JVM只会保证对象的finalize()方法会调用，但不保证finalize()方法100%能执行完毕。比如此时，Finalizer线程正在执行一个对象finalize()方法，但是其内部的逻辑执行比较耗时，而此时堆内存严重不足（已用内存达到98%以上）时，GC会强制回收掉该队列中的对象。也就相当于finalize()方法本来是对象的最后抢救机会，结果抢救过程中因为某些意外因素，对象直接嗝屁了。

• 我们重写 finalize() 方法，然后在方法的内部，重写将其存放到 GC Roots 中。

/**
 * 测试Object类中finalize()方法，即对象的finalization机制。
 */
public class CanReliveObj {

    public static CanReliveObj obj; //类变量，属于 GC Root

    //此方法只能被调用一次
    @Override
    protected void finalize() throws Throwable {
        super.finalize();
        System.out.println("调用当前类重写的finalize()方法");
        obj = this;//当前待回收的对象在finalize()方法中与引用链上的一个对象obj建立了联系
    }

    public static void main(String[] args) {
        try {
            obj = new CanReliveObj();
            // 对象第一次成功拯救自己
            obj = null;
            System.gc();//调用垃圾回收器
            System.out.println("-----------------第一次gc操作------------");
            // 因为Finalizer线程优先级很低，暂停2秒，以等待它
            Thread.sleep(2000);
            if (obj == null) {
                System.out.println("obj is dead");
            } else {
                System.out.println("obj is still alive");
            }
            System.out.println("-----------------第二次gc操作------------");
            // 下面这段代码与上面的完全相同，但是这次自救却失败了
            obj = null;
            System.gc();
            // 因为Finalizer线程优先级很低，暂停2秒，以等待它
            Thread.sleep(2000);
            if (obj == null) {
                System.out.println("obj is dead");
            } else {
                System.out.println("obj is still alive");
            }
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }

}

• 程序运行结果

-----------------第一次gc操作------------
调用当前类重写的finalize()方法
obj is still alive
-----------------第二次gc操作------------
obj is dead

• 在进行第一次清除的时候，我们会执行 finalize() 方法，然后对象进行了一次自救操作，但是因为 finalize() 方法只会被调用一次，因此第二次该对象将会被垃圾清除。

垃圾回收算法：垃圾清除阶段

当成功区分出内存中存活对象和死亡对象后，GC接下来的任务就是执行垃圾回收，释放掉无用对象所占用的内存空间，以便有足够的可用内存空间为新对象分配内存。目前在JVM中比较常见的三种垃圾收集算法是

• 标记-清除算法（Mark-Sweep）

• 复制算法（Copying）

• 标记-压缩算法（Mark-Compact）

清除阶段：标记 - 清除

当堆中的有效内存空间（available memory）被耗尽的时候，就会停止整个程序（也被称为stop the world），然后进行两项工作，第一项则是标记，第二项则是清除

标记 - 清除算法的过程：

1. 标记：Collector从引用根节点开始遍历，标记所有被引用的对象。一般是在对象的Header中记录为可达对象。
   • 注意：标记的是被引用的对象，也就是可达对象，并非标记的是即将被清除的垃圾对象
2. 清除：Collector对堆内存从头到尾进行线性的遍历，如果发现某个对象在其Header中没有标记为可达对象，则将其回收

标记 - 清除算法的缺点：

这里所谓的清除并不是真的置空，而是把需要清除的对象地址保存在空闲的地址列表里。下次有新对象需要加载时，判断垃圾的位置空间是否够，如果够，就存放（也就是覆盖原有的地址）。

关于空闲列表是在为对象分配内存的时候提过：

可参考这篇博文：

指针碰撞和空闲列表

1. 如果内存规整
   • 采用指针碰撞的方式进行内存分配
2. 如果内存不规整
   • 虚拟机需要维护一个空闲列表
   • 采用空闲列表分配内存

清除阶段：复制

核心思想

将活着的内存空间分为两块，每次只使用其中一块，在垃圾回收时将正在使用的内存中的存活对象复制到未被使用的内存块中，之后清除正在使用的内存块中的所有对象，交换两个内存的角色，最后完成垃圾回收

复制算法的优缺点

优点

1. 没有标记和清除过程，实现简单，运行高效

2. 复制过去以后保证空间的连续性，不会出现“碎片”问题

   复制算法带来的好处是显而易见的，因为每次GC都是直接对半边区域进行回收，所以回收之后不需要考虑内存碎片的复杂情况，在内存分配时直接可以使用简单高效的 指针碰撞 方式分配对象。

缺点

1. 此算法的缺点也是很明显的，就是需要两倍的内存空间。

2. 对于G1这种分拆成为大量region的GC，复制而不是移动，意味着GC需要维护region之间对象引用关系，不管是内存占用或者时间开销也不小

   在现代高性能虚拟机中，一般都采用复制算法来收集新生代空间，因为新生代中95%左右的对象都是朝生夕死的。在HotSpot中，新生代会被划分为Eden*1、Survivor*2三个区域，但比例并非1:1，因为经过一次GC后能够依旧活着的对象是十不存一的，所以需要转移的对象并不多，所以在HotSpotVM中，三个区域的比例默认为8:1:1。当每次新生代发生GC时，就将Eden区和一块Survivor区的存活对象移动到另外一块Survivor区中，最后对Eden区和原本那块Survivor区进行全面回收。所以也就是说，HotSpot中新生代的内存最多浪费10%，最大容量为80%+10%=90%。

   但凡事没有绝对，因为在运行时，谁也不能保证每次存活的对象总量都小于新生代空间的10%，所以有时候可能会出现：另外一块Survivor区10%的空间放不下新生代的存活对象这种情况，所以此时就需要 空间分配担保机制 介入了。

   空间分配担保机制在上篇关于 JVM成神路之对象内存布局、分配过程、从生至死历程、强弱软虚引用全面剖析 中则详细探讨过，该机制是指：当Survivor空间不够用时，需要依赖于年老代进行分配担保，对Survivor空间空间中的存活对象进行动态晋升判定，把一些符合条件的对象提前转入到年老代空间中存储，以确保新生代能够空出足够的空间，确保新生代GC的正常工作。

复制算法的应用场景

1. 如果系统中的垃圾对象很多，复制算法需要复制的存活对象数量并不会太大，效率较高
2. 老年代大量的对象存活，那么复制的对象将会有很多，效率会很低
3. 在新生代，对常规应用的垃圾回收，一次通常可以回收70% - 99% 的内存空间。回收性价比很高。所以现在的商业虚拟机都是用这种收集算法回收新生代

清除阶段：标记-压缩（整理）

背景

1. 复制算法的高效性是建立在存活对象少、垃圾对象多的前提下的。这种情况在新生代经常发生，但是在老年代，更常见的情况是大部分对象都是存活对象。如果依然使用复制算法，由于存活对象较多，复制的成本也将很高。因此，基于老年代垃圾回收的特性，需要使用其他的算法。
2. 标记-清除算法的确可以应用在老年代中，但是该算法不仅执行效率低下，而且在执行完内存回收后还会产生内存碎片，所以JVM的设计者需要在此基础之上进行改进。标记-压缩（Mark-Compact）算法由此诞生。
3. 1970年前后，G.L.Steele、C.J.Chene和D.s.Wise等研究者发布标记-压缩算法。在许多现代的垃圾收集器中，人们都使用了标记-压缩算法或其改进版本。

执行过程

• 第一阶段和标记清除算法一样，从根节点开始标记所有被引用对象

• 第二阶段将所有的存活对象压缩到内存的一端，按顺序排放。

• 之后，清理边界外所有的空间。

标记-压缩算法与标记-清除算法的比较

1. 标记-压缩算法的最终效果等同于标记-清除算法执行完成后，再进行一次内存碎片整理，因此，也可以把它称为标记-清除-压缩（Mark-Sweep-Compact）算法。
2. 二者的本质差异在于标记-清除算法是一种非移动式的回收算法，标记-压缩是移动式的。是否移动回收后的存活对象是一项优缺点并存的风险决策。
3. 可以看到，标记的存活对象将会被整理，按照内存地址依次排列，而未被标记的内存会被清理掉。如此一来，当我们需要给新对象分配内存时，JVM只需要持有一个内存的起始地址即可，这比维护一个空闲列表显然少了许多开销。

标记-压缩算法的优缺点

标-整算法听来好像很不错，即解决了标-清算法的内存碎片，又解决了复制算法的空间浪费，但是标-整算法唯一的美中不足在于：它的整体收集效率并不高。因为标-整算法不仅仅要标记对象，同时还要移动存活对象，所以整个GC过程下来，它所需要耗费的时间资源开销必然是不小的。

不过一般年老代空间都是采用标-整算法，因为一方面年老代GC次数方面远没有新生代频繁，同时，晋升年老代的对象一般来说体积不会很小，所以在晋升时需要足够的内存大小分配，如果采用标-清算法会导致大对象无法进行分配，如若采用复制算法则没有新的空间为年老代提供分配担保，所以标-整算法是三者中最适用于年老代GC的。

优点

1. 消除了标记-清除算法当中，内存区域分散的缺点，我们需要给新对象分配内存时，JVM只需要持有一个内存的起始地址即可。
2. 消除了复制算法当中，内存减半的高额代价。

缺点

1. 从效率上来说，标记-整理算法要低于复制算法。
2. 移动对象的同时，如果对象被其他对象引用，则还需要调整引用的地址（因为HotSpot虚拟机采用的不是句柄池的方式，而是直接指针）
3. 移动过程中，需要全程暂停用户应用程序。即：STW

垃圾回收算法小结

• 效率上来说，复制算法是当之无愧的老大，但是却浪费了太多内存。

• 而为了尽量兼顾上面提到的三个指标，标记-整理算法相对来说更平滑一些，但是效率上不尽如人意，它比复制算法多了一个标记的阶段，比标记-清除多了一个整理内存的阶段。

标记清除	标记整理	复制
速率	中等	最慢	最快
空间开销	少（但会堆积碎片）	少（不堆积碎片）	通常需要活对象的2倍空间（不堆积碎片）
移动对象	否	是	是

分代收集算法

为什么要使用分代收集算法

1. 前面所有这些算法中，并没有一种算法可以完全替代其他算法，它们都具有自己独特的优势和特点。分代收集算法应运而生。
2. 分代收集算法，是基于这样一个事实：**不同的对象的生命周期是不一样的。因此，不同生命周期的对象可以采取不同的收集方式，以便提高回收效率。**一般是把Java堆分为新生代和老年代，这样就可以根据各个年代的特点使用不同的回收算法，以提高垃圾回收的效率。
3. 在Java程序运行的过程中，会产生大量的对象，其中有些对象是与业务信息相关:
   • 比如Http请求中的Session对象、线程、Socket连接，这类对象跟业务直接挂钩，因此生命周期比较长。
   • 但是还有一些对象，主要是程序运行过程中生成的临时变量，这些对象生命周期会比较短，比如：String对象，由于其不变类的特性，系统会产生大量的这些对象，有些对象甚至只用一次即可回收。

目前几乎所有的GC都采用分代收集算法执行垃圾回收的

在HotSpot中，基于分代的概念，GC所使用的内存回收算法必须结合年轻代和老年代各自的特点。

1. 年轻代（Young Gen）
   • 年轻代特点：区域相对老年代较小，对象生命周期短、存活率低，回收频繁。
   • 这种情况复制算法的回收整理，速度是最快的。复制算法的效率只和当前存活对象大小有关，因此很适用于年轻代的回收。而复制算法内存利用率不高的问题，通过hotspot中的两个survivor的设计得到缓解。
2. 老年代（Tenured Gen）
   • 老年代特点：区域较大，对象生命周期长、存活率高，回收不及年轻代频繁。
   • 这种情况存在大量存活率高的对象，复制算法明显变得不合适。一般是由标记-清除或者是标记-清除与标记-整理的混合实现。
     • Mark阶段的开销与存活对象的数量成正比。
     • Sweep阶段的开销与所管理区域的大小成正相关。
     • Compact阶段的开销与存活对象的数据成正比。
3. 以HotSpot中的CMS回收器为例，CMS是基于Mark-Sweep实现的，对于对象的回收效率很高。对于碎片问题，CMS采用基于Mark-Compact算法的Serial Old回收器作为补偿措施：当内存回收不佳（碎片导致的Concurrent Mode Failure时），将采用Serial Old执行Full GC以达到对老年代内存的整理。
4. 分代的思想被现有的虚拟机广泛使用。几乎所有的垃圾回收器都区分新生代和老年代

增量收集算法

背景

上述现有的算法，在垃圾回收过程中，应用软件将处于一种Stop the World的状态。在Stop the World状态下，应用程序所有的线程都会挂起，暂停一切正常的工作，等待垃圾回收的完成。如果垃圾回收时间过长，应用程序会被挂起很久，将严重影响用户体验或者系统的稳定性。为了解决这个问题，即对实时垃圾收集算法的研究直接导致了增量收集（Incremental Collecting）算法的诞生

增量收集算法基本思想

1. 如果一次性将所有的垃圾进行处理，需要造成系统长时间的停顿，那么就可以让垃圾收集线程和应用程序线程交替执行。每次，垃圾收集线程只收集一小片区域的内存空间，接着切换到应用程序线程。依次反复，直到垃圾收集完成。
2. 总的来说，增量收集算法的基础仍是传统的标记-清除和复制算法。增量收集算法通过对线程间冲突的妥善处理，允许垃圾收集线程以分阶段的方式完成标记、清理或复制工作

增量收集算法的缺点

使用这种方式，由于在垃圾回收过程中，间断性地还执行了应用程序代码，所以能减少系统的停顿时间。但是，因为线程切换和上下文转换的消耗，会使得垃圾回收的总体成本上升，造成系统吞吐量的下降。

分区算法

1. 一般来说，在相同条件下，堆空间越大，一次GC时所需要的时间就越长，有关GC产生的停顿也越长。为了更好地控制GC产生的停顿时间，将一块大的内存区域分割成多个小块，根据目标的停顿时间，每次合理地回收若干个小区间，而不是整个堆空间，从而减少一次GC所产生的停顿。
2. 分代算法将按照对象的生命周期长短划分成两个部分，分区算法将整个堆空间划分成连续的不同小区间。每一个小区间都独立使用，独立回收。这种算法的好处是可以控制一次回收多少个小区间。

STW（stop the world）世界暂停

在前面介绍GC算法时曾提到过，在发生GC时会停下所有的用户线程，从而导致Java程序出现全局停顿的无响应情况，而这种情况则被称为STW（Stop The World）世界暂停。在发生STW之后，所有的Java代码会停止运行，不过native代码是可以继续执行的，但也不能和JVM交互。一般发生STW都是由于GC引起的，但在某几种少数情况下，也会导致STW出现，如线程Dump、死锁检查、堆日志Dump等。

GC发生时为什么需要STW？

GC发生时为什么都必须要STW呢？这主要有两个原因，一个是尽量为了避免浮动垃圾产生，第二个则是为了确保一致性。

避免产生浮动垃圾

如果在GC发生时不停下用户线程，那么会导致这么一种情况出现，就是刚刚标记完成一块区域中的对象，但转眼用户线程又在该区域中产生了新的“垃圾”。举个例子：

好比你生日聚会，聚会搞得屋子很乱，所以有人需要过来打扫卫生，但保洁人员刚扫完这边，那边又被搞乱了，又跑过去扫完那边之后，这边又被搞乱了，最终导致房间永远无法打扫干净。为了避免在打扫过程中产生“浮动垃圾”，就只能选择让所有聚会人员全部停止活动，这样才能确保最终屋子能够打扫干净。

同时，如果在GC发生时不做全局停顿，带来的后果则是：会给GC线程造成很大的负担，GC算法的实现难度也会增加，因为GC机制很难去准确判断哪些是垃圾。

确保内存一致性

在GC发生时，可达性分析算法的工作必须要在一个能够确保一致性的内存快照中进行。也就是指：在整个分析期间，JVM看起来就像被冻结在某个时间点上，不可以出现分析过程中对象引用关系还在不断变化的情况，该点不满足的话分析结果的准确性无法得到保证。这也是GC进行时，必须停止所有用户线程的其中一个重要原因。

STW会带来什么问题？

不过STW也会带来一些问题，比如导致客户端长时间无响应、HA（高可用）系统中的主从切换脑裂、上游系统宕机等。

客户端长时间无响应问题

因为STW发生时，会停止所有用户线程，所以对于客户端发送过来的网络请求并没有线程处理，最终导致客户端那边一直“转圈等待”，STW不结束，则客户端会一直处于无响应状态。

HA系统中的主从切换脑裂问题

同时如果你的系统做了主备、主从、多活等HA方案，那么如果主机触发GC发生STW，最终造成主机长时间停顿，而备机会监测到主机没有工作，于是备机开始尝试将流量切换到自身来处理，从备机变为了主机。
但旧主不工作只是暂时的，因为GC的原因导致暂停一段时间，而当GC完成后，旧主会依旧开始工作，最终造成了整个HA系统中出现了双主情况，形成了脑裂问题，最终影响生产环境。

上游系统宕机问题

如果你的系统是以多机器部署的工程项目，那么如果当某个工程所在的机器发送GC出现STW时，那么上游系统过来的请求则不会处理，如果STW时间一长，最终很有可能导致上游机器扛不住流量而出现宕机。

其实STW在线上环境时，绝大多数情况下并不会出现这些问题，因为一般来说，GC发生时STW的时间是比较短暂的，同时现在的GC器也都在追求高吞吐与低延迟，所以你几乎很难遇到线上长时间的STW出现。

GC类型划分

JVM在发生GC时，主要作用的区域有三个：新生代、年老代以及元数据空间，当然，程序运行期间，绝对多数GC都是在回收新生代。一般而言，GC可以分为四种类型，如下：

• ①新生代收集：只针对新生代的GC，当Eden区满了时触发，Survivor满了并不会触发。
• ②年老代收集：针对年老代空间的GC，不过目前只有CMS存在单独回收年老代的行为。
• ③混合收集：指收集范围覆盖整个新生代空间及部分年老代空间的GC，目前只有G1存在该行为。
• ④全面收集：覆盖新生代、年老代以及元数据空间的GC，会对于所有可发生GC的内存进行收集。

新生代收集（MinorGC/YoungGC）

发生在新生代的GC也被称为MinorGC或YoungGC，在JVM中，发生次数最多的也就是新生代GC，毕竟新生代中的对象都是朝生夕死的，也是分配最为频繁的，所以新生代GC也是触发最频繁的。不过新生代GC只有Eden区满了才会触发，而Survivor区满了后是不会触发的。对于大部分Java程序而言，新生代GC造成的STW停顿几乎可以忽略不计，因为新生代GC只需要标记出垃圾对象即可，对于存活对象移动的工作量是比较小的。

年老代收集（Major GC/Old GC）

当老年代满时会触发MajorGC，当然在有些地方也被称为OldGC，但一般而言，年老代GC触发时往往都会伴随新生代GC一起发生，只有CMS收集器会有单独收集年老代空间的行为，其他收集器均无此行为。

混合收集（MixedGC）

混合收集MixedGC是指收集范围覆盖整个新生代空间及部分年老代空间的GC，但目前只有G1存在该行为，其他收集器均不支持，因为G1收集器是逻辑分代，物理分区的结构，所以可以针对于不同的分区进行单独的收集，在发生GC时，可以选取新生代分区+部分年老代分区进行回收。

全面收集（FullGC）

全面收集也被称为FullGC，是所有GC类型中，耗时最长、停顿最久的GC，FullGC会对于所有可发生GC的区域进行全面回收，其中涵盖新生代、年老代以及元数据空间，而一般触发FullGC的原因有如下几种：

• ①调用System.gc()时，JVM在内存占用较多时会尝试发生FullGC，但并非100%触发。
• ②除CMS之外收集器，当年老代不足时也会触发FullGC。
• ③元数据空间内存不足时，也会触发FullGC。
• ④对象晋升时年老代空间无法承载晋升对象时也会触发FullGC。
• ⑤新生代空间分配担保机制触发时，也会先触发FullGC。

安全点与安全区域

从前面的阐述中不难得知的一个结论：当GC发生时，必然会出现程序停顿，也就是需要停止所有用户线程。但问题在于：用户线程停止的时机必须合理，不然在恢复线程后，有可能会导致最终的执行结果出现不一致，因此用户线程必然需要在一个安全的位置暂停。

而在JVM中，存在两个概念：安全点和安全区域，当用户线程执行到安全点或安全区域的代码处，此时发生停止是安全的，后续再次唤醒线程工作时，执行结果也不会因为线程暂停而受到任何影响。

安全点(SafePoint)

无论是在GC中还是并发编程中，都会经常出现安全点这个概念，因为当我们需要阻塞停止一条线程时，都需要在安全点停止，简单说安全点就是指当线程运行到这类位置时，堆对象状态是确定一致的，线程停止后，JVM可以安全地进行操作，如GC、偏向锁撒销等。

而JVM中对于安全点的定义主要有如下几种：

• ①循环结束的末尾段
• ②方法调用之后
• ③抛出异常的位置
• ④方法返回之前

当JVM需要发生GC、偏向锁撤销等操作时，如何才能让所有线程到达安全点阻塞或停止？

• ①主动式中断(JVM采用的方式)：不中断线程，而是设置一个标志，而后让每条线程执行时主动轮询这个标志，当一个线程到达安全点后，发现中断标志为true时就自己中断挂起。
• ②抢断式中断：先中断所有线程，如果发现线程未执行到安全点则恢复线程让其运行到安全点位置。

安全区域(SafeRegion)

当Java程序需要停下所有用户线程时，某些线程可能处于中断或者休眠状态，从而无法响应JVM的中断请求走到安全点位置挂起了，所以出现了安全区域的概念。

安全区域是指一条线程执行到一段代码时，该区域的代码不会改变堆中对象的引用。在这区域内JVM可以安全地进行操作。当线程进入到该区域时需要先标识自己进入了，这样GC线程则不会管这些已标识的线程，当线程要离开这个区域时需要先判断可达性分析是否完成，如果完成了则往下执行，如果没有则需要原地等待到GC线程发出安全离开信息为止。
抛出异常的位置

• ④方法返回之前

当JVM需要发生GC、偏向锁撤销等操作时，如何才能让所有线程到达安全点阻塞或停止？

• ①主动式中断(JVM采用的方式)：不中断线程，而是设置一个标志，而后让每条线程执行时主动轮询这个标志，当一个线程到达安全点后，发现中断标志为true时就自己中断挂起。
• ②抢断式中断：先中断所有线程，如果发现线程未执行到安全点则恢复线程让其运行到安全点位置。

安全区域(SafeRegion)

当Java程序需要停下所有用户线程时，某些线程可能处于中断或者休眠状态，从而无法响应JVM的中断请求走到安全点位置挂起了，所以出现了安全区域的概念。

安全区域是指一条线程执行到一段代码时，该区域的代码不会改变堆中对象的引用。在这区域内JVM可以安全地进行操作。当线程进入到该区域时需要先标识自己进入了，这样GC线程则不会管这些已标识的线程，当线程要离开这个区域时需要先判断可达性分析是否完成，如果完成了则往下执行，如果没有则需要原地等待到GC线程发出安全离开信息为止。