结构化并发（Structured Concurrency） 最初由 JEP 428 提出，并在 JDK 19 中作为孵化 API 发布，接着又在 JDK 20 中通过 JEP 437 再次孵化，现在该特性进入预览版本了。结构化并发是一种多线程编程方法，它将在不同线程中运行的相关任务组视为单个工作单元，从而简化错误处理和取消操作，提高程序的可靠性和可观察性。

结构化并发和虚拟线程、作用域值一样，都是由 Loom 项目发展而来。

那么到底什么是结构化并发呢？我们不妨从结构化编程的概念开始聊起。

结构化编程（Structured Programming）

计算机发展的早期，程序员必须使用很低级的编程语言去写程序，比如汇编语言，通过一条条的硬件指令去操作计算机，这种编程方式非常痛苦；于是一些计算机界大佬便开始着手重新设计编程语言，使用类似英语的语句来表达操作，这就诞生了一批比汇编语言稍微高级一点的编程语言，如 FORTRAN、FLOW-MATIC、COBOL 等。

这些语言和现在我们所使用的 Java 或者 C 等高级语言还是有一些差距的，没有函数代码块，没有条件或循环控制语句，这些现在看来稀松平常的特性当时还没有被发明出来。设想一下如果程序只能从上往下顺序执行，那么我们就不能复用之前已经编写过的逻辑，想要重新执行一遍之前的逻辑，就得把前面的代码重写一遍，很显然这是非常麻烦的，所以一些设计者在语言中加入了 GOTO 语句，可以让程序在执行时跳转到指定位置，从而实现代码复用。

GOTO 语句的发明使得编程语言变得更加强大，但是这种跳转执行的逻辑使得程序充满了不确定性，一旦程序中大量使用了 GOTO 语句，整个代码就会变得一团糟：

这种代码如同面条一般，所以被形象地戏称为 面条式代码（Spaghetti Code）。

1968 年 3 月，荷兰计算机科学家 Edsger W. Dijkstra 发表了一篇文章 Goto Statement Considered Harmful，提出了著名的 GOTO 有害论；后来，他又编写了一部札记 Notes on Structured Programming，通过大量的篇幅详细阐述了他理想中的编程范式，首次提出了 结构化编程（Structured Programming） 的概念。

结构化编程的核心思想是 基于块语句，实现代码逻辑的抽象与封装，从而保证控制流拥有单一的入口与出口，现代编程语言中的条件语句、循环语句、方法调用都是结构化编程的体现，我们基于现代编程语言所编写的程序，基本上都是结构化的。

相比 GOTO 语句，结构化编程使代码逻辑变得更加清晰，思维模型变得更加简单；如今，大部分现代编程语言都已经禁用 GOTO 语句，尽管 break 和 continue 语句仍然可以实现跳转逻辑，但是他们还是遵循结构化的基本原则：控制流拥有单一的入口与出口。

少部分编程语言仍然支持 GOTO，但是它们大都遵循高德纳所提出的前进分支和后退分支不得交叉的原则。

结构化并发（Structured Concurrency）

了解了结构化编程的历史后，我们再来看看什么是结构化并发。假设我们有两个独立的任务 task1 和 task2 需要执行，由于它们之间互不影响，我们可以使用 ExecutorService 来并发执行：

private static void testExecutorService() throws Exception {
  System.out.println("main thread start");
  ExecutorService executor = Executors.newCachedThreadPool();
  Future<Integer> f1 = executor.submit(() -> task1(0));
  Future<Integer> f2 = executor.submit(() -> task2(0));
  System.out.println(f1.get());
  System.out.println(f2.get());
  System.out.println("main thread end");
  executor.shutdown();
}

通过 submit 提交任务，并通过 get 等待任务执行结束，代码非常简单，整个流程也非常顺利。然而，真实情况却未必如此，由于子任务并发执行，每个子任务都可能成功或失败，当某个子任务失败时，我们要考虑的事情可能会变得出乎意料地复杂：

• 如果 task1 运行失败，那么在调用 f1.get() 时会抛出异常，但 task2 将继续在其自己的线程中运行，这是一种线程泄漏，不仅浪费资源，而且可能会干扰其他任务；
• 如果 task2 运行失败，由于先执行 f1.get()，会阻塞等待 task1 运行结束才会执行 f2.get() 抛出异常，task1 可能会执行很久，这是一种不必要的等待；
• 如果主线程被中断，该中断不会传播到子任务中，task1 和 task2 线程都会泄漏；
• 另一种场景中，如果我们只需要 task1 和 task2 中的任意一个结果，这又该如何实现？

其实以上这些场景都可以实现，但需要极其复杂、难以维护的代码，比如 这里 使用 CompletableFuture 演示了三个子任务之间互相取消的场景，其代码的复杂程度应该会吓坏不少人。

此外，这类代码也不好调试，通过线程转储，我们会得到一堆名为 “pool-X-thread-Y” 的线程，我们无法知道哪个子线程属于哪个主线程，每个子线程的运行就像非结构化编程中的 GOTO 一样，不知道会跳转到哪里。这种情况被称为 非结构化并发（Unstructured Concurrency）。我们的任务在一张错综复杂的线程网中运行，其开始与结束在代码中难以察觉，缺乏清晰的错误处理机制，当主线程结束时，常常会出现孤立线程的情况。

结构化并发（Structured Concurrency） 正是为解决这些问题而提出的，它的核心思想和结构化编程一样：在并发模型下，也要保证控制流拥有单一的入口与出口。程序可以产生多个子线程来实现并发，但是所有子线程最终都要在统一的出口处完成合并：

使用结构化并发有着诸多好处：

• 在出口处，所有子线程都应该处于完成或取消状态，所以子线程的开始和结束变得清晰可见，这使得代码更易于阅读和维护；
• 子线程发生的错误能传播到父线程中，父线程的取消也能传播到子线程中，从而简化了线程之间的错误处理和状态控制；
• 另外，线程转储还可以保持父线程与子线程之间的调用层次结构，增强了可观察性，有助于程序调试。

使用 StructuredTaskScope 实现结构化并发

在 Java 中，实现结构化并发的基本 API 是 StructuredTaskScope，它的基本用法如下：

private static void testStructuredTaskScope() throws Exception {
  System.out.println("main thread start");
  try (var scope = new StructuredTaskScope<Object>()) {
    Subtask<Integer> t1 = scope.fork(() -> task1(0));
    Subtask<Integer> t2 = scope.fork(() -> task2(0));
    scope.join();
    System.out.println(t1.get());
    System.out.println(t2.get());
  }
  System.out.println("main thread end");
}

这里实现了和之前代码同样的逻辑，只是写法上略有区分，我们将 ExecutorService 替换为 StructuredTaskScope，并将 executor.submit() 替换为 scope.fork()，然后使用 scope.join() 等待所有任务完成。之后，我们可以通过 Subtask.get() 读取子任务的结果，如果某个子任务发生异常，Subtask.get() 会抛出 IllegalStateException 异常。因此，在调用 get() 之前，最好先用 state() 查询子任务的状态：

if (t1.state() == Subtask.State.SUCCESS) {
  System.out.println(t1.get());
} else {
  System.out.println("task1 error: " + t1.exception().getMessage());
}

StructuredTaskScope 的关闭策略

scope.join() 可以保证所有子线程全部处于完成或取消状态，这样可以消除孤儿线程的风险。但是在有些场景下，如果某个子线程异常，等待其他子任务的结果就没有了意义，这时我们可以取消其他子任务，避免无谓的等待；还有些情况是，只要有一个子任务运行成功即可，无需等待所有任务都运行结束。这就引出了 StructuredTaskScope 的 关闭策略（Shutdown policies），StructuredTaskScope 定义了两种关闭策略，分别处理这两种情况：

ShutdownOnFailure 策略

使用 ShutdownOnFailure 策略，当某个子任务中发生异常时，将导致所有其他子任务终止。它的使用方法如下所示：

private static void testStructuredTaskScopeShutdownOnFailure() throws Exception {
  System.out.println("main thread start");
  try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
    Subtask<Integer> t1 = scope.fork(() -> task1(1));
    Subtask<Integer> t2 = scope.fork(() -> task2(0));
    scope.join().throwIfFailed();
    System.out.println(t1.get());
    System.out.println(t2.get());
  }
  System.out.println("main thread end");
}

首先，我们使用 new StructuredTaskScope.ShutdownOnFailure() 创建一个 ShutdownOnFailure 策略的 StructuredTaskScope，然后在 scope.join() 的时候，通过 throwIfFailed() 让其在子任务失败时抛出异常。假设 task1 异常，运行结果如下：

main thread start
task1 start
task2 start
java.lang.InterruptedException
  at java.base/java.lang.VirtualThread.sleepNanos(VirtualThread.java:805)
  at java.base/java.lang.Thread.sleep(Thread.java:507)
  at StructuredConcurrencyDemo.task2(StructuredConcurrencyDemo.java:91)
  at StructuredConcurrencyDemo.lambda$9(StructuredConcurrencyDemo.java:130)
  at java.base/java.util.concurrent.StructuredTaskScope$SubtaskImpl.run(StructuredTaskScope.java:889)
  at java.base/java.lang.VirtualThread.run(VirtualThread.java:311)
task2 end
Exception in thread "main" java.util.concurrent.ExecutionException: java.lang.RuntimeException: code is illegal
  at java.base/java.util.concurrent.StructuredTaskScope$ShutdownOnFailure.throwIfFailed(StructuredTaskScope.java:1318)
  at java.base/java.util.concurrent.StructuredTaskScope$ShutdownOnFailure.throwIfFailed(StructuredTaskScope.java:1295)
  at StructuredConcurrencyDemo.testStructuredTaskScopeShutdownOnFailure(StructuredConcurrencyDemo.java:131)
  at StructuredConcurrencyDemo.main(StructuredConcurrencyDemo.java:14)
Caused by: java.lang.RuntimeException: code is illegal
  at StructuredConcurrencyDemo.task1(StructuredConcurrencyDemo.java:74)
  at StructuredConcurrencyDemo.lambda$8(StructuredConcurrencyDemo.java:129)
  at java.base/java.util.concurrent.StructuredTaskScope$SubtaskImpl.run(StructuredTaskScope.java:889)
  at java.base/java.lang.VirtualThread.run(VirtualThread.java:311)

可以看到当 task1 异常时，task2 出现了 InterruptedException，说明 task2 被中断了，从而避免了无谓的等待。

ShutdownOnSuccess 策略

使用 ShutdownOnSuccess 策略，只要某个子任务中成功，将导致所有其他子任务终止。它的使用方法如下所示：

private static void testStructuredTaskScopeShutdownOnSuccess() throws Exception {
  System.out.println("main thread start");
  try (var scope = new StructuredTaskScope.ShutdownOnSuccess<Object>()) {
    scope.fork(() -> task1(0));
    scope.fork(() -> task2(0));
    scope.join();
    System.out.println(scope.result());
  }
  System.out.println("main thread end");
}

首先，我们使用 new StructuredTaskScope.ShutdownOnSuccess<Object>() 创建一个 ShutdownOnSuccess 策略的 StructuredTaskScope，然后通过 scope.join() 等待子任务结束，任意一个子任务结束，整个 StructuredTaskScope 都会结束，并保证其他子任务被取消，最后通过 scope.result() 获取第一个运行成功的子任务结果。运行结果如下：

main thread start
task1 start
task2 start
task2 end
2
java.lang.InterruptedException
  at java.base/java.lang.VirtualThread.sleepNanos(VirtualThread.java:805)
  at java.base/java.lang.Thread.sleep(Thread.java:507)
  at StructuredConcurrencyDemo.task1(StructuredConcurrencyDemo.java:78)
  at StructuredConcurrencyDemo.lambda$10(StructuredConcurrencyDemo.java:142)
  at java.base/java.util.concurrent.StructuredTaskScope$SubtaskImpl.run(StructuredTaskScope.java:889)
  at java.base/java.lang.VirtualThread.run(VirtualThread.java:311)
task1 end
main thread end

可以看到当 task2 最先运行结束，所以输出了 task2 的结果，同时 task1 出现了 InterruptedException，说明 task1 被中断了，避免了线程泄露。

自定义关闭策略

如果这两个标准策略都不满足你的需求，我们还可以编写自定义的策略，通过继承 StructuredTaskScope 类，并重写其 handleComplete(...) 方法，从而实现不同于 ShutdownOnSuccess 和 ShutdownOnFailure 的策略。这里 有一个自定义关闭策略的示例可供参考。

可观察性

使用结构化并发的另一个好处是，线程是有层次结构的，我们可以从线程转储中看到某个主线程都派生了哪些子线程，也可以看出某个子线程来自于哪个主线程，从而方便问题排查。使用下面的命令以 JSON 格式进行线程转储：

$ jcmd <pid> Thread.dump_to_file -format=json threads.json

从转储结果中可以清晰的看到线程之间的层次结构：

{
  "container": "java.util.concurrent.StructuredTaskScope$ShutdownOnSuccess@58644d46",
  "parent": "<root>",
  "owner": "1",
  "threads": [
    {
      "tid": "19",
      "name": "",
      "stack": [
        "java.base\/java.lang.VirtualThread.parkNanos(VirtualThread.java:631)",
        "java.base\/java.lang.VirtualThread.sleepNanos(VirtualThread.java:803)",
        "java.base\/java.lang.Thread.sleep(Thread.java:507)",
        "StructuredConcurrencyDemo.task1(StructuredConcurrencyDemo.java:78)",
        "StructuredConcurrencyDemo.lambda$10(StructuredConcurrencyDemo.java:142)",
        "java.base\/java.util.concurrent.StructuredTaskScope$SubtaskImpl.run(StructuredTaskScope.java:889)",
        "java.base\/java.lang.VirtualThread.run(VirtualThread.java:311)"
      ]
    },
    {
      "tid": "21",
      "name": "",
      "stack": [
        "java.base\/java.lang.VirtualThread.parkNanos(VirtualThread.java:631)",
        "java.base\/java.lang.VirtualThread.sleepNanos(VirtualThread.java:803)",
        "java.base\/java.lang.Thread.sleep(Thread.java:507)",
        "StructuredConcurrencyDemo.task2(StructuredConcurrencyDemo.java:92)",
        "StructuredConcurrencyDemo.lambda$11(StructuredConcurrencyDemo.java:143)",
        "java.base\/java.util.concurrent.StructuredTaskScope$SubtaskImpl.run(StructuredTaskScope.java:889)",
        "java.base\/java.lang.VirtualThread.run(VirtualThread.java:311)"
      ]
    }
  ],
  "threadCount": "2"
}

小结

今天我们学习了 Java 21 中的 结构化并发（Structured Concurrency） 特性，这是 Loom 项目的重要成果，它借鉴了结构化编程的核心思想，将并发编程中的多个子任务视为单个工作单元进行统一管理。主要内容包括：

1. 核心思想 - 结构化并发将结构化编程的原则引入并发编程，保证控制流拥有单一的入口与出口。所有子线程在统一的出口处完成合并，使得任务的开始与结束变得清晰可见，代码逻辑更易于理解和维护，这一设计有效解决了传统非结构化并发中的线程泄漏、错误处理复杂、可观察性差等问题；
2. StructuredTaskScope API - Java 提供了 StructuredTaskScope 作为实现结构化并发的基础 API，它通过 fork() 提交任务，通过 join() 等待任务完成，为子任务的生命周期管理提供了清晰的语义。同时通过关闭策略（如 ShutdownOnFailure 和 ShutdownOnSuccess）来满足不同的并发场景需求，还支持自定义关闭策略以应对复杂的业务逻辑；
3. 增强的可观察性 - 结构化并发带来的一个重要好处是线程之间拥有清晰的层次结构。通过 jcmd 工具生成的线程转储能够直观地展示父线程与子线程的关系，这对于问题排查和性能分析提供了极大的便利，使得高并发应用的调试与维护变得更加高效。

结构化并发与虚拟线程、作用域值等特性共同构成了 Java 高性能并发编程的新范式，有望为 Java 应用程序的构建方式带来深刻的变革。当这些特性结合使用时，开发者将能够编写更加清晰、可靠、易于维护的高吞吐量并发应用程序，这对 Java 在云计算、微服务和高并发场景中的应用具有重要意义。

密钥封装（Key Encapsulation） 是一种现代加密技术，它使用非对称或公钥加密来保护对称密钥。传统的做法是使用公钥加密随机生成的对称密钥，但这需要 填充（Paddings） 并且难以证明安全，密钥封装机制（Key Encapsulation Mechanism，KEM） 另辟蹊径，使用公钥的属性来推导相关的对称密钥，不需要填充。

KEM 的概念是由 Crammer 和 Shoup 在 Design and Analysis of Practical Public-Key Encryption Schemes Secure against Adaptive Chosen Ciphertext Attack 这篇论文中提出的，后来 Shoup 将其提议为 ISO 标准，并于 2006 年 5 月接受并发布为 ISO 18033-2。

