Java `Safepoints` `Stop-the-World` (STW) 机制与 `JVM` 停顿原因 - 智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座

各位观众老爷们，晚上好！我是你们的老朋友，今天咱们来聊聊Java虚拟机里那些让人又爱又恨的“暂停时刻”——Safepoint和Stop-the-World。别怕，这玩意儿虽然听起来玄乎，但其实就像你打游戏时的“存档点”，只不过是JVM在默默地帮你存档，然后悄悄地干点活儿。

开场白：JVM的“小憩”与“深度睡眠”

想象一下，JVM就像一个不知疲倦的工人，日夜不停地运行你的Java代码。但是，再牛的工人也需要休息，需要偶尔停下来整理工具，打扫卫生，甚至需要来个深度睡眠，好好检修一下机器。这些“休息”和“睡眠”，就是我们今天要说的Safepoint和Stop-the-World。

Safepoint，我们可以理解为JVM的“小憩”，它允许JVM在特定的代码位置安全地暂停所有线程，进行一些必要的操作，比如垃圾回收（GC）、偏向锁撤销等等。而Stop-the-World（STW），则是JVM的“深度睡眠”，在这个期间，所有用户线程都会被暂停，直到JVM完成一些重要的任务，比如Full GC。

Safepoint：JVM的“存档点”

先说说Safepoint。这玩意儿就好比你玩游戏时的存档点。JVM会在代码的特定位置插入Safepoint，当需要暂停所有线程时，JVM会等待所有线程都到达这些Safepoint，然后统一暂停。

Safepoint的类型

Safepoint可以分为以下几种类型：
- GC Safepoint： 用于垃圾回收。这是最常见的Safepoint类型。
- Stack Walking Safepoint： 用于线程堆栈的遍历，例如ThreadDump。
- Revoke Bias Safepoint： 用于撤销偏向锁。
- VM Operation Safepoint： 用于执行一些VM操作，例如代码卸载。
Safepoint的插入位置

JVM并不是在所有代码位置都插入Safepoint。为了性能考虑，Safepoint通常只插入在以下位置：
- 方法返回之前： 确保方法执行完毕，可以安全地清理栈帧。
- 循环的开头： 避免长时间循环导致无法进入Safepoint。
- 调用其他方法之前： 方便进行方法间的状态切换。
- 一些特殊指令之前： 例如，可能引起竞争的指令。
简而言之，JVM会尽量选择那些对性能影响较小，但又能保证安全的位置插入Safepoint。
Safepoint的实现机制

JVM使用一种叫做“Safe-Point Polling”的机制来实现Safepoint。简单来说，就是JVM会在每个线程的执行路径上插入一些“检查点”，线程会定期检查这些检查点，看是否需要进入Safepoint。如果需要，线程就会主动暂停自己，等待JVM的指令。

这个“检查点”通常是通过向内存中的某个特定地址写入一个值来实现的。如果这个值发生了变化，线程就知道需要进入Safepoint了。
```
// 伪代码，用于说明Safepoint polling的原理
while (true) {
    // 执行一些代码
    doSomething();

    // 检查是否需要进入Safepoint
    if (safepoint_flag) { // safepoint_flag是一个全局变量，由JVM控制
        // 进入Safepoint
        enterSafepoint();
    }
}
```
代码示例：查看Safepoint相关信息

我们可以使用jstat命令来查看Safepoint相关的信息。例如：
```
jstat -gcutil <pid> 1000 10
```
这个命令会每隔1秒输出一次GC相关的信息，包括Safepoint的等待时间和执行时间。

其中，STW 列表示 Stop-The-World 的时间（以秒为单位），SCT 列表示进入 Safepoint 的次数。

Stop-the-World：JVM的“深度睡眠”

Stop-the-World，顾名思义，就是停止整个世界。在这个期间，所有的用户线程都会被暂停，只有JVM自己的线程可以运行。

STW的原因

STW通常发生在以下几种情况下：
- Full GC： 为了彻底清理堆内存，JVM需要暂停所有线程，进行全局的垃圾回收。
- Heap Dump： 为了生成堆转储文件，JVM需要暂停所有线程，确保堆内存的状态一致。
- Thread Dump： 为了生成线程转储文件，JVM需要暂停所有线程，收集线程的状态信息。
- JIT Compilation： 虽然通常是并发的，但在某些情况下，JIT编译也可能导致STW。
- Class Loading： 加载某些类的时候可能会导致STW。
STW的影响

STW会导致应用程序的响应时间变长，甚至出现卡顿现象。因此，我们需要尽量避免STW的发生，或者缩短STW的时间。
优化STW的方法

有很多方法可以优化STW的时间，例如：
- 选择合适的垃圾回收器： 不同的垃圾回收器有不同的STW时间。例如，G1垃圾回收器可以控制STW的时间，CMS垃圾回收器在大部分时间是并发执行的。
- 调整堆内存的大小： 堆内存过大或过小都可能导致STW时间变长。
- 优化代码： 避免创建过多的临时对象，减少垃圾回收的频率。
- 使用并发的数据结构： 并发的数据结构可以减少线程之间的竞争，从而减少STW的发生。
- 增加CPU核心数： 增加CPU核心数可以提高垃圾回收的效率，从而缩短STW的时间。

代码示例：模拟STW

虽然我们不能直接控制JVM的STW，但是我们可以通过一些手段来模拟STW的发生。例如，我们可以创建一个长时间运行的线程，并且不断地分配内存，从而触发GC，导致STW。