经过多年的发展，KEM 已经在多个密码学领域有所应用：

• 在 混合公钥加密（Hybrid Public Key Encryption，HPKE） 中，KEM 是基本的构建模块，比如 DH 密钥封装机制（DHKEM）、RSA 密钥封装机制（RSA-KEM）、椭圆曲线集成加密方案（ECIES）等；
• 可以使用 KEM 替换传统的密钥交换协议，比如 TLS 1.3 中的 Diffie-Hellman 密钥交换步骤 可以建模为 KEM，也就是 Diffie-Hellman KEM (DHKEM)；
• 在 NIST 后量子密码（Post-Quantum Cryptography，PQC）标准化过程 中，明确要求对 KEM 和数字签名算法进行评估，作为下一代标准公钥密码算法的候选；KEM 将成为抵御量子攻击的重要工具；

Java 平台中现有的加密 API 都无法以自然的方式表示 KEM，第三方安全提供商的实施者已经表达了对标准 KEM API 的需求。于是，Java 21 引入了一种新的 KEM API，使应用程序能够自然且方便地使用 KEM 算法。

对称加密

上面对 KEM 的描述中涉及大量现代密码学的概念，为了对 KEM 有一个更直观的认识，我们不妨快速浏览一遍密码学的发展历史。

我们经常会在各种讲述一二战的谍战片中看到破译电报的片段，当时使用的密码算法在现在看来是非常简单的，几乎所有的密码系统使用的都是 对称加密（Symmetric Cryptography） 算法，也就是说使用相同的密钥进行消息的加密与解密，因为这个特性，我们也称这个密钥为 共享密钥（Shared Secret Key）。

常见的对称加密算法有：DES、3DES、AES、Salsa20 / ChaCha20、Blowfish、RC6、Camelia 等。

其中绝大多数都是 块密码算法（Block Cipher） 或者叫 分组密码算法，这种算法一次只能加密固定大小的块（例如 128 位）；少部分是 流密码算法（Stream Cipher），流密码算法将数据逐字节地加密为密文流。为了实现加密任意长度的数据，我们通常需要将分组密码算法转换为流密码算法，这被称为 分组密码的工作模式，常用的工作模式有：ECB（电子密码本）、CBC（密码块链接）、CTR（计数器）、CFB（密文反馈模式）、OFB（输出反馈模式）、GCM（伽罗瓦/计数器模式）） 等。

分组密码的工作模式其背后的主要思想是把明文分成多个长度固定的组，再在这些分组上重复应用分组密码算法，以实现安全地加密或解密任意长度的数据。某些分组模式（如 CBC）要求将输入拆分为分组，并使用填充算法（例如添加特殊填充字符）将最末尾的分组填充到块大小，也有些分组模式（如 CTR、CFB、OFB、CCM、EAX 和 GCM）根本不需要填充，因为它们在每个步骤中，都直接在明文部分和内部密码状态之间执行异或（XOR）运算。

因此我们在使用对称加密时，往往要指定 工作模式（Modes） 和 填充模式（Paddings） 这两个参数，下面是使用 Java 标准库提供的接口实现 AES 加密和解密的示例：

private static void testAES() throws Exception {

  // 1. 生成对称密钥
  KeyGenerator keyGenerator = KeyGenerator.getInstance("AES");
  keyGenerator.init(new SecureRandom());
  Key secretKey =  keyGenerator.generateKey();

  // 1. 使用固定密钥：128 位密钥 = 16 字节
  // SecretKey secretKey = new SecretKeySpec("1234567890abcdef".getBytes(), "AES");

  // 2. 加密
  Cipher cipher = Cipher.getInstance("AES/ECB/PKCS5Padding");
  cipher.init(Cipher.ENCRYPT_MODE, secretKey);
  byte[] encrypted = cipher.doFinal("hello".getBytes());

  // 3. 解密
  cipher.init(Cipher.DECRYPT_MODE, secretKey);
  byte[] decrypted = cipher.doFinal(encrypted);
  System.out.println(new String(decrypted));
}

我们首先通过 KeyGenerator 生成一个对称密钥（也可以直接使用 SecretKeySpec 来定义一个固定的密钥，但是要注意密钥的长度），然后通过 算法名称/工作模式/填充模式 来获取一个 Cipher 实例，这里使用的是 AES 算法，ECB 分组模式以及 PKCS5Padding 填充模式，关于其他算法和模式可参考 Java Security Standard Algorithm Names。得到 Cipher 实例后，就可以对数据进行加密和解密，可以看到，这里加密和解密使用的是同一个密钥。

对称加密算法的问题有两点：

• 需要安全的通道进行密钥交换，早期最常见的是面对面交换密钥，一旦密钥泄露，数据将完全暴露；
• 每个点对点通信都需要使用不同的密钥，密钥的管理会变得很困难，如果你需要跟 100 个朋友安全通信，你就要维护 100 个不同的对称密钥；

综上，对称加密会导致巨大的 密钥交换 跟 密钥保存与管理 的成本。

密钥交换协议

为了解决对称加密存在的两大问题，密码学家们前仆后继，想出了各种各样的算法，其中最关键的一个是 Whitfield Diffie 和 Martin Hellman 在 1976 年公开发表的一种算法，也就是现在广为人知的 Diffie–Hellman 密钥交换（Diffie–Hellman Key Exchange，DHKE） 算法。

上图是经典 DHKE 协议的整个过程，其基本原理涉及到数学中的 模幂（Modular Exponentiations） 和 离散对数（Discrete Logarithms） 的知识。

模幂是指求 g 的 a 次幂模 p 的值，其中 g a p 均为整数，公式如下：

A = (g^a) mod p

而离散对数是指在已知 g p 和模幂值 A 的情况下，求幂指数 a 的逆过程。

我们通过将 p 设置为一个非常大的质数，使用计算机计算上述模幂的值是非常快的，但是求离散对数却非常困难，这也就是所谓的 离散对数难题（Discrete Logarithm Problem，DLP）。

在 DHKE 协议中，Alice 和 Bob 首先约定好两个常数 g 和 p，这两个数所有人都可见。然后他们分别生成各自的私钥 a 和 b，这两个值各自保存，不对外公开。他们再分别使用各自的私钥计算出模幂 A 和 B，这两个值就是他们的公钥：

A = (g^a) mod p
B = (g^b) mod p

接着，Alice 将 A 发送给 Bob，Bob 将 B 发送给 Alice，接受到彼此的公钥之后，他们使用自己的私钥来计算模幂：

S1 = (B^a) mod p
S2 = (A^b) mod p

根据模幂的数学性质，我们可以得知 S1 和 S2 是相等的！

S1 = (B^a) mod p = (g^b)^a mod p = ( g^(b*a) ) mod p
S2 = (A^b) mod p = (g^a)^b mod p = ( g^(a*b) ) mod p

至此 Alice 和 Bob 就协商出了一个共享密钥，这个密钥可以在后续的通讯中作为对称密钥来加密通讯内容。可以看到，尽管整个密钥交换过程是公开的，但是任何窃听者都无法根据公开信息推算出密钥，这就是密钥交换协议的巧妙之处。

下面的代码演示了如何在 Java 中实现标准的 DHKE 协议：

private static void testKeyAgreement() throws Exception {

  // 1. Alice 和 Bob 分别生成各自的密钥对
  KeyPairGenerator keyPairGen = KeyPairGenerator.getInstance("DH");
  keyPairGen.initialize(512);
  KeyPair keyPairAlice = keyPairGen.generateKeyPair();
  KeyPair keyPairBob = keyPairGen.generateKeyPair();

  // 2. Alice 根据 Bob 的公钥协商出对称密钥
  KeyAgreement keyAgreement = KeyAgreement.getInstance("DH");
  keyAgreement.init(keyPairAlice.getPrivate());
  keyAgreement.doPhase(keyPairBob.getPublic(), true);
  byte[] secretKey1 = keyAgreement.generateSecret();

  // 3. Bob 根据 Alice 的公钥协商出对称密钥
  keyAgreement.init(keyPairBob.getPrivate());
  keyAgreement.doPhase(keyPairAlice.getPublic(), true);
  byte[] secretKey2 = keyAgreement.generateSecret();

  // 4. 比较双方的密钥是否一致
  System.out.println("Alice Secret key: " + HexFormat.of().formatHex(secretKey1));
  System.out.println("Bob Secret key: " + HexFormat.of().formatHex(secretKey2));
}

这里首先通过 KeyPairGenerator 为 Alice 和 Bob 分别生成密钥对（密钥对中包含了一个私钥和一个公钥，也就是上文中的 a/b 和 A/B），然后使用 KeyAgreement.getInstance("DH") 获取一个 KeyAgreement 实例，用于密钥协商，Alice 根据 Bob 的公钥协商出对称密钥 S1，Bob 根据 Alice 的公钥协商出对称密钥 S2，根据输出结果可以看到 S1 和 S2 是相等的。

非对称加密

从第一次世界大战、第二次世界大战到 1976 年这段时期密码的发展阶段，被称为 近代密码阶段。1976 年是密码学的一个分水岭，在 Whitfield Diffie 和 Martin Hellman 这篇论文 中，他们不仅提出了 DHKE 算法，还提出了 公钥密码学（Public- Key Cryptography） 的概念。

公钥密码学中最核心的部分是 非对称加密（Asymmetric Encryption） 算法，和 DHKE 算法类似，它也是基于两个不同的密钥来实现加密和解密，一个称为公钥，另一个称为私钥，其中公钥可以公开，任何人都能访问；但和 DHKE 不同的是，DHKE 中的公钥只是用于协商出一个对称密钥，用于后续通讯的加解密，而在非对称加密中，不需要密钥协商，消息的发送者可以直接使用接受者的公钥对数据进行加密，而加密后的数据只有私钥的持有者才能将其解密。

非对称加密算法的这种神奇特性，使得通讯双发不需要预先协商密钥，因此非常适合在多方通信中使用；也使得公钥密码学的概念很快就深入人心，它极大地推动了现代密码学的发展，为 数字签名 和 数字证书 提供了理论基础，特别是 公钥基础设施（PKI） 体系的建立，实现安全的身份验证和数据保护。

可以说，非对称加密是密码学领域一项划时代的发明，它宣告了近代密码阶段的终结，是现代密码学的起点。

最著名的非对称加密算法非 RSA 莫属，它是 1977 年由三位美国数学家 Ron Rivest、Adi Shamir 和 Leonard Adleman 共同设计的，这种算法以他们名字的首字母命名。RSA 算法涉及不少数论中的基础概念和定理，比如 互质、欧拉函数、模反元素、中国余数定理、费马小定理 等，网上有大量的文章介绍 RSA 算法原理，感兴趣的同学可以查阅相关的资料。

不过对于初学者来说，这些原理可能显得晦涩难懂，不妨玩一玩下面这个数学小魔术：

首先，让 A 任意想一个 3 位数，并把这个数乘以 91，然后将积的末三位告诉 B，B 就可以猜出 A 想的是什么数字。比如 A 想的是 123，那么他就计算出 123 * 91 = 11193，并把结果的末三位 193 告诉 B。那么 B 要怎么猜出对方的数字呢？其实很简单，只需要把对方说的数字再乘以 11，乘积的末三位就是 A 刚开始想的数了。可以验证一下，193 * 11 = 2123，末三位正是对方所想的秘密数字！

这个小魔术的道理其实很简单，由于 91 * 11 = 1001，而任何一个三位数乘以 1001 后，末三位显然都不变，例如 123 * 1001 = 123123。

这个例子直观地展示了非对称加密算法的工作流程：A 和 B 可以看做消息的发送方和接受方，其中 91 是 B 的公钥，123 是 A 要发送的消息，123 * 91 就好比使用公钥加密，193 就是加密后的密文；而 11 是 B 的私钥，193 * 11 就是使用私钥解密。

RSA 算法的本质就是上面这套思想，只不过它不是简单的乘法计算，而是换成了更加复杂的指数和取模运算。

下面继续使用 Java 代码来实现 RSA 的加密和解密：

private static void testRSA() throws Exception {

  // 1. Bob 生成密钥对
  KeyPairGenerator keyPairGen = KeyPairGenerator.getInstance("RSA");
  keyPairGen.initialize(2048);
  KeyPair keyPairBob = keyPairGen.generateKeyPair();

  // 2. Alice 使用 Bob 的公钥加密数据
  Cipher cipher1 = Cipher.getInstance("RSA");
  cipher1.init(Cipher.ENCRYPT_MODE, keyPairBob.getPublic());
  byte[] encrypted = cipher1.doFinal("hello".getBytes());

  // 3. Bob 使用自己的私钥解密数据
  Cipher cipher2 = Cipher.getInstance("RSA");
  cipher2.init(Cipher.DECRYPT_MODE, keyPairBob.getPrivate());
  byte[] decrypted = cipher2.doFinal(encrypted);

  System.out.println(new String(decrypted));
}

这里的代码和对称加密如出一辙，都是先通过 Cipher.getInstance() 获取一个 Cipher 实例，然后再通过它对数据进行加密和解密；和对称加密不同的是，这里加密用的是 Bob 的公钥，而解密用的是 Bob 的私钥。

其实，根据非对称加密的性质，我们不仅可以 公钥加密，私钥解密，而且也可以 私钥加密，公钥解密，不过用私钥加密的信息所有人都能够用公钥解密，这看起来貌似没啥用，但是密码学家们却发现它大有用处，由于私钥加密的信息只能用公钥解密，也就意味着这个消息只能是私钥持有者发出的，其他人是不能伪造或篡改的，所以我们可以把它用作 数字签名，数字签名在数字证书等应用中。

除了 RSA 算法，还有一些其他重要的非对称加密算法，比如 Rabin 密码、ElGamal 密码 以及基于椭圆曲线的 ECC 密码（Elliptic Curve Cryptography） 等。

后量子密码学

非对称加密算法的安全性，基本上都是由不同的数学难题保障的，比如：

• RSA 算法 - IFP（整数分解问题）
• DH 算法 - DLP（离散对数问题）
• ECC 算法 - ECDLP（椭圆曲线离散对数问题）

这些数学难题暂时都没有好方法解决，所以这些非对称加密算法暂时仍然被认为是安全的；一旦这些数学难题被破解，那么这些加密算法就不再安全了。

近年来，随着 量子计算机 的不断发展，很多运行于量子计算机的量子算法被提出来，其中最著名的是数学家彼得·秀尔于 1994 年提出的 秀尔算法，可以在多项式时间内解决整数分解问题。

这也就意味着，如果攻击者拥有大型量子计算机，那么他可以使用秀尔算法解决整数分解问题，从而破解 RSA 算法。不仅如此，后来人们还发现，使用秀尔算法也可以破解离散对数和椭圆曲线等问题，这导致目前流行的公钥密码系统都是 量子不安全（quantum-unsafe） 的。如果人类进入量子时代，这些密码算法都将被淘汰。

密码学家们估算认为，破解 2048 位的 RSA 需要 4098 个量子比特与 5.2 万亿个托佛利门，目前还不存在建造如此大型量子计算机的科学技术，因此现有的公钥密码系统至少在未来十年（或更久）依然是安全的。尽管如此，密码学家已经积极展开了后量子时代的密码学研究，也就是 后量子密码学（Post-quantum Cryptography，PQC）。

目前已经有一些量子安全的公钥密码系统问世，但是由于它们需要更长的密钥、更长的签名等原因，并没有被广泛使用。这些量子安全的公钥密码算法包括：NewHope、NTRU、BLISS、Kyber 等，有兴趣的同学可以自行查阅相关文档。

混合密码系统

非对称加密好处多多，既可以用来加密和解密，也可以用来签名和验证，而且还大大降低了密钥管理的成本。不过非对称加密也有不少缺点：

• 使用密钥对进行加解密，算法要比对称加密更复杂；而且一些非对称密码系统（如 ECC）不直接提供加密能力，需要结合使用更复杂的方案才能实现加解密；
• 只能加解密很短的消息；
• 加解密非常缓慢，比如 RSA 加密比 AES 慢 1000 倍；

为了解决这些问题，现代密码学提出了 混合密码系统（Hybrid Cryptosystem） 或 混合公钥加密（Hybrid Public Key Encryption，HPKE） 的概念，将对称加密和非对称加密的优势相结合，好比同时装备电动机和发动机两种动力系统的混合动力汽车。发送者首先生成一个对称密码，使用这个对称密码来加密消息，然后使用接受者的公钥来加密对称密码；接受者首先使用自己的私钥解密出对称密码，然后再用对称密码解密消息。这里的对称密码也被称为 会话密钥（Session Key）。

下面的代码演示了 Alice 是如何利用 Bob 的公钥将一个 AES 对称密钥发送给 Bob 的：

private static void testRSA_AES() throws Exception {

  // 1. Bob 生成密钥对
  KeyPairGenerator keyPairGen = KeyPairGenerator.getInstance("RSA");
  keyPairGen.initialize(2048);
  KeyPair keyPair = keyPairGen.generateKeyPair();

  // 2. Alice 生成一个对称密钥
  KeyGenerator keyGen = KeyGenerator.getInstance("AES");
  keyGen.init(256);
  SecretKey secretKey = keyGen.generateKey();

  // 3. Alice 使用 Bob 的公钥加密对称密钥
  Cipher cipher1 = Cipher.getInstance("RSA");
  cipher1.init(Cipher.ENCRYPT_MODE, keyPair.getPublic());
  byte[] secretKeyEncrypted = cipher1.doFinal(secretKey.getEncoded());

  // 4. Bob 使用自己的私钥解密出对称密钥
  Cipher cipher2 = Cipher.getInstance("RSA");
  cipher2.init(Cipher.DECRYPT_MODE, keyPair.getPrivate());
  byte[] secretKeyDecrypted = cipher2.doFinal(secretKeyEncrypted);

  // 5. 比较双方的密钥是否一致
  System.out.println("Alice Secret key: " + HexFormat.of().formatHex(secretKey.getEncoded()));
  System.out.println("Bob Secret key: " + HexFormat.of().formatHex(secretKeyDecrypted));
}

可以看出，在混合密码系统中，非对称加密算法的作用和上文中的 DHKE 一样，只是用于密钥交换，并不用于加密消息，这和 DHKE 的工作原理几乎是一样的，所以严格来说，DHKE 也算是一种混合密码系统，只是两种密钥交换的实现不一样罢了。如何将会话密钥加密并发送给对方，就是 密钥封装机制（Key Encapsulation Mechanisms，KEM） 要解决的问题。

密钥封装机制

综上所述，密钥封装机制就是一种基于非对称加密的密钥交换技术，其主要目的是在不直接暴露私钥的情况下安全地传输会话密钥。

在 KEM 中，发起方运行一个封装算法产生一个会话密钥以及与之对应的 密钥封装消息（key encapsulation message），这个消息在 ISO 18033-2 中被称为 密文（ciphertext），随后发起方将密钥封装消息发送给接收方，接收方收到后，使用自己的私钥进行解封，从而获得相同的会话密钥。一个 KEM 由三部分组成：

• 密钥对生成函数：由接收方调用，用于生成密钥对，包含公钥和私钥；
• 密钥封装函数：由发送方调用，根据接收方的公钥产生一个会话密钥和密钥封装消息，然后发送方将密钥封装消息发送给接收方；
• 密钥解封函数：由接收方调用，根据自己的私钥和接受到的密钥封装消息，计算出会话密钥。

其中第一步可以由现有的 KeyPairGenerator API 完成，但是后两步 Java 中暂时没有合适的 API 来自然的表示，这就是 JEP 452 被提出的初衷。通过 密钥封装机制 API（KEM API） 可以方便的实现密钥封装和解封：

private static void testKEM() throws Exception {

  // 1. Bob 生成密钥对
  KeyPairGenerator keyPairGen = KeyPairGenerator.getInstance("X25519");
  KeyPair keyPair = keyPairGen.generateKeyPair();

  // 2. Alice 根据 Bob 的公钥生成一个 Encapsulated 对象，这个对象里包含了：
  //  * 共享密钥 shared secret
  //  * 密钥封装消息 key encapsulation message
  //  * 可选参数 optional parameters
  //  然后 Alice 将密钥封装消息发送给 Bob
  KEM kem1 = KEM.getInstance("DHKEM");
  Encapsulator sender = kem1.newEncapsulator(keyPair.getPublic());
  Encapsulated encapsulated = sender.encapsulate();
  SecretKey k1 = encapsulated.key();

  // 3. Bob 根据自己的私钥和 Alice 发过来的密钥封装消息，计算出共享密钥
  KEM kem2 = KEM.getInstance("DHKEM");
  Decapsulator receiver = kem2.newDecapsulator(keyPair.getPrivate());
  SecretKey k2 = receiver.decapsulate(encapsulated.encapsulation());

  // 4. 比较双方的密钥是否一致
  System.out.println(Base64.getEncoder().encodeToString(k1.getEncoded()));
  System.out.println(Base64.getEncoder().encodeToString(k2.getEncoded()));
}

从代码可以看出密钥封装机制和混合密码系统有点像，但是看起来要更简单一点，省去了使用 KeyGenerator.generateKey() 生成对称密钥的步骤，而是使用密钥封装算法直接给出，至于这个密钥封装算法可以抽象成任意的实现，可以是密钥生成算法，也可以是随机数算法。

从 Java 文档 中可以看到 KEM 算法暂时只支持 DHKEM 这一种。但是 KEM API 提供了 服务提供商接口（Service Provider Interface，SPI），允许安全提供商在 Java 代码或本地代码中实现自己的 KEM 算法，比如 RSA-KEM、ECIES-KEM、PSEC-KEM、PQC-KEM 等。

Java Agent 通常被直译为 Java 代理，它是一个 jar 包，这个 jar 包很特别，不能独立运行，而是要依附到我们的目标 JVM 进程中。它利用 JVM 提供的 Instrumentation API 来修改已加载到 JVM 中的字节码，从而实现很多高级功能，比如：

• Eclipse、IntelliJ 等 IDE 的调试功能；
• JRebel、spring-loaded 等工具的热加载功能；
• Arthas、Btrace、Greys 等工具的线上诊断功能；
• Visual VM、JConsole 等工具的性能分析功能；
• 此外，SkyWalking、Pinpoint 等 APM 系统也是基于 Java Agent 实现的；

Java Agent 简单示例

为了对 Java Agent 的概念有一个更直观的认识，我们从一个简单的示例入手，从零开始实现一个 Java Agent。先创建如下目录结构：

├── pom.xml
└── src
  └── main
    ├── java
    │   └── com
    │     └── example
    │       └── AgentDemo.java
    └── resources
      └── META-INF
        └── MANIFEST.MF

包含三个主要文件：

• pom.xml - Maven 项目的配置文件
• AgentDemo.java - Java Agent 的入口类
• MANIFEST.MF - 元数据文件，用于描述打包的 JAR 文件中的各种属性和信息

Java Agent 的入口类定义如下：

package com.example;

import java.lang.instrument.Instrumentation;

public class AgentDemo {

  public static void premain(String agentArgs, Instrumentation inst) {
    System.out.println("premain");
  }
}

我们知道，常规 Java 程序的入口方法是 main 函数，而 Java Agent 的入口方法是 premain 函数。其中，String agentArgs 是传递给 Agent 的参数，比如当我们运行 java -javaagent:agent-demo.jar=some-args app.jar 命名时，参数 agentArgs 的值就是字符串 some-args；另一个参数 Instrumentation inst 是 JVM 提供的修改字节码的接口，我们可以通过这个接口定位到希望修改的类并做出修改。

Instrumentation API 是 Java Agent 的核心，它可以在加载 class 文件之前做拦截，对字节码做修改（addTransformer），也可以在运行时对已经加载的类的字节码做变更（retransformClasses 或 redefineClasses）；Instrumentation 的英文释义是插桩或植入，所以这个操作又被称为 字节码插桩，由于这个操作非常的底层，一般会配合一些字节码修改的库，比如 ASM、Javassist、Byte Buddy 等。关于 Instrumentation API 是一个较为艰深复杂的话题，本文为简单起见，没有深入展开，感兴趣的同学可以自行查找相关资料。

有了 Java Agent 的入口类之后，我们还需要告诉 JVM 这个入口类的位置，可以在 MANIFEST.MF 元数据文件中通过 Premain-Class 参数来描述：

Premain-Class: com.example.AgentDemo

打包的时候，要注意将 MANIFEST.MF 文件一起打到 jar 包里，这可以通过打包插件 maven-assembly-plugin 来实现：

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-assembly-plugin</artifactId>
  <version>3.6.0</version>
  <configuration>
    <descriptorRefs>
      <descriptorRef>jar-with-dependencies</descriptorRef>
    </descriptorRefs>
    <archive>
      <manifestFile>src/main/resources/META-INF/MANIFEST.MF</manifestFile>
    </archive>
  </configuration>
  <executions>
    <execution>
      <phase>package</phase>
      <goals>
        <goal>single</goal>
      </goals>
    </execution>
  </executions>
</plugin>

最后，执行 mvn clean package 打包命令，生成 target/agent-demo-1.0-SNAPSHOT-jar-with-dependencies.jar 文件，我们就得到了一个最简单的 Java Agent 了。

Java Agent 的两种加载方式

Java Agent 最常见的使用方式是在运行 java 命令时通过 -javaagent 参数指定要加载的 Agent 文件：

$ java -javaagent:agent-demo-1.0-SNAPSHOT-jar-with-dependencies.jar Hello.java

这种方式被称为 静态加载（static loading）。在这种情况下，Java Agent 和应用程序一起启动，并在运行主程序的 main 方法之前先调用 Java Agent 的 premain 方法，下面是程序的运行结果：

premain
Hello

既然有静态加载，自然就有动态加载。动态加载（dynamic loading） 指的是将 Java Agent 动态地加载到已运行的 JVM 进程中，当我们不希望中断生产环境中已经运行的应用程序时，这个特性非常有用。

我们先正常启动一个 Java 应用程序：

$ java Hello.java
Hello

通过 jps 得到该程序的 PID，然后使用 Java 的 Attach API 附加（attach） 到该程序上：

String pidOfOtherJVM = "3378";
VirtualMachine vm = VirtualMachine.attach(pidOfOtherJVM);

附加成功后得到 VirtualMachine 实例，VirtualMachine 提供了一个 loadAgent() 方法用于动态加载 Java Agent：

File agentJar = new File("/com.docker.devenvironments.code/agent-demo-1.0-SNAPSHOT-jar-with-dependencies.jar");
vm.loadAgent(agentJar.getAbsolutePath());

// do other works

vm.detach();

查看应用程序的日志，可以发现如下报错：

Failed to find Agent-Class manifest attribute from /com.docker.devenvironments.code/agent-demo.jar

这是因为目前我们这个 Java Agent 还不支持动态加载，动态加载的入口并不是 premain 函数，而是 agentmain 函数，我们在 AgentDemo 类中新增代码如下：

...
  public static void agentmain(String agentArgs, Instrumentation inst) {
    System.out.println("agentmain");
  }
...

并在 MANIFEST.MF 文件中新增 Agent-Class 参数：

Agent-Class: com.example.AgentDemo

重新打包，并再次动态加载，可以在应用程序中看到日志如下：

WARNING: A Java agent has been loaded dynamically (/com.docker.devenvironments.code/agent-demo-1.0-SNAPSHOT-jar-with-dependencies.jar)
WARNING: If a serviceability tool is in use, please run with -XX:+EnableDynamicAgentLoading to hide this warning
WARNING: If a serviceability tool is not in use, please run with -Djdk.instrument.traceUsage for more information
WARNING: Dynamic loading of agents will be disallowed by default in a future release
agentmain

可以看到 agentmain 函数被成功执行，动态加载生效了。

禁用 Java Agent 的动态加载

在上面的应用程序日志中，我们可以看到几行 WARNING 提示，这其实就是 Java 21 引入的新内容了，当 JVM 检测到有 Java Agent 被动态加载，就会打印这几行警告信息，告知用户动态加载机制将在未来的版本中默认禁用。如果不想看到这样的日志，可以在启动应用程序时加上 -XX:+EnableDynamicAgentLoading 选项：

$ java -XX:+EnableDynamicAgentLoading Hello.java

那么 Java 21 为什么要禁用 Java Agent 的动态加载呢？这就要提到 Java 所追求的 Integrity by Default 原则了。Integrity 一般被翻译为 完整性，片面的理解就是要保证我们程序中的任何内容，包括数据或代码都是完整的、没有被篡改的。而 Instrumentation API 通过修改已加载到 JVM 中的字节码来改变现有应用程序，在不更改源代码的情况下改变应用程序的行为。当我们静态加载 Java Agent 时，这并不是什么大问题，因为这是用户明确且有意的使用；然而，动态加载则是间接的，它超出了用户的控制范围，可能对用户的应用程序造成严重破坏，很显然并不符合完整性原则。

因此，作为应用程序的所有者，必须有意识地、明确地决定允许和加载哪些 Java Agent：要么使用静态加载，要么通过 -XX:+EnableDynamicAgentLoading 选项允许动态加载。

向量 API 最初由 JEP 338 提出，并作为孵化 API 集成到 Java 16 中，在 Java 17 到 20 中，又经过了 JEP 414、JEP 417、JEP 426、JEP 438 四次的孵化，这次在 Java 21 中，已经是第六次孵化了。

向量 API 又被称为 Vector API，要注意，这里讲的并不是 Java 中的 Vector 集合类，而是一种专门用于向量计算的全新 API。尽管这个 API 还在孵化期，并没有正式发布，但是这项技术很值得我们提前学习和了解，因为这项技术代表了 Java 语言发展的一个重要方向，在未来一定会有着重要的影响。随着生成式人工智能的发展，Embedding 技术也如日中天，它将各种类型的数据（如文本、图像、声音等）转换为高维数值向量，从而实现对数据特征和语义信息的表示。Embedding 技术在个性化推荐、多模态检索和自然语言处理等领域中发挥着重要作用，而这些场景都离不开向量计算。

什么是向量？

向量是数学和物理学中的一个基本概念，具有大小和方向两个属性，比如物理学中的力就是向量。向量可以有多种不同的表示方式：

• 在代数中，一般印刷用黑体的小写英文字母来表示（比如 a、b、c 等），手写用在 a、b、c 等字母上加一箭头（→）表示；
• 在几何中，向量可以形象化地表示为带箭头的线段，箭头所指的方向代表向量的方向，线段长度则代表向量的大小；
• 在坐标系中，向量可以用点的坐标位置来表示，比如平面直角坐标系中的向量可以记为 (x, y)，空间直角坐标系中的向量可以记为 (x, y, z)，多维空间以此类推；此外，向量也可以使用矩阵来表示；
• 在计算机科学中，向量可以被理解为一个数字列表或数组，这在编程语言中尤为常见。

和向量这个概念相对应的，还有标量、矩阵、张量等概念，这几个概念可以代表不同的维度，一般用点线面体来类比：

• 点——标量（scalar）
• 线——向量（vector）
• 面——矩阵（matrix）
• 体——张量（tensor）

标量计算 vs. 向量计算

标量就是一个数字，在 Java 中通常可以表示为一个整数或浮点数等，我们所熟知的算术运算基本上都是作用于标量之上的，比如下面的代码对 a 和 b 两个标量求和：

int a = 1;
int b = 1;
int c = a + b;

如果将 a 和 b 换成向量，也就是数组，该如何求和呢？最简单的方法是使用 for 循环依次相加数组中对应的元素：

int[] a = new int[] {1, 2, 3, 4};
int[] b = new int[] {1, 2, 3, 4};
int[] c = new int[4];
for (int i = 0; i < a.length; i++) {
  c[i] = a[i] + b[i];
}

很显然这不是什么高明的做法，仔细观察上面的代码就会发现，对于数组中每个元素的相加是互不影响的，那么我们能不能并行计算呢？一种有效的解决方法是使用 并行流（Parallel Stream）：

IntStream.range(0, a.length)
  .parallel()
  .forEach(i -> c[i] = a[i] + b[i]);

另一种解决方法就是我们将要学习的 向量 API（Vector API）：

IntVector aVector = IntVector.fromArray(IntVector.SPECIES_128, a, 0);
IntVector bVector = IntVector.fromArray(IntVector.SPECIES_128, b, 0);
IntVector cVector = aVector.add(bVector);

注意，由于向量 API 并没有正式发布，运行时需要手动加上 jdk.incubator.vector 模块：

$ java --add-modules jdk.incubator.vector VectorDemo.java

向量 API 定义了专门的向量类，比如这里的 IntVector，并提供了 fromArray 方法方便我们将数组转换为向量，然后再通过 aVector.add(bVector) 执行两个向量的加法运算。

除了加法运算，向量 API 还提供了一组方法来执行各种其他的向量计算：

• 算术运算（Arithmetic Operations）

  • 加法：vector1.add(vector2)
  • 减法：vector1.sub(vector2)
  • 乘法：vector1.mul(vector2)
  • 除法：vector1.div(vector2)

• 逐元素操作（Element-Wise Operations）

  • 绝对值：vector.abs()
  • 负数：vector.neg()
  • 平方根：vector.sqrt()
  • 指数：vector.exp()
  • 对数：vector.log()

• 规约运算（Reductions）

  • 元素之和：vector.reduce(VectorOperators.ADD)
  • 最小元素：vector.reduce(VectorOperators.MIN)
  • 最大元素：vector.reduce(VectorOperators.MAX)
  • 平均值：vector.reduce(VectorOperators.ADD).mul(1.0 / vector.length())