import java.util.ArrayList;
import java.util.List;

public class STWSimulator {

    public static void main(String[] args) throws InterruptedException {
        System.out.println("模拟STW开始...");

        // 创建一个长时间运行的线程
        Thread thread = new Thread(() -> {
            List<Object> list = new ArrayList<>();
            while (true) {
                // 不断地分配内存
                for (int i = 0; i < 1000; i++) {
                    list.add(new byte[1024 * 1024]); // 1MB
                }

                // 模拟一些业务逻辑
                try {
                    Thread.sleep(1);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        });

        thread.start();

        // 主线程也执行一些操作
        for (int i = 0; i < 10; i++) {
            System.out.println("主线程执行中... " + i);
            Thread.sleep(2000);
        }

        System.out.println("模拟STW结束...");
    }
}

运行这段代码，我们可以观察到GC的频率会比较高，并且可能会出现STW。

JVM停顿原因：不仅仅是GC

虽然GC是导致STW的最常见原因，但它并不是唯一的罪魁祸首。还有很多其他因素可能导致JVM停顿，例如：

JIT Compilation： JIT编译器在将字节码编译成本地代码时，可能会导致STW。虽然现代的JVM通常会使用并发的JIT编译器，但在某些情况下，仍然可能出现STW。
Class Loading： 加载类时，JVM需要进行一些初始化操作，这可能会导致STW。特别是加载大量的类时，STW的时间可能会比较长。
Thread Stack Dump： 使用jstack命令或者一些监控工具生成线程转储文件时，JVM需要暂停所有线程，收集线程的状态信息，这会导致STW。
Heap Dump： 使用jmap命令或者一些监控工具生成堆转储文件时，JVM需要暂停所有线程，确保堆内存的状态一致，这会导致STW。
System.gc()： 调用System.gc()方法会建议JVM进行垃圾回收，这可能会导致Full GC，从而导致STW。但是，JVM并不一定会响应System.gc()的调用。
Biased Locking Revocation： 偏向锁撤销也可能导致STW。

下面是一个表格，总结了常见的JVM停顿原因：

停顿原因	描述	优化方法
Full GC	为了彻底清理堆内存，JVM需要暂停所有线程，进行全局的垃圾回收。	选择合适的垃圾回收器（例如G1），调整堆内存大小，优化代码，减少临时对象的创建，使用并发的数据结构。
JIT Compilation	JIT编译器在将字节码编译成本地代码时，可能会导致STW。	优化代码，减少JIT编译的频率，使用tiered compilation，调整JIT编译器的参数。
Class Loading	加载类时，JVM需要进行一些初始化操作，这可能会导致STW。	减少类的数量，优化类的加载顺序，使用类加载器缓存。
Thread Stack Dump	使用`jstack`命令或者一些监控工具生成线程转储文件时，JVM需要暂停所有线程，收集线程的状态信息，这会导致STW。	尽量减少生成线程转储文件的频率，使用异步的线程转储工具。
Heap Dump	使用`jmap`命令或者一些监控工具生成堆转储文件时，JVM需要暂停所有线程，确保堆内存的状态一致，这会导致STW。	尽量减少生成堆转储文件的频率，使用增量的堆转储工具。
System.gc()	调用`System.gc()`方法会建议JVM进行垃圾回收，这可能会导致Full GC，从而导致STW。	尽量避免使用`System.gc()`方法，让JVM自己决定何时进行垃圾回收。
Biased Locking Revocation	偏向锁撤销也可能导致STW。	减少线程之间的竞争，优化锁的使用。
VM Operation	执行一些VM操作，如代码卸载，也可能导致STW。	尽量减少动态代码卸载操作。

如何诊断JVM停顿问题

诊断JVM停顿问题需要一些工具和技巧。以下是一些常用的方法：

GC日志： GC日志记录了垃圾回收的详细信息，包括GC的类型、时间、频率等等。通过分析GC日志，我们可以了解GC是否是导致STW的主要原因。
jstat： jstat命令可以实时监控JVM的运行状态，包括GC、类加载、JIT编译等等。通过jstat，我们可以快速了解JVM的整体运行状况。
jstack： jstack命令可以生成线程转储文件，通过分析线程转储文件，我们可以了解线程的状态，从而找到导致停顿的线程。
jmap： jmap命令可以生成堆转储文件，通过分析堆转储文件，我们可以了解堆内存的使用情况，从而找到导致GC的原因。
VisualVM： VisualVM是一个图形化的JVM监控工具，它可以实时监控JVM的运行状态，并且可以生成线程转储文件和堆转储文件。
Arthas： Arthas是一个强大的Java诊断工具，它可以实时监控JVM的运行状态，并且可以执行各种诊断命令，例如查看线程状态、查看堆内存使用情况、动态修改代码等等。

总结：与“暂停”共舞

Safepoint和Stop-the-World是JVM为了保证自身运行的稳定性和效率而采取的一种机制。虽然STW会对应用程序的响应时间产生影响，但是通过选择合适的垃圾回收器、调整堆内存的大小、优化代码等等手段，我们可以尽量避免STW的发生，或者缩短STW的时间。

记住，了解JVM的底层机制，才能更好地优化我们的应用程序，与这些“暂停时刻”和谐共舞！

今天的讲座就到这里，感谢各位的收听！希望对大家有所帮助。下次有机会再和大家分享其他有趣的Java技术话题！

发表回复 取消回复

发表回复取消回复