• 逻辑运算（Logical Operations）

  • 与：vector1.and(vector2)
  • 或：vector1.or(vector2)
  • 非：vector.not()

• 比较操作（Comparisons）

  • 等于：vector1.eq(vector2)
  • 小于：vector1.lt(vector2)
  • 大于：vector1.compare(VectorOperators.GT, vector2)

单指令多数据（SIMD）

使用向量 API 来执行向量计算，不仅代码精简，容易理解，而且它还有另一个好处，那就是性能提升。尽管使用并行流也能提升一定的性能，但是并行流和向量 API 是两种完全不同的优化技术，前者使用多线程在不同的 CPU 核上并行计算，而后者通过 SIMD 技术，在单个 CPU 周期内对多个数据同时执行相同操作，从而达到并行计算的目的。

SIMD（Single Instruction, Multiple Data，单指令多数据） 是一种并行处理技术，它的核心思想是将一个控制器与多个处理单元结合在一起，使得这些处理单元可以针对不同的数据同时执行相同的操作，简单来说就是一个指令能够同时处理多个数据。这与传统的 SISD（Single Instruction, Single Data，单指令单数据） 形成对比，在后者中，一个指令只能处理一个数据。

在上面那个向量求和的例子中，我们先是使用 for 循环实现：

for (int i = 0; i < a.length; i++) {
  c[i] = a[i] + b[i];
}

数组中的每个元素将使用（大致）1 个 CPU 指令进行计算，这意味着我们需要 4 个指令或 4 个 CPU 周期才能完成计算，这就是典型的 SISD。而使用向量 API 可以将向量的计算编译为对应 CPU 架构上的 SIMD 指令集，只要 1 个指令即可完成向量计算：

在实际应用中，许多现代处理器都支持 SIMD 指令集，如 Intel 的 MMX、SSE 和 AVX，ARM 的 NEON 和 SVE 等，这些指令集能够显著提升程序的执行效率，特别是在需要大量数值计算的场景下。不过使用这些指令集的门槛并不低，通常涉及到汇编语言或一些特殊的函数库，比如 Intel 的跨平台函数库 IPP（Integrated Performance Primitives） 或使用 内置函数 (Intrinsic function) 等。

相比于传统的手写 SIMD 代码，Java 的向量 API 提供了更高的可读性和维护性，开发者可以使用熟悉的 Java 语法和类型系统，无需处理底层寄存器和指令，编写出简洁明了的、平台无关的、高性能的向量计算代码。

其实，在向量 API 提出之前，Java 已经在 SIMD 上探索了很长一段时间了，比如 HotSpot 的 自动向量化（Auto-Vectorization） 功能，它将标量操作转换为 超字操作（SuperWord Operations），然后再映射到 SIMD 指令。然而，这个过程完全依赖 JIT，并没有什么可靠的方法来保证编写的代码一定可以使用 SIMD 指令优化，有些代码甚至根本无法进行优化，开发人员必须深入了解 HotSpot 的自动向量化算法及其限制，才能实现可靠的性能提升。向量 API 使得这个过程完全由开发人员自己控制，因此可以写出更加可预测、更加稳健的代码。

我们可以通过 -XX:-UseSuperWord 参数关闭 HotSpot 的自动向量化功能。

使用向量 API

在学习了向量的基础知识之后，接下来我们将继续深入学习向量 API 的使用。

上面介绍向量计算时，我们已经学习了向量 API 的基本用法，使用 IntVector 实现两个向量相加。这个示例为了易于理解，做了简单处理，并没有考虑在实际使用时的边界情况，假设我们将 a 和 b 两个数组改成 10 个数字：

int[] a = new int[] {1, 2, 3, 4, 5, 6, 7, 8, 9, 10};
int[] b = new int[] {1, 2, 3, 4, 5, 6, 7, 8, 9, 10};
IntVector aVector = IntVector.fromArray(IntVector.SPECIES_128, a, 0);
IntVector bVector = IntVector.fromArray(IntVector.SPECIES_128, b, 0);
IntVector cVector = aVector.add(bVector);

运行后得到的结果 c 仍然是 [2, 4, 6, 8]，后面新加的数字并没有计算。这是因为每个向量的存储空间有限，并不能一次存下所有的数据。这里涉及向量 API 的一个重要概念：向量种类（Vector Species），它是 数据类型（Data Types） 和 向量形状（Vector Shapes） 的组合；所谓数据类型就是 Java 的基础类型，比如 byte、short、int、long 这些整数类型和 float、double 浮点类型，而所谓向量形状就是向量的位大小或位数；比如这里的向量种类为 IntVector.SPECIES_128，它代表数据类型为 int，向量形状为 128 位；而我们知道，一般情况下 int 值的大小为 32 位，所以这个向量一次只能存储 128/32 = 4 个 int 值，这也被形象地称为 通道（Lanes），表示向量一次可以处理的数据个数。

知道这一点后，我们就可以写出更加通用的向量计算代码了。首先我们需要将数据按通道数分组，然后一组一组的进行处理：

int[] a = new int[] {1, 2, 3, 4, 5, 6, 7, 8, 9, 10};
int[] b = new int[] {1, 2, 3, 4, 5, 6, 7, 8, 9, 10};
int[] c = new int[10];
int lanes = IntVector.SPECIES_128.length();
int loopBound = IntVector.SPECIES_128.loopBound(a.length);
for (int i = 0; i < loopBound; i += lanes) {
  IntVector aVector = IntVector.fromArray(IntVector.SPECIES_128, a, i);
  IntVector bVector = IntVector.fromArray(IntVector.SPECIES_128, b, i);
  IntVector cVector = aVector.add(bVector);
  cVector.intoArray(c, i);
}
for (int i = loopBound; i < a.length; i++) {
  c[i] = a[i] + b[i];
}
IntStream.of(c).forEach(x -> System.out.println(x));

我们可以注意到，在遍历时 i 每次增加 lanes，它的值等于 IntVector.SPECIES_128.length()，也就是通道数，一般来说该值等于 4，所以我们是按 4 个一组进行处理的。但是要注意数据不一定能被通道数完全整除，比如这里 10 个数字，前 8 个可以分为两组处理掉，还剩下 2 个怎么办呢？这时我们只能使用最原始的标量计算来处理了。

此外，在实际编码时向量种类不建议写死，可以使用 IntVector.SPECIES_PREFERRED 替代，它会根据平台自动选择最合适的向量种类：

static final VectorSpecies<Integer> SPECIES = IntVector.SPECIES_PREFERRED;

可以看出尽管向量 API 的使用有不少好处，但是我们也需要谨慎对待：

• 首先，在使用向量 API 时，数据对齐是一个重要的考虑因素，不对齐的数据访问可能会导致性能下降。开发者需要确保数据在内存中的对齐方式，以充分发挥 SIMD 指令的优势；
• 另外，向量 API 有硬件依赖性，它依赖于底层硬件支持的 SIMD 指令集，许多功能可能在其他平台和架构上不可用，性能也可能会有所不同。开发者需要了解目标平台的特性，并进行适当的性能优化。

小结

今天我们学习了 Java 21 中的 向量 API（Vector API），这个特性从 Java 16 开始就已引入，一直在不断演进和完善。学习内容总结如下：

1. 向量计算基础 - 向量是数学和物理学中的基本概念，在计算机科学中被表示为数组或列表。向量计算相比标量计算，通过一次性处理多个数据元素，显著提高了计算效率，这正是现代高性能计算的关键所在；
2. SIMD 优势 - 向量 API 充分利用现代处理器的 SIMD（单指令多数据）指令集特性，如 Intel 的 AVX 和 ARM 的 NEON，相比于手写汇编或使用低级 Unsafe API，向量 API 提供了更高的可读性、更好的可维护性和更可靠的性能保证；
3. 向量 API 的使用：虽然向量 API 带来了性能提升，但我们在使用时也需要关注数据对齐、硬件依赖性等问题，需要根据目标平台的特性进行适当的优化，这样才能充分发挥向量计算的优势；

随着生成式人工智能的快速发展，Embedding 技术和向量计算在推荐系统、多模态检索、自然语言处理等领域的应用日益广泛，向量 API 为 Java 在这些领域的应用提供了基础，有望推动 Java 在 AI 和数据科学领域的进一步发展。

作用域值（Scoped Values） 是 Loom 项目提出的另一个重要特性，它提供了一种隐式方法参数的形式，允许在大型程序的各个部分之间安全地共享数据，而无需将它们作为显式参数添加到调用链中的每个方法中。作用域值通常是作为一个公共静态字段，因此可以从任何方法中访问到。如果多个线程使用相同的作用域值，则从每个线程的角度来看，它可能包含不同的值。

如果您熟悉 线程本地变量（thread-local variables），这听起来会很熟悉，事实上，作用域值正是为了解决使用线程本地变量时可能遇到的一些问题，在某些情况下可以将其作为线程本地变量的现代替代品。

一个例子

在 Web 应用开发中，一个经典的场景是获取当前已登录的用户信息，下面的代码模拟了大概的流程：

public class UserDemo {
    
  public static void main(String[] args) {

    // 从 request 中获取用户信息
    String userId = getUserFromRequest();
    
    // 查询用户详情
    String userInfo = new UserService().getUserInfo(userId);
    System.out.println(userInfo);
  }

  private static String getUserFromRequest() {
    return "admin";
  }

  static class UserService {
    public String getUserInfo(String userId) {
      return new UserRepository().getUserInfo(userId);
    }
  }

  static class UserRepository {
    public String getUserInfo(String userId) {
      return String.format("%s:%s", userId, userId);
    }
  }
}

在接收到请求时，首先对用户进行身份验证，然后得到用户信息，这个信息可能被很多地方使用。在这里我们使用方法参数将用户信息传递到其他要使用的地方，可以看到，userId 参数从 UserDemo 传到 UserService 又传到 UserRepository。

在一个复杂的应用程序中，请求的处理可能会延伸到数百个方法，这时，我们需要为每一个方法添加 userId 参数，将用户传递到最底层需要用户信息的方法中。很显然，额外的 userId 参数会使我们的代码很快变得混乱，因为大多数方法不需要用户信息，甚至可能有一些方法出于安全原因根本不应该能够访问用户。如果在调用堆栈的某个深处我们还需要用户的 IP 地址怎么办？那么我们将不得不再添加一个 ip 参数，然后通过无数的方法传递它。

使用 ThreadLocal 线程本地变量

解决这一问题的传统方法是使用 ThreadLocal，它是线程本地变量，只要线程不销毁，我们随时可以获取 ThreadLocal 中的变量值。

public class UserDemoThreadLocal {
    
  private final static ThreadLocal<String> USER = new ThreadLocal<>();
  
  public static void main(String[] args) {
    
    // 从 request 中获取用户信息
    String userId = getUserFromRequest();
    USER.set(userId);

    // 查询用户详情
    String userInfo = new UserService().getUserInfo();
    System.out.println(userInfo);
  }

  private static String getUserFromRequest() {
    return "admin";
  }

  static class UserService {
    public String getUserInfo() {
      return new UserRepository().getUserInfo();
    }
  }

  static class UserRepository {
    public String getUserInfo() {
      String userId = USER.get();
      return String.format("%s:%s", userId, userId);
    }
  }
}

这里我们定义了一个名为 USER 的 ThreadLocal 全局变量，获取完用户信息之后将其存入 USER 中，然后在 UserRepository 中直接从 USER 中获取。尽管看起来像普通变量，但线程本地变量的特点是每个线程都有一个独立实例，它的值取决于哪个线程调用其 get 或 set 方法来读取或写入其值。使用线程本地变量，可以方便地在调用堆栈上的方法之间共享数据，而无需使用方法参数。

注意，ThreadLocal 只能在单个线程中共享数据，如果内部方法中创建了新线程，我们可以使用 InheritableThreadLocal，它是 ThreadLocal 的子类，主要用于子线程创建时自动继承父线程的 ThreadLocal 变量，方便必要信息的进一步传递。

使用 ScopedValue 作用域值

不幸的是，线程本地变量存在许多设计缺陷，无法避免：

• 不受限制的可变性（Unconstrained mutability） - 线程本地变量都是可变的，它的值可以随意被更改，任何能够调用线程本地变量的 get 方法的代码都可以随时调用该变量的 set 方法；但是往往更常见的需求是从一个方法向其他方法简单的单向数据传输，就像上面的示例一样；对线程本地变量的任意修改可能导致类似意大利面条的数据流以及难以察觉的错误；
• 无限寿命（Unbounded lifetime） - 一旦线程本地变量通过 set 方法设值，这个值将在线程的整个生命周期中被保留，直到调用 remove 方法，不幸的是，开发人员经常忘记调用 remove 方法；如果使用了线程池，如果没有正确清除线程本地变量，可能会将一个线程的变量意外地泄漏到另一个不相关的线程中，导致潜在地安全漏洞；此外，忘记清理线程局部变量还可能导致内存泄露；
• 昂贵的继承（Expensive inheritance） - 当使用大量线程时，我们通常会使用 InheritableThreadLocal 让子线程自动继承父线程的线程本地变量，子线程无法共享父线程使用的存储空间，这会显著增加程序的内存占用；特别是在虚拟线程推出之后，这个问题变得更为显著，因为虚拟线程足够廉价，程序中可能会创建成千上万的虚拟线程，如果一百万个虚拟线程中的每一个都有自己的线程局部变量副本，很快就会出现内存不足的问题。

作用域值（Scoped Values） 就是为解决这些问题而诞生的新概念。

• 首先，作用域值是不可变的，它的值无法更改，单向的数据传输使得代码流程更清晰；
• 另外，作用域值只在有限范围内使用，用完立即释放，不存在忘记清理的问题，所以也不会导致内存泄露；
• 最后，作用域值更轻量，由于它是不可变的，所以父线程和子线程可以复用一个实例，再多的虚拟线程也不会有内存不足的问题。

下面用 ScopedValue 对上面的代码进行重写：

public class UserDemoScopedValue {
    
  final static ScopedValue<String> USER = ScopedValue.newInstance();

  public static void main(String[] args) {
    // 从 request 中获取用户信息
    String userId = getUserFromRequest();
    ScopedValue.where(USER, userId)
      .run(() -> {
        // 查询用户详情
        String userInfo = new UserService().getUserInfo();
        System.out.println(userInfo);
      });
  }

  private static String getUserFromRequest() {
    return "admin";
  }

  static class UserService {
    public String getUserInfo() {
      return new UserRepository().getUserInfo();
    }
  }

  static class UserRepository {
    public String getUserInfo() {
      String userId = USER.get();
      return String.format("%s:%s", userId, userId);
    }
  }
}

我们首先调用 ScopedValue.where(USER, userId)，它用于将作用域值和某个对象进行绑定，然后调用 run() 方法，它接受一个 lambda 表达式，从该表达式直接或间接调用的任何方法都可以通过 get() 方法读取作用域值。

作用域值仅在 run() 调用的生命周期内有效，在 run() 方法完成后，绑定将被销毁。这种有界的生命周期，使得数据从调用方传输到被调用方（直接和间接）的单向传输一目了然。

作用域值的重绑定

上面说过，作用域值是不可变的，没有任何方法可以更改作用域值，但是我们可以重新绑定作用域值：

private static final ScopedValue<String> X = ScopedValue.newInstance();

void foo() {
  ScopedValue.where(X, "hello").run(() -> bar());
}

void bar() {
  System.out.println(X.get()); // prints hello
  ScopedValue.where(X, "goodbye").run(() -> baz());
  System.out.println(X.get()); // prints hello
}

void baz() {
  System.out.println(X.get()); // prints goodbye
}

在这个例子中，foo() 方法将作用域值 X 绑定为 hello，所以在 bar() 方法中使用 X.get() 获得的是 hello；但是接下来，我们重新将 X 绑定为 goodbye，再去调用 baz() 方法，这时在 baz() 方法中使用 X.get() 得到的就是 goodbye 了；不过值得注意的是，当 baz() 方法结束后，重新回到 bar() 方法，使用 X.get() 获得的仍然是 hello，说明作用域值并没有被修改。

作用域值的线程继承

在使用 ThreadLocal 的时候，我们通常会使用 InheritableThreadLocal 让子线程自动继承父线程的线程本地变量，那么作用域值如何实现线程继承呢？可惜的是，并不存在 InheritableScopedValue 这样的类，Java 21 提供了另一种解决方案：结构化并发 API（JEP 428）。

StructuredTaskScope 是结构化并发中的核心类，它的使用方法如下：

try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
  Supplier<String> user = scope.fork(() -> USER.get());
  scope.join().throwIfFailed();
  System.out.println("task scope: " + user.get());
} catch (Exception ex) {
}

其中 scope.fork() 方法用于创建子线程，父线程中的作用域值会自动被 StructuredTaskScope 创建的子线程继承，子线程中的代码可以使用父线程中为作用域值建立的绑定，而几乎没有额外开销。与线程局部变量不同，父线程的作用域值绑定不会被复制到子线程中，因此它的性能更高，也不会消耗过多的内存。

子线程的作用域值绑定的生命周期由 StructuredTaskScope 提供的 fork/join 模型控制，scope.join() 等待子线程结束，当线程结束后绑定就会自动销毁，避免了使用线程本地变量时出现无限生命周期的问题。

结构化并发也是 Java 21 中的一项重要特性，我们将在后面的笔记中继续学习它的知识。

虚拟线程（Virtual Thread） 是 Java 21 中最突出的特性之一，作为 Loom 项目的一部分，开发人员对这个特性可谓期待已久。它由预览特性变成正式特性经历了两个版本的迭代，第一次预览是 Java 19 的 JEP 425 ，第二次预览是 Java 20 的 JEP 436，在 Java 21 中虚拟线程特性正式发布。

虚拟线程 vs. 平台线程

在引入虚拟线程之前，我们常使用 java.lang.Thread 来创建 Java 线程，这个线程被称为 平台线程（Platform Thread），它和操作系统的内核线程是一对一的关系，由内核线程调度器负责调度。

为了提高应用程序的性能和系统的吞吐量，我们将添加越来越多的 Java 线程，下面是一个模拟多线程的例子，我们创建 10 万个线程，每个线程模拟 I/O 操作等待 1 秒钟：

private static void testThread() {
  long l = System.currentTimeMillis();
  try(var executor = Executors.newCachedThreadPool()) {
    IntStream.range(0, 100000).forEach(i -> {
      executor.submit(() -> {
        Thread.sleep(Duration.ofSeconds(1));
        // System.out.println(i);
        return i;
      });
    });
  }
  System.out.printf("elapsed time：%d ms", System.currentTimeMillis() - l);
}

这里的 10 万个线程对应着 10 万个内核线程，这种通过大量的线程来提高系统性能是不现实的，因为内核线程成本高昂，不仅会占用大量资源来处理上下文切换，而且可用数量也很受限，一个线程大约消耗 1M~2M 的内存，当系统资源不足时就会报错：

$ java ThreadDemo.java
Exception in thread "pool-2-thread-427" java.lang.OutOfMemoryError: Java heap space
  at java.base/java.util.concurrent.SynchronousQueue$TransferStack.snode(SynchronousQueue.java:328)
  at java.base/java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:371)
  at java.base/java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:903)
  at java.base/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1069)
  at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
  at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
  at java.base/java.lang.Thread.runWith(Thread.java:1596)
  at java.base/java.lang.Thread.run(Thread.java:1583)

于是人们又发明了各种线程池技术，最大程度地提高线程的复用性。下面我们使用一个固定大小为 200 的线程池来解决线程过多时报错的问题：

private static void testThreadPool() {
  long l = System.currentTimeMillis();
  try(var executor = Executors.newFixedThreadPool(200)) {
    IntStream.range(0, 100000).forEach(i -> {
      executor.submit(() -> {
        Thread.sleep(Duration.ofSeconds(1));
        // System.out.println(i);
        return i;
      });
    });
  }
  System.out.printf("elapsed time：%d ms", System.currentTimeMillis() - l);
}

在使用固定大小的线程池后，不会出现创建大量线程导致报错的问题，任务可以正常完成。但是这里的线程池却成了我们应用程序最大的性能瓶颈，程序运行花费了 50 秒的时间：

$ java ThreadDemo.java
elapsed time：50863 ms

按理说每个线程耗时 1 秒，无论是多少个线程并发，总耗时应该都是 1 秒，很显然这里并没有发挥出硬件应有的性能。

为了充分利用硬件，研究人员转而采用线程共享的方式，它的核心想法是这样的：我们并不需要在一个线程上从头到尾地处理一个请求，当执行到等待 I/O 操作时，可以将这个请求缓存到池中，以便线程可以处理其他请求，当 I/O 操作结束后会收到一个回调通知，再将请求从池中取出继续处理。这种细粒度的线程共享允许在高并发操作时不消耗大量线程，从而消除内核线程稀缺而导致的性能瓶颈。

这种方式使用了一种被称为 异步编程（Asynchronous Programming） 的风格，通过所谓的 响应式框架（Reactive Frameworks） 来实现，比如著名的 Reactor 项目一直致力于通过响应式编程来提高 Java 性能。但是这种风格的代码难以理解、难以调试、难以使用，普通开发人员只能对其敬而远之，只有高阶开发人员才能玩得转，所以并没有得到普及。

所以 Java 一直在寻找一种既能有异步编程的性能，又能编写起来简单的方案，最终虚拟线程诞生。

虚拟线程由 Loom 项目提出，最初被称为 纤程（Fibers），类似于 协程（Coroutine） 的概念，它由 JVM 而不是操作系统进行调度，可以让大量的虚拟线程在较少数量的平台线程上运行。我们将上面的代码改成虚拟线程非常简单，只需要将 Executors.newFixedThreadPool(200) 改成 Executors.newVirtualThreadPerTaskExecutor() 即可：

private static void testVirtualThread() {
  long l = System.currentTimeMillis();
  try(var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    IntStream.range(0, 100000).forEach(i -> {
      executor.submit(() -> {
        Thread.sleep(Duration.ofSeconds(1));
        // System.out.println(i);
        return i;
      });
    });
  }
  System.out.printf("elapsed time：%d ms", System.currentTimeMillis() - l);
}

运行结果显示，虚拟线程使得程序的性能得到了非常显著的提升，10 万个线程全部运行只花费 1 秒多的时间：

$ java ThreadDemo.java
elapsed time：1592 ms

虚拟线程的数量可以远大于平台线程的数量，多个虚拟线程将由 JVM 调度在某个平台线程上执行，一个平台线程可以在不同的时间执行不同的虚拟线程，当虚拟线程被阻塞或等待时，平台线程可以切换到另一个虚拟线程执行。

虚拟线程、平台线程和系统内核线程的关系图如下所示：

值得注意的是，虚拟线程适用于 I/O 密集型任务，不适用于计算密集型任务，因为计算密集型任务始终需要 CPU 资源作为支持。如果测试程序中的任务不是等待 1 秒钟，而是执行一秒钟的计算（比如对一个巨大的数组进行排序），那么程序不会有明显的性能提升。因为虚拟线程不是更快的线程，它们运行代码的速度与平台线程相比并无优势。虚拟线程的存在是为了提供更高的吞吐量，而不是速度（更低的延迟）。

创建虚拟线程

为了降低虚拟线程的使用门槛，官方尽力复用原有的 java.lang.Thread 线程类，让我们的代码可以平滑地过渡到虚拟线程的使用。下面列举几种创建虚拟线程的方式：

通过 Thread.startVirtualThread() 创建

Thread.startVirtualThread(() -> {
  System.out.println("Hello");
});

使用 Thread.ofVirtual() 创建

Thread.ofVirtual().start(() -> {
  System.out.println("Hello");
});

上面的代码通过 start() 直接启动虚拟线程，也可以通过 unstarted() 创建一个未启动的虚拟线程，再在合适的时机启动：

Thread thread = Thread.ofVirtual().unstarted(() -> {
  System.out.println("Hello");
});
thread.start();

和 Thread.ofVirtual() 对应的是 Thread.ofPlatform()，用于创建平台线程。

通过 ThreadFactory 创建

ThreadFactory factory = Thread.ofVirtual().factory();
Thread thread = factory.newThread(() -> {
  System.out.println("Hello");
});
thread.start();

通过 Executors.newVirtualThreadPerTaskExecutor() 创建

try(var executor = Executors.newVirtualThreadPerTaskExecutor()) {
  executor.submit(() -> {
    System.out.println("Hello");
  });
}

这种方式和传统的创建线程池非常相似，只需要改一行代码就可以把之前的线程池切换到虚拟线程。

很有意思的一点是，这里我们并没有指定虚拟线程的数量，这是因为虚拟线程非常廉价非常轻量，使用后立即就被销毁了，所以根本不需要被重用或池化。

正是由于虚拟线程非常轻量，我们可以在单个平台线程中创建成百上千个虚拟线程，它们通过暂停和恢复来实现线程之间的切换，避免了上下文切换的额外耗费，兼顾了多线程的优点，简化了高并发程序的复杂，可以有效减少编写、维护和观察高吞吐量并发应用程序的工作量。

调试虚拟线程

JDK 长期以来一直提供调试、分析和监控线程的机制，这些机制对于故障排查、维护和优化是必不可少的，JDK 提供了很多工具来实现这点，这些工具现在对虚拟线程也提供了同样的支持。

比如 jstack 或 jcmd 是流行的线程转储工具，它们可以打印出应用程序的所有线程，这种扁平的列表结构对于几十或几百个平台线程来说还可以，但对于成千上万的虚拟线程来说已经不适合了，于是在 jcmd 中引入了一种新的线程转储方式，以 JSON 格式将虚拟线程与平台线程一起打印：

$ jcmd <pid> Thread.dump_to_file -format=json <file>

以下是这样的线程转储的示例：

小结

今天我们学习了 Java 21 中最令人期待的特性之一：虚拟线程（Virtual Thread），这是 Loom 项目从预览到正式发布的重要里程碑。

虚拟线程由 JVM 而非操作系统调度，可以让大量的虚拟线程在较少的平台线程上运行。这种设计使得我们可以创建成百上千甚至百万个虚拟线程而无需担心资源耗尽，虚拟线程之间通过暂停和恢复来实现切换，避免了传统线程上下文切换带来的额外开销。

虚拟线程特别适合 I/O 密集型的应用程序，对于网络服务、数据库连接、文件读写等涉及 I/O 操作的场景，虚拟线程能够带来显著的性能提升。然而需要注意的是，虚拟线程并不能提升 CPU 密集型任务的处理能力，因为其本质上并不是更快的线程，而是通过更高效的线程调度来提高吞吐量。

虚拟线程的推出标志着 Java 在并发编程领域的一次重大进步，它有望改变 Java 应用程序的构建方式，使得开发者能够更加轻松地编写高吞吐量、易于维护的并发应用程序。随着生态中越来越多的框架和库对虚拟线程的支持，相信虚拟线程会逐步成为 Java 并发编程的首选方案。

未命名模式和变量也是一个预览特性，其主要目的是为了提高代码的可读性和可维护性。

在 Java 代码中，我们偶尔会遇到一些不需要使用的变量，比如下面这个例子中的异常 e：

try { 
  int i = Integer.parseInt(s);
  System.out.println("Good number: " + i);
} catch (NumberFormatException e) { 
  System.out.println("Bad number: " + s);
}

这时我们就可以使用这个特性，使用下划线 _ 来表示不需要使用的变量：

try { 
  int i = Integer.parseInt(s);
  System.out.println("Good number: " + i);
} catch (NumberFormatException _) { 
  System.out.println("Bad number: " + s);
}

上面这个这被称为 未命名变量（Unnamed Variables）。

顾名思义，未命名模式和变量包含两个方面：未命名模式（Unnamed Patterns） 和 未命名变量（Unnamed Variables）。

未命名模式（Unnamed Patterns）

在上一篇笔记中，我们学习了什么是 记录模式（Record Pattern） 以及 instanceof 和 switch 两种模式匹配。未命名模式允许在模式匹配中省略掉记录组件的类型和名称。下面的代码展示了如何在 instanceof 模式匹配中使用未命名模式这个特性：

if (obj instanceof Person(String name, _)) {
  System.out.println("Name: " + name);
}

其中 Person 记录的第二个参数 Integer age 在后续的代码中没用到，于是用下划线 _ 把类型和名称都代替掉。我们也可以只代替 age 名称，这被称为 未命名模式变量（Unnamed Pattern Variables）：

if (obj instanceof Person(String name, Integer _)) {
  System.out.println("Name: " + name);
}

这个特性也可以在 switch 模式匹配中使用：

switch (b) {
  case Box(RedBall _), Box(BlueBall _) -> processBox(b);
  case Box(GreenBall _)                -> stopProcessing();
  case Box(_)                          -> pickAnotherBox();
}

这里前两个 case 是未命名模式变量，最后一个 case 是未命名模式。

未命名变量（Unnamed Variables）

未命名变量的使用场景更加丰富，除了上面在 catch 子句中使用的例子外，下面列举了一些其他的典型场景。

在 for 循环中使用：

int acc = 0;
for (Order _ : orders) {
  if (acc < LIMIT) { 
    ... acc++ ...
  }
}

在赋值语句中使用：

Queue<Integer> q = ... // x1, y1, z1, x2, y2, z2, ...
while (q.size() >= 3) {
  var x = q.remove();
  var y = q.remove();
  var _ = q.remove();
  ... new Point(x, y) ...
}

在 try-with-resource 语句中使用：

try (var _ = ScopedContext.acquire()) {
  // No use of acquired resource
}

在 lambda 表达式中使用：

stream.collect(
  Collectors.toMap(String::toUpperCase, _ -> "NODATA")
)

未命名类和实例 Main 方法（预览版本）

除了未命名模式和变量，Java 21 还引入了一个 未命名类和实例 Main 方法 预览特性。相信所有学过 Java 的人对下面这几行代码都非常熟悉吧：

public class Hello {
  public static void main(String[] args) {
    System.out.println("Hello");
  }
}

通常我们初学 Java 的时候，都会写出类似这样的 Hello World 程序，不过作为初学者的入门示例，这段代码相比其他语言来说显得过于臃肿了，给初学者的感觉就是 Java 太复杂了，因为这里掺杂了太多只有在开发大型应用的时候才会涉及到的概念：

• 首先 public class Hello 这行代码涉及了类的声明和访问修饰符，这些概念可以用于数据隐藏、重用、访问控制、模块化等，在大型复杂应用程序中很有用；但是对于一个初学者，往往是从变量、控制流和子程序的基本编程概念开始学习的，在这个小例子中，它们毫无意义；
• 其次，main() 函数的 String[] args 这个参数主要用于接收从命令行传入的参数，但是对于一个初学者来说，在这里它显得非常神秘，因为它在代码中从未被使用过；
• 最后，main() 函数前面的 static 修饰符是 Java 类和对象模型的一部分，这个概念这对初学者也很不友好，甚至是有害的，因为如果要在代码中添加一个新的方法或字段时，为了访问它们，我们必须将它们全部声明成 static 的，这是一种既不常见也不是好习惯的用法，要么就要学习如何实例化对象。

为了让初学者可以快速上手，Java 21 引入了未命名类和实例 Main 方法这个特性，这个特性包含两个部分：

1. 增强了 Java 程序的 启动协议（the launch protocol），使得 main 方法可以没有访问修饰符、没有 static 修饰符和没有 String[] 参数：

class Hello { 
  void main() { 
    System.out.println("Hello");
  }
}

这样的 main 方法被称为 实例 Main 方法（instance main methods）。

1. 实现了 未命名类（unnamed class） 特性，使我们可以不用声明类，进一步简化上面的代码：

void main() {
  System.out.println("Hello");
}

在 Java 语言中，每个类都位于一个包中，每个包都位于一个模块中。而一个未命名的类位于未命名的包中，未命名的包位于未命名的模块中。

小结

今天我们学习了 Java 21 中的 未命名模式和变量 以及 未命名类和实例 Main 方法 两个特性：

• 未命名模式和变量 通过使用下划线 _ 来表示那些不需要使用的模式变量和普通变量，消除了编译器对未使用变量的警告，使得代码意图更加明确；
• 未命名类和实例 Main 方法 这个特性则着眼于降低 Java 的学习曲线，通过简化程序的启动协议，使得初学者可以无需掌握访问修饰符、static 修饰符、类的概念等高级特性，就能快速编写简单的 Java 程序；

这两个特性的引入虽然看似微不足道，但都体现了 Java 语言设计者的用心，他们在保持语言强大功能的同时，也在努力让 Java 变得更加易于上手。

外部函数和内存 API（Foreign Function & Memory API，简称 FFM API） 是 Java 17 中首次引入的一个重要特性，经过了 JEP 412 和 JEP 419 两个孵化版本，以及 JEP 424 和 JEP 434 两个预览版本，在 Java 21 中，这已经是第三个预览版本了。

在 Java 22 中，这个特性终于退出了预览版本。

近年来，随着人工智能、数据科学、图像处理等领域的发展，我们在越来越多的场景下接触到原生代码：

• Off-CPU Computing (CUDA, OpenCL)
• Deep Learning (Blas, cuBlas, cuDNN, Tensorflow)
• Graphics Processing (OpenGL, Vulkan, DirectX)
• Others (CRIU, fuse, io_uring, OpenSSL, V8, ucx, ...)

这些代码不太可能用 Java 重写，也没有必要，Java 急需一种能与本地库进行交互的方案，这就是 FFM API 诞生的背景。FFM API 最初作为 Panama 项目 中的核心组件，旨在改善 Java 与本地代码的互操作性。FFM API 是 Java 现代化进程中的一个重要里程碑，标志着 Java 在与本地代码互操作性方面迈出了重要一步，它的引入也为 Java 在人工智能、数据科学等领域的应用提供了更多的可能性，有望加速 Java 在这些领域的发展和应用。

FFM API 由两大部分组成：外部函数接口（Foreign Function Interface，简称 FFI） 和 内存 API（Memory API），FFI 用于实现 Java 代码和外部代码之间的相互操作，而 Memory API 则用于安全地管理堆外内存。

使用 JNI 调用外部函数

在引入外部函数之前，如果想要实现 Java 调用外部函数库，我们需要借助 JNI (Java Native Interface) 来实现。下面的代码是一个使用 JNI 调用外部函数的例子：

public class JNIDemo {
    static {
        System.loadLibrary("JNIDemo");
    }

    public static void main(String[] args) {
        new JNIDemo().sayHello();
    }

    private native void sayHello();
}

其中 sayHello 函数使用了 native 修饰符，表明这是一个本地方法，该方法的实现不在 Java 代码中。这个本地方法可以使用 C 语言来实现，我们首先需要生成这个本地方法对应的 C 语言头文件：

$ javac -h . JNIDemo.java

javac 命令不仅可以将 .java 文件编译成 .class 字节码文件，而且还可以生成本地方法的头文件，参数 -h . 表示将头文件生成到当前目录。这个命令执行成功后，当前目录应该会生成 JNIDemo.class 和 JNIDemo.h 两个文件，JNIDemo.h 文件内容如下：

/* DO NOT EDIT THIS FILE - it is machine generated */
#include <jni.h>
/* Header for class JNIDemo */

#ifndef _Included_JNIDemo
#define _Included_JNIDemo
#ifdef __cplusplus
extern "C" {
#endif
/*
 * Class:     JNIDemo
 * Method:    sayHello
 * Signature: ()V
 */
JNIEXPORT void JNICALL Java_JNIDemo_sayHello
  (JNIEnv *, jobject);

#ifdef __cplusplus
}
#endif
#endif

正如我们所看到的，在这个头文件中定义了一个名为 Java_JNIDemo_sayHello 的函数，这个名称是根据包名、类名和方法名自动生成的。有了这个自动生成的头文件，我们就可以在 C 语言里实现这个这个方法了，于是接着创建一个 JNIDemo.c 文件，编写代码：

#include "jni.h"
#include "JNIDemo.h"
#include <stdio.h>

JNIEXPORT void JNICALL Java_JNIDemo_sayHello(JNIEnv *env, jobject jobj) {
    printf("Hello World!\n");
}

这段代码很简单，直接调用标准库中的 printf 输出 Hello World！。

然后使用 gcc 将这个 C 文件编译成动态链接库：

$ gcc -I${JAVA_HOME}/include -I${JAVA_HOME}/include/darwin -dynamiclib JNIDemo.c -o libJNIDemo.dylib

这个命令会在当前目录下生成一个名为 libJNIDemo.dylib 的动态链接库文件，这个库文件正是我们在 Java 代码中通过 System.loadLibrary("JNIDemo") 加载的库文件。

注意这里我用的是 Mac 操作系统，动态链接库的名称必须以 lib 为前缀，以 .dylib 为扩展名，其他操作系统的命令略有区别。

Linux 系统：

$ gcc -I${JAVA_HOME}/include -I${JAVA_HOME}/include/linux -shared JNIDemo.c -o libJNIDemo.so

Windows 系统：

$ gcc -I${JAVA_HOME}/include -I${JAVA_HOME}/include/win32 -shared JNIDemo.c -o JNIDemo.dll

至此，我们就可以运行这个 Hello World 的本地实现了：

$ java -cp . -Djava.library.path=. JNIDemo

以上步骤演示了如何使用 JNI 调用外部函数，这只是 JNI 的一个简单示例，更多 JNI 的高级功能，比如实现带参数的函数，在 C 代码中访问 Java 对象或方法等，可以参考 Baeldung 的这篇教程。

外部函数接口（Foreign Function Interface）

从上面的过程可以看出，JNI 的使用非常繁琐，一个简单的 Hello World 都要费好大劲：首先要在 Java 代码中定义 native 方法，然后从 Java 代码派生 C 头文件，最后还要使用 C 语言对其进行实现。Java 开发人员必须跨多个工具链工作，当本地库快速演变时，这个工作就会变得尤为枯燥乏味。

除此之外，JNI 还有几个更为严重的问题：

• Java 语言最大的特性是跨平台，所谓 一次编译，到处运行，但是使用本地接口需要涉及 C 语言的编译和链接，这是平台相关的，所以丧失了 Java 语言的跨平台特性；
• JNI 桩代码非常难以编写和维护，首先，JNI 在类型处理上很糟糕，由于 Java 和 C 的类型系统不一致，比如聚合数据在 Java 中用对象表示，而在 C 中用结构体表示，因此，任何传递给 native 方法的 Java 对象都必须由本地代码费力地解包；另外，假设某个本地库包含 1000 个函数，那么意味着我们要生成 1000 个对应的 JNI 桩代码，这么大量的 JNI 桩代码非常难以维护；
• 由于本地代码不受 JVM 的安全机制管理，所以 JNI 本质上是不安全的，它在使用上非常危险和脆弱，JNI 错误可能导致 JVM 的崩溃；
• JNI 的性能也不行，一方面是由于 JNI 方法调用不能从 JIT 优化中受益，另一方面是由于通过 JNI 传递 Java 对象很慢；这就导致开发人员更愿意使用 Unsafe API 来分配堆外内存，并将其地址传递给 native 方法，这使得 Java 代码非常不安全！

多年来，已经出现了许多框架来解决 JNI 遗留下来的问题，包括 JNA、JNR 和 JavaCPP。这些框架通常比 JNI 有显著改进，但情况仍然不尽理想，尤其是与提供一流本地互操作性的语言相比。例如，Python 的 ctypes 包可以动态地包装本地库中的函数，而无需任何胶水代码，Rust 则提供了从 C/C++ 头文件自动生成本地包装器的工具。

FFI 综合参考了其他语言的实现，试图更加优雅地解决这些问题，它实现了对外部函数库的原生接口，提供了一种更高效更安全的方式来访问本地内存和函数，从而取代了传统的 JNI。

下面的代码是使用 FFI 实现和上面相同的 Hello World 的例子：

public class FFIDemo {
    public static void main(String[] args) throws Throwable {
        Linker linker = Linker.nativeLinker();
        SymbolLookup symbolLookup = linker.defaultLookup();
        MethodHandle printf = linker.downcallHandle(
            symbolLookup.find("printf").orElseThrow(), 
            FunctionDescriptor.of(ValueLayout.JAVA_LONG, ValueLayout.ADDRESS)
        );
        try (Arena arena = Arena.ofConfined()) {
            MemorySegment hello = arena.allocateUtf8String("Hello World!\n");
            printf.invoke(hello);
        }
    }
}

注意，Java 22 中取消了 Arena::allocateUtf8String() 方法，改成了 Arena::allocateFrom() 方法。

相比于 JNI 的实现，FFI 的代码要简洁优雅得多。这里的代码涉及三个 FFI 中的重要接口：

• Linker
• SymbolLookup
• FunctionDescriptor

其中 SymbolLookup 用于从已加载的本地库中查找外部函数的地址，Linker 用于链接 Java 代码与外部函数，它同时支持下行调用（从 Java 代码调用本地代码）和上行调用（从本地代码返回到 Java 代码），FunctionDescriptor 用于描述外部函数的返回类型和参数类型，这些类型在 FFM API 中可以由 MemoryLayout 对象描述，例如 ValueLayout 表示值类型，GroupLayout 表示结构类型。

通过 FFI 提供的接口，我们可以生成对应外部函数的方法句柄（MethodHandle），方法句柄是 Java 7 引入的一个抽象概念，可以实现对方法的动态调用，它提供了比反射更高的性能和更灵活的使用方式，这里复用了方法句柄的概念，通过方法句柄的 invoke() 方法就可以实现外部函数的调用。

这里我们不再需要编写 C 代码，也不再需要编译链接生成动态库，所以，也就不存在平台相关的问题了。另一方面，FFI 接口的设计大多数情况下是安全的，由于都是 Java 代码，因此也受到 Java 安全机制的约束，虽然也有一部分接口是不安全的，但是比 JNI 来说要好多了。

OpenJDK 还提供了一个 jextract 工具，用于从本地库自动生成 Java 代码，有兴趣的同学可以尝试一下。

使用 ByteBuffer 和 Unsafe 访问堆外内存

上面说过，FFM API 的另一个主要部分是 内存 API（Memory API），用于安全地管理堆外内存。其实在 FFIDemo 的示例中我们已经见到内存 API 了，其中 printf 打印的 Hello World!\n 字符串，就是通过 Arena 这个内存 API 分配的。

但是在学习内存 API 之前，我们先来复习下 Java 在之前的版本中是如何处理堆外内存的。

内存的使用往往和程序性能挂钩，很多像 TensorFlow、Ignite、Netty 这样的类库，都对性能有很高的要求，为了避免垃圾收集器不可预测的行为以及额外的性能开销，这些类库一般倾向于使用 JVM 之外的内存来存储和管理数据，这就是我们常说的 堆外内存（off-heap memory）。

使用堆外内存有两个明显的好处：

• 使用堆外内存，也就意味着堆内内存较小，从而可以减少垃圾回收次数，以及垃圾回收停顿对于应用的影响；
• 在 I/O 通信过程中，通常会存在堆内内存和堆外内存之间的数据拷贝操作，频繁的内存拷贝是性能的主要障碍之一，为了极致的性能，一份数据应该只占一份内存空间，这就是所谓的 零拷贝，直接使用堆外内存可以提升程序 I/O 操作的性能。

ByteBuffer 是访问堆外内存最常用的方法：

private static void testDirect() {
    ByteBuffer bb = ByteBuffer.allocateDirect(10);
    bb.putInt(0);
    bb.putInt(1);
    bb.put((byte)0);
    bb.put((byte)1);

    bb.flip();

    System.out.println(bb.getInt());
    System.out.println(bb.getInt());
    System.out.println(bb.get());
    System.out.println(bb.get());
}

上面的代码使用 ByteBuffer.allocateDirect(10) 分配了 10 个字节的直接内存，然后通过 put 写内存，通过 get 读内存。

可以注意到这里的 int 是 4 个字节，byte 是 1 个字节，当写完 2 个 int 和 2 个 byte 后，如果再继续写，就会报 java.nio.BufferOverflowException 异常。

另外还有一点值得注意，我们并没有手动释放内存。虽然这个内存是直接从操作系统分配的，不受 JVM 的控制，但是创建 DirectByteBuffer 对象的同时也会创建一个 Cleaner 对象，它用于跟踪对象的垃圾回收，当 DirectByteBuffer 被垃圾回收时，分配的堆外内存也会一起被释放，所以我们不用手动释放内存。

ByteBuffer 是异步编程和非阻塞编程的核心类，从 java.nio.ByteBuffer 这个包名就可以看出这个类是为 NIO 而设计，可以说，几乎所有的 Java 异步模式或者非阻塞模式的代码，都要直接或者间接地使用 ByteBuffer 来管理数据。尽管如此，这个类仍然存在着一些无法摆脱的限制：

• 首先，它不支持手动释放内存，ByteBuffer 对应内存的释放，完全依赖于 JVM 的垃圾回收机制，这对于一些像 Netty 这样追求极致性能的类库来说并不满足，这些类库往往需要对内存进行精确的控制；
• 其次，ByteBuffer 使用了 Java 的整数来表示存储空间的大小，这就导致，它的存储空间最多只有 2G；在网络编程的环境下，这可能并不是一个问题，但是在处理超过 2G 的文件时就不行了，而且像 Memcahed 这样的分布式缓存系统，内存 2G 的限制明显是不够的。

为了突破这些限制，有些类库选择了访问堆外内存的另一条路，使用 sun.misc.Unsafe 类。这个类提供了一些低级别不安全的方法，可以直接访问系统内存资源，自主管理内存资源：

private static void testUnsafe() throws Exception {
    Field f = Unsafe.class.getDeclaredField("theUnsafe");
    f.setAccessible(true);
    Unsafe unsafe = (Unsafe) f.get(null);
    
    long address = unsafe.allocateMemory(10);
    unsafe.putInt(address, 0);
    unsafe.putInt(address+4, 1);
    unsafe.putByte(address+8, (byte)0);
    unsafe.putByte(address+9, (byte)1);
    System.out.println(unsafe.getInt(address));
    System.out.println(unsafe.getInt(address+4));
    System.out.println(unsafe.getByte(address+8));
    System.out.println(unsafe.getByte(address+9));
    unsafe.freeMemory(address);
}

Unsafe 的使用方法和 ByteBuffer 很像，我们使用 unsafe.allocateMemory(10) 分配了 10 个字节的直接内存，然后通过 put 写内存，通过 get 读内存，区别在于我们要手动调整内存地址。

使用 Unsafe 操作内存就像是使用 C 语言中的指针一样，效率虽然提高了不少，但是很显然，它增加了 Java 语言的不安全性，因为它实际上可以访问到任意位置的内存，不正确使用 Unsafe 类会使得程序出错的概率变大。

注意，默认情况下，我们无法直接使用 Unsafe 类，直接使用的话会报下面这样的 SecurityException 异常：

Exception in thread "main" java.lang.SecurityException: Unsafe
        at jdk.unsupported/sun.misc.Unsafe.getUnsafe(Unsafe.java:99)
        at ByteBufferDemo.testUnsafe(ByteBufferDemo.java:33)
        at ByteBufferDemo.main(ByteBufferDemo.java:10)

所以上面的代码通过反射的手段，使得我们可以使用 Unsafe。

说了这么多，总结一句话就是：ByteBuffer 安全但效率低，Unsafe 效率高但是不安全。此时，就轮到 内存 API 出场了。

内存 API（Memory API）

内存 API 基于前人的经验，使用了全新的接口设计，它的基本使用如下：

private static void testAllocate() {
    try (Arena offHeap = Arena.ofConfined()) {
        MemorySegment address = offHeap.allocate(8);
        address.setAtIndex(ValueLayout.JAVA_INT, 0, 1);
        address.setAtIndex(ValueLayout.JAVA_INT, 1, 0);
        System.out.println(address.getAtIndex(ValueLayout.JAVA_INT, 0));
        System.out.println(address.getAtIndex(ValueLayout.JAVA_INT, 1));
    }
}

这段代码使用 Arena::allocate() 分配了 8 个字节的外部内存，然后写入两个整型数字，最后再读取出来。下面是另一个示例，写入再读取字符串：

private static void testAllocateString() {
    try (Arena offHeap = Arena.ofConfined()) {
        MemorySegment str = offHeap.allocateUtf8String("hello");
        System.out.println(str.getUtf8String(0));
    }
}

这段代码使用 Arena::allocateUtf8String() 根据字符串的长度动态地分配外部内存，然后通过 MemorySegment::getUtf8String() 将其复制到 JVM 栈上并输出。

这两段代码中的 Arena 和 MemorySegment 是内存 API 的关键，MemorySegment 用于表示一段内存片段，既可以是堆内内存也可以是堆外内存；Arena 定义了内存资源的生命周期管理机制，它实现了 AutoCloseable 接口，所以可以使用 try-with-resource 语句及时地释放它管理的内存。

Arena.ofConfined() 表示定义一块受限区域，只有一个线程可以访问在受限区域中分配的内存段。除此之外，我们还可以定义其他类型的区域：

• Arena.global() - 全局区域，分配的区域永远不会释放，随时可以访问；
• Arena.ofAuto() - 自动区域，由垃圾收集器自动检测并释放；
• Arena.ofShared() - 共享区域，可以被多个线程同时访问；

Arena 接口的设计经过了多次调整，在最初的版本中被称为 ResourceScope，后来改成 MemorySession，再后来又拆成了 Arena 和 SegmentScope 两个类，现在基本上稳定使用 Arena 就可以了。

除 Arena 接口，内存 API 还包括了下面这些接口，主要可以分为两大类：

• Arena、MemorySegment、SegmentAllocator - 这几个接口用于控制外部内存的分配和释放
• MemoryLayout、VarHandle - 这几个接口用于操作和访问结构化的外部内存

内存 API 试图简化 Java 代码操作堆外内存的难度，通过它可以实现更高效的内存访问方式，同时可以保障一定的安全性，特别适用于下面这些场景：

• 大规模数据处理：在处理大规模数据集时，内存 API 的直接内存访问能力将显著提高程序的执行效率；
• 高性能计算：对于需要频繁进行数值计算的任务，内存 API 可以减少对象访问的开销，从而实现更高的计算性能；
• 与本地代码交互：内存 API 的使用可以使得 Java 代码更方便地与本地代码进行交互，结合外部函数接口，可以实现更灵活的数据传输和处理。

相信等内存 API 正式发布之后，之前使用 ByteBuffer 或 Unsafe 的很多类库估计都会考虑切换成使用内存 API 来获取性能的提升。

小结

今天我们学习了 外部函数和内存 API（Foreign Function & Memory API） 这一重要特性，它在 Java 17 开始引入，经过多个版本的迭代，在 Java 21 中是第三个预览版本，并在 Java 22 中正式发布。

FFM API 由两个部分组成：

1. 外部函数接口（FFI） - 提供了一种比 JNI 更加优雅、安全和高效的方式来调用本地代码，消除了繁琐的 JNI 桩代码编写，使得 Java 与本地库的交互更加直观和类型安全；相比 JNI 的种种限制（跨平台性差、难以维护、性能低下），FFI 通过方法句柄动态生成对应的本地函数调用，既保证了 Java 的跨平台特性，又提供了更好的安全性和性能；
2. 内存 API - 提供了一套统一的、安全的、高效的堆外内存管理方案，它汲取了 ByteBuffer 的安全性优势和 Unsafe 的高性能优点，同时避免了两者的缺陷，通过 Arena 的生命周期管理和 MemorySegment 的内存访问抽象，实现了既安全又高效的堆外内存操作；

FFM API 的推出为 Java 打开了与本地代码交互的新大门，为 Java 在人工智能、数据科学、图像处理等需要调用本地库的领域提供了强有力的支持，有望加速 Java 在这些领域的发展和应用。随着 Java 生态中越来越多的高性能库（如 TensorFlow、CUDA 等）的本地绑定逐步迁移到 FFM API，Java 开发者将能够更加便捷地利用这些强大的库来构建高性能应用。

记录模式（Record Patterns） 是对 记录类（Records） 这个特性的延伸，所以，我们先大致了解下什么是记录类，然后再来看看什么是记录模式。

什么是记录类（Records）？

记录类早在 Java 14 就已经引入了，它类似于 Tuple，提供了一种更简洁、更紧凑的方式来表示不可变数据，记录类经过三个版本的迭代（JEP 359、JEP 384、JEP 395），最终在 Java 16 中发布了正式版本。

记录类的概念在其他编程语言中其实早已有之，比如 Kotlin 的 Data class 或者 Scala 的 Case class。它本质上依然是一个类，只不过使用关键字 record 来定义：

record Point(int x, int y) { }

记录类的定义非常灵活，我们可以在单独文件中定义，也可以在类内部定义，甚至在函数内部定义。记录类的使用和普通类无异，使用 new 创建即可：

Point p1 = new Point(10, 20);
System.out.println("x = " + p1.x());
System.out.println("y = " + p1.y());
System.out.println("p1 is " + p1.toString());

记录类具备如下特点：

• 它是一个 final 类；
• 它不能继承其他类，也不能继承其他记录类；
• 它的所有字段也是 final 的，所以一旦创建就不能修改；
• 它内置实现了构造函数，函数参数就是所有的字段；
• 它内置实现了所有字段的 getter 方法，没有 setter 方法；
• 它内置实现了 equals()、hashCode() 和 toString() 函数；

所以上面的示例和下面的 Point 类是等价的：

public final class Point {
  final int x;
  final int y;

  public Point(int x, int y) {
    this.x = x;
    this.y = y;
  }

  public int x() {
    return x;
  }

  public int y() {
    return y;
  }

  @Override
  public boolean equals(Object o) {
    if (this == o) return true;
    if (o == null || getClass() != o.getClass()) return false;
    Point point = (Point) o;
    return x == point.x && y == point.y;
  }

  @Override
  public int hashCode() {
    return Objects.hash(x, y);
  }

  @Override
  public String toString() {
    return "Point{" +
        "x=" + x +
        ", y=" + y +
        '}';
  }
}

我们也可以在记录类中声明新的方法：

record Point(int x, int y) {
    boolean isOrigin() {
        return x == 0 && y == 0;
    }
}

记录类的很多特性和 Lombok 非常类似，比如下面通过 Lombok 的 @Value 注解创建一个不可变对象：

@Value
public class Point {
  int x;
  int y;
}

不过记录类和 Lombok 还是有一些区别的：

• 根据 JEP 395 的描述，记录类是作为不可变数据的透明载体，也就是说记录类无法隐藏字段；然而，Lombok 允许我们修改字段名称和访问级别；
• 记录类适合创建小型对象，当类中存在很多字段时，记录类会变得非常臃肿；使用 Lombok 的 @Builder 构建器模式可以写出更干净的代码；
• 记录类只能创建不可变对象，而 Lombok 的 @Data 可以创建可变对象；
• 记录类不支持继承，但是 Lombok 创建的类可以继承其他类或被其他类继承；

什么是记录模式（Record Patterns）？

相信很多人都写过类似下面这样的代码：

if (obj instanceof Integer) {
  int intValue = ((Integer) obj).intValue();
  System.out.println(intValue);
}

这段代码实际上做了三件事：

• Test：测试 obj 的类型是否为 Integer；
• Conversion：将 obj 的类型转换为 Integer；
• Destructuring：从 Integer 类中提取出 int 值；

这三个步骤构成了一种通用的模式：测试并进行强制类型转换，这种模式被称为 模式匹配（Pattern Matching）。虽然简单，但是却很繁琐。Java 16 在 JEP 394 中正式发布了 instanceof 模式匹配 的特性，帮我们减少这种繁琐的条件状态提取：

if (obj instanceof Integer intValue) {
  System.out.println(intValue);
}

这里的 Integer intValue 被称为 类型模式（Type Patterns），其中 Integer 是匹配的断言，intValue 是匹配成功后的变量，这个变量可以直接使用，不需要再进行类型转换了。

匹配的断言也支持记录类：

if (obj instanceof Point p) {
  int x = p.x();
  int y = p.y();
  System.out.println(x + y);
}

不过，这里虽然测试和转换代码得到了简化，但是从记录类中提取值仍然不是很方便，我们还可以进一步简化这段代码：

if (obj instanceof Point(int x, int y)) {
  System.out.println(x + y);
}

这里的 Point(int x, int y) 就是 Java 21 中的 记录模式（Record Patterns），可以说它是 instanceof 模式匹配的一个特例，专门用于从记录类中提取数据；记录模式也经过了三个版本的迭代：JEP 405、JEP 432 和 JEP 440，现在终于在 Java 21 中发布了正式版本。

此外，记录模式还支持嵌套，我们可以在记录模式中嵌套另一个模式，假设有下面两个记录类：

record Address(String province, String city) {}
record Person(String name, Integer age, Address address) {}

我们可以一次性提取出外部记录和内部记录的值：

if (obj instanceof Person(String name, Integer age, Address(String province, String city))) {
  System.out.println("Name: " + name);
  System.out.println("Age: " + age);
  System.out.println("Address: " + province + " " + city);
}

仔细体会上面的代码，是不是非常优雅？

switch 模式匹配

学习了记录模式，我们再来看看 Java 21 中的另一个特性，它和上面学习的 instanceof 模式匹配 息息相关。

除了 instanceof 模式匹配，其实还有另一种模式匹配叫做 switch 模式匹配，这个特性经历了 JEP 406、JEP 420、JEP 427、JEP 433 和 JEP 441 五个版本的迭代，从 Java 17 开始首个预览版本到 Java 21 正式发布足足开发了 2 年时间。

在介绍这个功能之前，有一个前置知识点需要复习一下：在 Java 14 中发布了一个特性叫做 Switch Expressions，这个特性允许我们在 case 中使用 Lambda 表达式来简化 switch 语句的写法：

int result = switch (type) {
  case "child" -> 0;
  case "adult" -> 1;
  default -> -1;
};
System.out.println(result);

这种写法不仅省去了繁琐的 break 关键词，而且 switch 作为表达式可以直接赋值给一个变量。switch 模式匹配 则更进一步，允许我们在 case 语句中进行类型的测试和转换，下面是 switch 模式匹配的一个示例：

String formatted = switch (obj) {
  case Integer i -> String.format("int %d", i);
  case Long l    -> String.format("long %d", l);
  case Double d  -> String.format("double %f", d);
  case String s  -> String.format("string %s", s);
  default        -> "unknown";
};
System.out.println(formatted);

作为对比，如果不使用 switch 模式匹配，我们只能写出下面这样的面条式代码：

String formatted;
if (obj instanceof Integer i) {
  formatted = String.format("int %d", i);
} else if (obj instanceof Long l) {
  formatted = String.format("long %d", l);
} else if (obj instanceof Double d) {
  formatted = String.format("double %f", d);
} else if (obj instanceof String s) {
  formatted = String.format("string %s", s);
} else {
  formatted = "unknown";
}
System.out.println(formatted);

更多关于 switch 模式匹配的用法可以参考这篇文章：

• https://inside.java/2023/11/13/sip088/

小结

今天我们学习了 Java 21 中的 记录模式 和 switch 模式匹配 两个特性。

记录模式（Record Patterns） 建立在记录类和模式匹配的基础之上，进一步简化了代码的书写：

1. 记录类（Records） 是一种轻量级的、不可变的数据载体，从 Java 16 开始正式发布，相比于 Lombok 更加原生，避免了注解编译时的额外处理，代码更加透明；
2. 模式匹配 将类型测试、转换和值提取这三个繁琐的步骤统一起来，使得代码更加简洁。从 Java 16 开始支持 instanceof 模式匹配，允许在条件语句中直接进行类型的测试和转换；
3. 记录模式 是 instanceof 模式匹配的特例，专门用于从记录类中提取数据，通过记录模式，我们可以一次性从记录对象中提取多个字段，使得代码更加直观易读；

而 switch 模式匹配 进一步扩展了模式匹配的应用场景，允许在 switch 表达式中进行类型的测试、转换和值的提取，相比于传统的 if-else 链式判断，代码结构更加清晰。

想要搞清楚 Java 21 中的 分代式 ZGC（Generational ZGC） 这个特性，我们需要先搞清楚什么是 ZGC。

ZGC 简介

ZGC（The Z Garbage Collector） 是由 Oracle 开发的一款垃圾回收器，最初在 Java 11 中以实验性功能推出，并经过几个版本的迭代，最终在 Java 15 中被宣布为 Production Ready，相比于其他的垃圾回收器，ZGC 更适用于大内存、低延迟服务的内存管理和回收。下图展示的是不同的垃圾回收器所专注的目标也各不相同：

低延迟服务的最大敌人是 GC 停顿，所谓 GC 停顿指的是垃圾回收期间的 STW（Stop The World），当 STW 时，所有的应用线程全部暂停，等待 GC 结束后才能继续运行。要想实现低延迟，就要想办法减少 GC 的停顿时间，根据 JEP 333 的介绍，最初 ZGC 的目标是：

• GC 停顿时间不超过 10ms；
• 支持处理小到几百 MB，大到 TB 量级的堆；
• 相对于使用 G1，应用吞吐量的降低不超过 15%；

经过几年的发展，目前 ZGC 的最大停顿时间已经优化到了不超过 1 毫秒（Sub-millisecond，亚毫秒级），且停顿时间不会随着堆的增大而增加，甚至不会随着 root-set 或 live-set 的增大而增加（通过 JEP 376 Concurrent Thread-Stack Processing 实现），支持处理最小 8MB，最大 16TB 的堆：

ZGC 之所以能实现这么快的速度，不仅是因为它在算法上做了大量的优化和改进，而且还革命性的使用了大量的创新技术，包括：

• Concurrent：全链路并发，ZGC 在整个垃圾回收阶段几乎全部实现了并发；
• Region-based：和 G1 类似，ZGC 是一种基于区域的垃圾回收器；
• Compacting：垃圾回收的过程中，ZGC 会产生内存碎片，所以要进行内存整理；
• NUMA-aware：NUMA 全称 Non-Uniform Memory Access（非一致内存访问），是一种多内存访问技术，使用 NUMA，CPU 会访问离它最近的内存，提升读写效率；
• Using colored pointers：染色指针是一种将数据存放在指针里的技术，ZGC 通过染色指针来标记对象，以及实现对象的多重视图；
• Using load barriers：当应用程序从堆中读取对象引用时，JIT 会向应用代码中注入一小段代码，这就是读屏障；通过读屏障操作，不仅可以让应用线程帮助完成对象的标记（mark），而且当对象地址发生变化时，还能自动实现对象转移（relocate）和重映射（remap）；

关于这些技术点，网上的参考资料有很多，有兴趣的同学可以通过本文的更多部分进一步学习，其中最有意思的莫过于 染色指针 和 读屏障，下面重点介绍这两项。

染色指针

在 64 位的操作系统中，一个指针有 64 位，但是由于内存大小限制，其实有很多高阶位是用不上的，所以我们可以在指针的高阶位中嵌入一些元数据，这种在指针中存储元数据的技术就叫做 染色指针（Colored Pointers）。染色指针是 ZGC 的核心设计之一，以前的垃圾回收器都是使用对象头来标记对象，而 ZGC 则通过染色指针来标记对象。ZGC 将一个 64 位的指针划分成三个部分：

其中，前面的 16 位暂时没用，预留给以后使用；后面的 44 位表示对象的地址，所以 ZGC 最大可以支持 2^44=16T 内存；中间的 4 位即染色位，分别是：

• Finalizable：标识这个对象只能通过 Finalizer 才能访问；
• Remapped：标识这个对象是否在转移集（Relocation Set）中；
• Marked1：用于标记可到达的对象（活跃对象）；
• Marked0：用于标记可到达的对象（活跃对象）；

此外，染色指针不仅用来标记对象，还可以实现对象地址的多重视图，上述 Marked0、Marked1、Remapped 三个染色位其实代表了三种地址视图，分别对应三个虚拟地址，这三个虚拟地址指向同一个物理地址，并且在同一时间，三个虚拟地址有且只有一个有效，整个视图映射关系如下：

这三个地址视图的切换是由垃圾回收的不同阶段触发的：

• 初始化阶段：程序启动时，ZGC 完成初始化，整个堆内存空间的地址视图被设置为 Remapped；
• 标记阶段：当进入标记阶段时，视图转变为 Marked0 或者 Marked1；
• 转移阶段：从标记阶段结束进入转移阶段时，视图再次被设置为 Remapped；

读屏障

读屏障（Load Barriers） 是 ZGC 的另一项核心技术，当应用程序从堆中读取对象引用时，JIT 会向应用代码中注入一小段代码：

在上面的代码示例中，只有第一行是从堆中读取对象引用，所以只会在第一行后面注入代码，注入的代码类似于这样：

String n = person.name; // Loading an object reference from heap
if (n & bad_bit_mask) {
  slow_path(register_for(n), address_of(person.name));
}

这行代码虽然简单，但是用途却很大，在垃圾回收的不同阶段，触发的逻辑也有所不同：在标记阶段，通过读屏障操作，可以让应用线程帮助 GC 线程一起完成对象的标记或重映射；在转移阶段，如果对象地址发生变化，还能自动实现对象转移。

ZGC 工作流程

整个 ZGC 可以划分成下面六个阶段：

其中有三个是 STW 阶段，尽管如此，但是 ZGC 对 STW 的停顿时间有着严格的要求，一般不会超过 1 毫秒。这六个阶段的前三个可以统称为 标记（Mark）阶段：

• Pause Mark Start - 标记开始阶段，将地址视图被设置成 Marked0 或 Marked1（交替设置）；这个阶段会 STW，它只标记 GC Roots 直接可达的对象，GC Roots 类似于局部变量，通过它可以访问堆上其他对象，这样的对象不会太多，所以 STW 时间很短；
• Concurrent Mark/Remap - 并发标记阶段，GC 线程和应用线程是并发执行的，在第一步的基础上，继续往下标记存活的对象；另外，这个阶段还会对上一个 GC 周期留下来的失效指针进行重映射修复；
• Pause Mark End - 标记结束阶段，由于并发标记阶段应用线程还在运行，所以可能会修改对象的引用，导致漏标，这个阶段会标记这些漏标的对象；

ZGC 的后三个阶段统称为 转移（Relocation）阶段（也叫重定位阶段）：

• Concurrent Prepare for Relocate - 为转移阶段做准备，比如筛选所有可以被回收的页面，将垃圾比较多的页面作为接下来转移候选集（EC）；
• Pause Relocate Start - 转移开始阶段，将地址视图从 Marked0 或者 Marked1 调整为 Remapped，从 GC Roots 出发，遍历根对象的直接引用的对象，对这些对象进行转移；
• Concurrent Relocate - 并发转移阶段，将之前选中的转移集中存活的对象移到新的页面，转移完成的页面即可被回收掉，并发转移完成之后整个 ZGC 周期完成。注意这里只转移了对象，并没有对失效指针进行重映射，ZGC 通过转发表存储旧地址到新地址的映射，如果这个阶段应用线程访问这些失效指针，会触发读屏障机制自动修复，对于没有访问到的失效指针，要到下一个 GC 周期的并发标记阶段才会被修复。

为什么要分代？

在 ZGC 面世之前，Java 内置的所有垃圾回收器都实现了分代回收（G1 是逻辑分代）：

这些分代回收器之间可以搭配使用，周志明老师在《深入理解 Java 虚拟机》这本书中总结了各种回收器之间的关系：

其中，Serial + CMS 和 ParNew + Serial Old 这两个组件在 Java 9 之后已经被取消，而 CMS 与 Serial Old 之间的连线表示 CMS 在并发失败的时候（Concurrent Mode Failure）会切换成 Serial Old 备用方案。

分代的基本思想源自于 弱分代假说（Weak Generational Hypothesis），这个假说认为绝大部分对象都是朝生夕死的，也就是说年轻对象往往很快死去，而老对象往往会保留下来。根据这个假说，JVM 将内存区域划分为 年轻代（Young Generation） 和 老年代（Old Generation），新生代又进一步划分为 伊甸园区（Eden）、第一幸存区（S0） 和 第二幸存区（S1）。

伊甸园区用来分配新创建的对象，如果没有足够的空间，就会触发一次 年轻代 GC（Young GC，Minor GC） 来释放内存空间，这里一般使用 标记-复制（Mark-Copy） 算法，将存活的对象标记下来，然后复制到一个幸存区中；年轻代的内存空间一般较小，所以可以更频繁地触发 GC，清理掉那些朝生夕死的对象，从而提高应用程序的性能；如果 GC 后伊甸园区还没有足够的空间存放新创建的对象，或者幸存区中某个对象的存活时间超过一定的阈值，这时就会将对象分配到老年代，如果老年代的空间也满了，就会触发一次 老年代 GC（Old GC，Full GC）；老年代的内存空间要大的多，而且其中的对象大部分是存活的，GC 发生的频率要小很多，所以不再使用标记-复制算法，而是采用移动对象的方式来实现内存碎片的整理。

但是在上面的 ZGC 的工作流程中，我们却没有看到分代的影子，这也就意味着每次 ZGC 都是对整个堆空间进行扫描，尽管 ZGC 的 STW 时间已经被优化到不到 1ms，但是其他几个阶段是和应用线程一起执行的，这势必会影响到应用程序的吞吐量。让 ZGC 支持分代是一项巨大的工程，开发团队足足花了三年时间才让我们有幸在 Java 21 中体验到这一令人激动的特性。

除了 ZGC，Java 11 之后还引入了一些新的垃圾回收器：

垃圾回收器	用法	说明
ZGC	-XX:+UseZGC	低延迟 GC，from JDK 11
Epsilon GC	-XX:+UseEpsilonGC	No-op GC，什么都不做，用于测试，from JDK 11
Shenandoah	-XX:+UseShenandoahGC	CPU 密集型 GC，from JDK 12

ZGC 实践

使用 -XX:+PrintCommandLineFlags，可以打印出 Java 的默认命令行参数：

$ java -XX:+PrintCommandLineFlags -version
-XX:ConcGCThreads=1 -XX:G1ConcRefinementThreads=4 -XX:GCDrainStackTargetSize=64 -XX:InitialHeapSize=128639872 -XX:MarkStackSize=4194304 -XX:MaxHeapSize=2058237952 -XX:MinHeapSize=6815736 -XX:+PrintCommandLineFlags -XX:ReservedCodeCacheSize=251658240 -XX:+SegmentedCodeCache -XX:+UseCompressedOops -XX:+UseG1GC 
openjdk version "21" 2023-09-19
OpenJDK Runtime Environment (build 21+35-2513)
OpenJDK 64-Bit Server VM (build 21+35-2513, mixed mode, sharing)

从上面的结果可以看出，Java 21 默认使用的仍然是 G1 垃圾回收器，它从 Java 9 就开始做为默认垃圾回收器了。

注意：Java 8 中默认的垃圾回收器是 Parallel GC。

如果想开启 ZGC，我们需要加上 -XX:+UseZGC 参数：

$ java -XX:+UseZGC -Xmx100M -Xlog:gc ZgcTest.java

其中 -Xlog:gc 参数表示打印出 GC 过程中的日志（就是 Java 8 的 -XX:+PrintGC 参数），输出结果如下：

[0.157s][info][gc] Using The Z Garbage Collector
[0.420s][info][gc] GC(0) Garbage Collection (Warmup) 14M(14%)->12M(12%)
[0.472s][info][gc] GC(1) Garbage Collection (System.gc()) 18M(18%)->8M(8%)

也可以使用 -Xlog:gc* 参数打印出 GC 过程中的详细日志（就是 Java 8 的 -XX+PrintGCDetails 参数），输出结果如下：

$ java -XX:+UseZGC -Xmx100M -Xlog:gc* ZgcTest.java
[0.010s][info][gc,init] Initializing The Z Garbage Collector
[0.011s][info][gc,init] Version: 21+35-2513 (release)
[0.011s][info][gc,init] Using legacy single-generation mode
[0.011s][info][gc,init] Probing address space for the highest valid bit: 47
[0.011s][info][gc,init] NUMA Support: Disabled
[0.011s][info][gc,init] CPUs: 4 total, 4 available
[0.011s][info][gc,init] Memory: 7851M
[0.011s][info][gc,init] Large Page Support: Disabled
[0.011s][info][gc,init] GC Workers: 1 (dynamic)
[0.011s][info][gc,init] Address Space Type: Contiguous/Unrestricted/Complete
[0.011s][info][gc,init] Address Space Size: 1600M x 3 = 4800M
[0.011s][info][gc,init] Heap Backing File: /memfd:java_heap
[0.011s][info][gc,init] Heap Backing Filesystem: tmpfs (0x1021994)
[0.012s][info][gc,init] Min Capacity: 8M
[0.012s][info][gc,init] Initial Capacity: 100M
[0.012s][info][gc,init] Max Capacity: 100M
[0.012s][info][gc,init] Medium Page Size: N/A
[0.012s][info][gc,init] Pre-touch: Disabled
[0.012s][info][gc,init] Available space on backing filesystem: N/A
[0.014s][info][gc,init] Uncommit: Enabled
[0.014s][info][gc,init] Uncommit Delay: 300s
[0.134s][info][gc,init] Runtime Workers: 1
[0.134s][info][gc     ] Using The Z Garbage Collector
[0.149s][info][gc,metaspace] CDS archive(s) mapped at: [0x0000006800000000-0x0000006800cb0000-0x0000006800cb0000), size 13303808, SharedBaseAddress: 0x0000006800000000, ArchiveRelocationMode: 1.
[0.149s][info][gc,metaspace] Compressed class space mapped at: 0x0000006801000000-0x0000006841000000, reserved size: 1073741824
[0.149s][info][gc,metaspace] Narrow klass base: 0x0000006800000000, Narrow klass shift: 0, Narrow klass range: 0x100000000
[0.357s][info][gc,start    ] GC(0) Garbage Collection (Warmup)
[0.357s][info][gc,task     ] GC(0) Using 1 workers
[0.357s][info][gc,phases   ] GC(0) Pause Mark Start 0.007ms
[0.366s][info][gc,phases   ] GC(0) Concurrent Mark 8.442ms
[0.366s][info][gc,phases   ] GC(0) Pause Mark End 0.005ms
[0.366s][info][gc,phases   ] GC(0) Concurrent Mark Free 0.000ms
[0.367s][info][gc,phases   ] GC(0) Concurrent Process Non-Strong References 1.092ms
[0.367s][info][gc,phases   ] GC(0) Concurrent Reset Relocation Set 0.000ms
[0.373s][info][gc,phases   ] GC(0) Concurrent Select Relocation Set 5.587ms
[0.373s][info][gc,phases   ] GC(0) Pause Relocate Start 0.003ms
[0.375s][info][gc,phases   ] GC(0) Concurrent Relocate 2.239ms
[0.375s][info][gc,load     ] GC(0) Load: 0.65/0.79/0.63
[0.375s][info][gc,mmu      ] GC(0) MMU: 2ms/99.7%, 5ms/99.9%, 10ms/99.9%, 20ms/99.9%, 50ms/100.0%, 100ms/100.0%
[0.375s][info][gc,marking  ] GC(0) Mark: 1 stripe(s), 2 proactive flush(es), 1 terminate flush(es), 0 completion(s), 0 continuation(s) 
[0.375s][info][gc,marking  ] GC(0) Mark Stack Usage: 32M
[0.375s][info][gc,nmethod  ] GC(0) NMethods: 889 registered, 90 unregistered
[0.375s][info][gc,metaspace] GC(0) Metaspace: 8M used, 8M committed, 1088M reserved
[0.375s][info][gc,ref      ] GC(0) Soft: 142 encountered, 0 discovered, 0 enqueued
[0.375s][info][gc,ref      ] GC(0) Weak: 747 encountered, 602 discovered, 224 enqueued
[0.375s][info][gc,ref      ] GC(0) Final: 0 encountered, 0 discovered, 0 enqueued
[0.375s][info][gc,ref      ] GC(0) Phantom: 146 encountered, 144 discovered, 143 enqueued
[0.375s][info][gc,reloc    ] GC(0) Small Pages: 7 / 14M, Empty: 0M, Relocated: 3M, In-Place: 0
[0.375s][info][gc,reloc    ] GC(0) Large Pages: 1 / 2M, Empty: 0M, Relocated: 0M, In-Place: 0
[0.375s][info][gc,reloc    ] GC(0) Forwarding Usage: 1M
[0.375s][info][gc,heap     ] GC(0) Min Capacity: 8M(8%)
[0.375s][info][gc,heap     ] GC(0) Max Capacity: 100M(100%)
[0.375s][info][gc,heap     ] GC(0) Soft Max Capacity: 100M(100%)
[0.375s][info][gc,heap     ] GC(0)                Mark Start          Mark End        Relocate Start      Relocate End           High               Low         
[0.375s][info][gc,heap     ] GC(0)  Capacity:      100M (100%)        100M (100%)        100M (100%)        100M (100%)        100M (100%)        100M (100%)   
[0.375s][info][gc,heap     ] GC(0)      Free:       84M (84%)          82M (82%)          82M (82%)          88M (88%)          88M (88%)          78M (78%)    
[0.375s][info][gc,heap     ] GC(0)      Used:       16M (16%)          18M (18%)          18M (18%)          12M (12%)          22M (22%)          12M (12%)    
[0.375s][info][gc,heap     ] GC(0)      Live:         -                 6M (6%)            6M (6%)            6M (6%)             -                  -          
[0.375s][info][gc,heap     ] GC(0) Allocated:         -                 2M (2%)            2M (2%)            3M (4%)             -                  -          
[0.375s][info][gc,heap     ] GC(0)   Garbage:         -                 9M (10%)           9M (10%)           1M (2%)             -                  -          
[0.375s][info][gc,heap     ] GC(0) Reclaimed:         -                  -                 0M (0%)            7M (8%)             -                  -          
[0.375s][info][gc          ] GC(0) Garbage Collection (Warmup) 16M(16%)->12M(12%)
[0.403s][info][gc,start    ] GC(1) Garbage Collection (System.gc())
[0.403s][info][gc,task     ] GC(1) Using 1 workers
[0.403s][info][gc,phases   ] GC(1) Pause Mark Start 0.006ms
[0.410s][info][gc,phases   ] GC(1) Concurrent Mark 7.316ms
[0.410s][info][gc,phases   ] GC(1) Pause Mark End 0.006ms
[0.410s][info][gc,phases   ] GC(1) Concurrent Mark Free 0.001ms
[0.412s][info][gc,phases   ] GC(1) Concurrent Process Non-Strong References 1.621ms
[0.412s][info][gc,phases   ] GC(1) Concurrent Reset Relocation Set 0.001ms
[0.414s][info][gc,phases   ] GC(1) Concurrent Select Relocation Set 2.436ms
[0.414s][info][gc,phases   ] GC(1) Pause Relocate Start 0.003ms
[0.415s][info][gc,phases   ] GC(1) Concurrent Relocate 0.865ms
[0.415s][info][gc,load     ] GC(1) Load: 0.65/0.79/0.63
[0.415s][info][gc,mmu      ] GC(1) MMU: 2ms/99.7%, 5ms/99.8%, 10ms/99.9%, 20ms/99.9%, 50ms/100.0%, 100ms/100.0%
[0.415s][info][gc,marking  ] GC(1) Mark: 1 stripe(s), 2 proactive flush(es), 1 terminate flush(es), 0 completion(s), 0 continuation(s) 
[0.415s][info][gc,marking  ] GC(1) Mark Stack Usage: 32M
[0.415s][info][gc,nmethod  ] GC(1) NMethods: 983 registered, 129 unregistered
[0.415s][info][gc,metaspace] GC(1) Metaspace: 9M used, 9M committed, 1088M reserved
[0.415s][info][gc,ref      ] GC(1) Soft: 155 encountered, 0 discovered, 0 enqueued
[0.415s][info][gc,ref      ] GC(1) Weak: 729 encountered, 580 discovered, 58 enqueued
[0.415s][info][gc,ref      ] GC(1) Final: 0 encountered, 0 discovered, 0 enqueued
[0.415s][info][gc,ref      ] GC(1) Phantom: 49 encountered, 47 discovered, 46 enqueued
[0.415s][info][gc,reloc    ] GC(1) Small Pages: 6 / 12M, Empty: 0M, Relocated: 1M, In-Place: 0
[0.415s][info][gc,reloc    ] GC(1) Large Pages: 2 / 4M, Empty: 2M, Relocated: 0M, In-Place: 0
[0.415s][info][gc,reloc    ] GC(1) Forwarding Usage: 0M
[0.415s][info][gc,heap     ] GC(1) Min Capacity: 8M(8%)
[0.415s][info][gc,heap     ] GC(1) Max Capacity: 100M(100%)
[0.415s][info][gc,heap     ] GC(1) Soft Max Capacity: 100M(100%)
[0.415s][info][gc,heap     ] GC(1)                Mark Start          Mark End        Relocate Start      Relocate End           High               Low         
[0.415s][info][gc,heap     ] GC(1)  Capacity:      100M (100%)        100M (100%)        100M (100%)        100M (100%)        100M (100%)        100M (100%)   
[0.415s][info][gc,heap     ] GC(1)      Free:       84M (84%)          84M (84%)          84M (84%)          92M (92%)          92M (92%)          82M (82%)    
[0.415s][info][gc,heap     ] GC(1)      Used:       16M (16%)          16M (16%)          16M (16%)           8M (8%)           18M (18%)           8M (8%)     
[0.415s][info][gc,heap     ] GC(1)      Live:         -                 4M (5%)            4M (5%)            4M (5%)             -                  -          
[0.415s][info][gc,heap     ] GC(1) Allocated:         -                 0M (0%)            2M (2%)            2M (2%)             -                  -          
[0.415s][info][gc,heap     ] GC(1)   Garbage:         -                11M (11%)           9M (9%)            1M (1%)             -                  -          
[0.415s][info][gc,heap     ] GC(1) Reclaimed:         -                  -                 2M (2%)           10M (10%)            -                  -          
[0.415s][info][gc          ] GC(1) Garbage Collection (System.gc()) 16M(16%)->8M(8%)
[0.416s][info][gc,heap,exit] Heap
[0.416s][info][gc,heap,exit]  ZHeap           used 8M, capacity 100M, max capacity 100M
[0.416s][info][gc,heap,exit]  Metaspace       used 9379K, committed 9600K, reserved 1114112K
[0.416s][info][gc,heap,exit]   class space    used 1083K, committed 1216K, reserved 1048576K

从日志中可以看到 ZGC 的整个过程。默认情况下并没有开启分代式 ZGC，如果想开启分代式 ZGC，我们还需要加上 -XX:+ZGenerational 参数：

$ java -XX:+UseZGC -XX:+ZGenerational -Xmx100M -Xlog:gc* ZgcTest.java

这个输出比较多，此处就省略了，从输出中可以看到不同分代的回收情况。关于 ZGC，还有很多微调参数，详细内容可参考 ZGC 的官方文档。

注意，在 Java 23 中分代式 ZGC 已经是默认选项，不需要再用 -XX:+ZGenerational 参数开启，另外，在 Java 24 中非分代模式已被正式移除。

小结

今天我们学习了 Java 21 引入的 分代式 ZGC（Generational ZGC） 这一新的垃圾回收特性，它在原有 ZGC 的基础上融入了分代回收的思想，进一步优化了应用的吞吐量和延迟性能。

单代 ZGC 汇聚了多个技术创新，包括 染色指针 和 读屏障 等技术，具有亚毫秒级的 STW 延迟，但由于每次 GC 都要扫描整个堆，这会对应用吞吐量造成影响；分代式 ZGC 继承了 ZGC 的低延迟特性，同时通过分代设计，使得频繁发生的年轻代 GC 更加高效，而老年代 GC 的频率大幅降低，从而实现了更好的整体性能。