虚拟线程（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 的频率大幅降低，从而实现了更好的整体性能。

字符串模板是很多语言都具备的特性，它允许在字符串中使用占位符来动态替换变量的值，这种构建字符串的方式比传统的字符串拼接或格式化更为简洁和直观。相信学过 JavaScript 的同学对下面这个 Template literals 的语法不陌生：

const name = 'zhangsan'
const age = 18
const message = `My name is ${name}, I'm ${age} years old.`
console.log(message)

如上所示，JavaScript 通过反引号 ` 来定义字符串模板，而 Java 21 则引入了一个叫做 模版表达式（Template expressions） 的概念来定义字符串模板。下面是一个简单示例：

String name = "zhangsan";
int age = 18;
String message = STR."My name is \{name}, I'm \{age} years old.";
System.out.println(message);

看上去和 JavaScript 的 Template literals 非常相似，但还是有一些区别的，模版表达式包含三个部分：

• 首先是一个 模版处理器（template processor）：这里使用的是 STR 模板处理器，也可以是 RAW 或 FMT 等，甚至可以自定义；
• 中间是一个点号（.）；
• 最后跟着一个字符串模板，模板中使用 \{name} 和 \{age} 这样的占位符语法，这被称为 内嵌表达式（embedded expression）；

当模版表达式运行的时候，模版处理器会将模版内容与内嵌表达式的值组合起来，生成结果。

不过，当我们执行上述代码时，很可能会报 Invalid escape sequence (valid ones are \b \t \n \f \r \" \' \\ ) 这样的错：

这是因为字符串模板还只是一个预览特性，根据 JEP 12: Preview Features，我们需要添加 --enable-preview 参数开启预览特性，使用 javac 编译时，还需要添加 --release 参数。使用下面的命令将 .java 文件编译成 .class 文件：

$ javac --enable-preview --release 21 StringTemplates.java 
Note: StringTemplates.java uses preview features of Java SE 21.
Note: Recompile with -Xlint:preview for details.

再使用下面的命令运行 .class 文件：

$ java --enable-preview StringTemplates
My name is zhangsan, I'm 18 years old.

从 Java 11 开始，我们可以直接运行 .java 文件了，参见 JEP 330，所以上面的两个命令也可以省略成一个命令：

$ java --enable-preview --source 21 StringTemplates.java

STR 模版处理器

STR 模板处理器中的内嵌表达式还有很多其他写法，比如执行数学运算：

int x = 1, y = 2;
String s1 = STR."\{x} + \{y} = \{x + y}";

调用方法：

String s2 = STR."Java version is \{getVersion()}";

访问字段：

Person p = new Person(name, age);
String s3 = STR."My name is \{p.name}, I'm \{p.age} years old.";

内嵌表达式中可以直接使用双引号，不用 \" 转义：

String s4 = STR."I'm \{age >= 18 ? "an adult" : "a child"}.";

内嵌表达式中可以编写注释和换行：

String s5 = STR."I'm \{
    // check the age
    age >= 18 ? "an adult" : "a child"
}.";

多行模板表达式

在 Java 13 的 JEP 355 中首次引入了 文本块（Text Blocks） 特性，并经过 Java 14 的 JEP 368 和 Java 15 的 JEP 378 两个版本的迭代，使得该特性正式可用，这个特性可以让我们在 Java 代码中愉快地使用多行字符串。在使用文本块之前，定义一个 JSON 格式的字符串可能会写出像下面这样无法直视的代码来：

String json1 = "{\n" +
               "  \"name\": \"zhangsan\",\n" +
               "  \"age\": 18\n" +
               "}\n";

但是在使用文本块之后，这样的代码就变得非常清爽：

String json2 = """
               {
                 "name": "zhangsan",
                 "age": 18
               }
               """;

文本块以三个双引号 """ 开始，同样以三个双引号结束，看上去和 Python 的多行字符串类似，不过 Java 的文本块会自动处理换行和缩进，使用起来更方便。上面的文本块在 Java 中输出如下：

{
  "name": "zhangsan",
  "age": 18
}

注意开头没有换行，结尾有一个换行。而在 Python 中输出如下：

               {
                 "name": "zhangsan",
                 "age": 18
               }

不仅开头和结尾都有换行，而且每一行有很多缩进，这里可以看出 Python 的处理很简单，它直接把 """ 之间的内容原样输出了，而 Java 是根据最后一个 """ 和内容之间的相对缩进来决定输出。很显然，我们更喜欢 Java 这样的输出结果，如果希望 Python 有同样的输出结果，就得这样写：

json = """{
  "name": "zhangsan",
  "age": 18
}
"""

这在代码的可读性上就比不上 Java 了，这里不得不感叹 Java 的设计，在细节的处理上做的确实不错。

言归正传，说回字符串模板这个特性，我们也可以在文本块中使用，如下：

String json3 = STR."""
               {
                 "name": "\{name}",
                 "age": \{age}
               }
               """;

FMT 模板处理器

FMT 是 Java 21 内置的另一个模版处理器，它不仅有 STR 模版处理器的插值功能，还可以对输出进行格式化操作。格式说明符（format specifiers） 放在嵌入表达式的左侧，如下所示：

%7.2f\{price}

支持的格式说明符参见 java.util.Formatter 文档。

不过在我的环境里编译时，会报错 cannot find symbol: variable FMT，就算是把镜像更换成 openjdk:22-jdk 也是一样的错，不清楚是为什么。

小结

我们今天学习了 Java 21 引入的 字符串模板（String Templates） 特性，它通过 模板表达式 和 内嵌表达式 的设计，使得字符串的构造更加简洁、直观和类型安全。字符串模板的核心优势在于：

• 简洁性：相比传统的字符串拼接或 String.format() 等方法，模板表达式的写法更加简洁易读，特别是在处理复杂的多行字符串时，结合文本块特性，代码的可读性得到了显著提升；
• 灵活的模板处理器：Java 21 内置了 STR 和 FMT 两个模板处理器，满足不同的需求，同时开发者也可以实现自定义的模板处理器来扩展功能；
• 与文本块的完美配合：字符串模板与文本块特性搭配使用，在处理 JSON、XML、HTML 等多行格式化文本时，表现出了显著的优势，使代码变得更加优雅；

总的来说，字符串模板是 Java 语言在现代化演进中的又一个重要步伐，通过借鉴其他编程语言（如 JavaScript、Python、Kotlin 等）的成功经验，为 Java 开发者提供了更加便利和舒适的开发体验。

2025 年 9 月 16 日，Oracle 正式发布了 Java 25 版本，这是 Java 时隔两年发布的又一个 LTS 版本，上一个 LTS 版本是 2023 年 9 月 19 日发布的 Java 21：

还记得当年发布 Java 21 的时候，市场反响很大，它被认为是最近几年内最为重要的版本，带来了一系列重要的功能和特性，包括：记录模式，switch 模式匹配，字符串模板，分代式 ZGC，不需要定义类的 Main 方法，等等等等，不过其中最为重要的一项，当属由 Loom 项目 发展而来的 虚拟线程。Java 程序一直以文件体积大、启动速度慢、内存占用多被人诟病，但是有了虚拟线程，再结合 GraalVM 的原生镜像，我们就可以写出媲美 C、Rust 或 Go 一样小巧灵活、高性能、可伸缩的应用程序。

转眼间，距离 Java 25 的发布已经 1 个多月了，网上相关的文章也已经铺天盖地，为了不使自己落伍，于是便打算花点时间学习一下，顺便看看我之前写的 Java 21 的学习笔记，重温下 Java 21 的相关知识。

尽管在坊间一直流传着 版本任你发，我用 Java 8 这样的说法，但是作为一线 Java 开发人员，最好还是紧跟大势，未雨绸缪，有备无患。而且最重要的是，随着 Spring Boot 2.7.18 的发布，2.x 版本将不再提供开源支持，而 3.x 不支持 Java 8，最低也得 Java 17，所以仍然相信这种说法的人除非不使用 Spring Boot，要么不升级 Spring Boot，否则学习 Java 新版本都是势在必行。

特性一览

接下来，我们先来看下 Java 21 的全部特性，包括下面 15 个 JEP：

• 430: String Templates (Preview)
• 431: Sequenced Collections
• 439: Generational ZGC
• 440: Record Patterns
• 441: Pattern Matching for switch
• 442: Foreign Function & Memory API (Third Preview)
• 443: Unnamed Patterns and Variables (Preview)
• 444: Virtual Threads
• 445: Unnamed Classes and Instance Main Methods (Preview)
• 446: Scoped Values (Preview)
• 448: Vector API (Sixth Incubator)
• 449: Deprecate the Windows 32-bit x86 Port for Removal
• 451: Prepare to Disallow the Dynamic Loading of Agents
• 452: Key Encapsulation Mechanism API
• 453: Structured Concurrency (Preview)

由于内容较多，我将分成几篇来介绍，这是第一篇，先学习下 431 和 449 两个简单的特性。

有序集合

Java 集合框架（Java Collections Framework，JCF） 为集合的表示和操作提供了一套统一的体系架构，让开发人员可以使用标准的接口来组织和操作集合，而不必关心底层的数据结构或实现方式。JCF 的接口大致可以分为 Collection 和 Map 两组，一共 15 个：

在过去的 20 个版本里，这些接口已经被证明非常有用，在日常开发中发挥了重要的作用。那么 Java 21 为什么又要增加一个新的 有序集合（Sequenced Collections） 接口呢？

不一致的顺序操作

这是因为这些接口在处理集合顺序问题时很不一致，导致了无谓的复杂性，比如要获取集合的第一个元素：

可以看到，不同的集合有着不同的实现。再比如获取集合的最后一个元素：

List 的实现显得非常笨重，而 LinkedHashSet 根本没有提供直接的方法，只能将整个集合遍历一遍才能获取最后一个元素。

除了获取集合的第一个元素和最后一个元素，对集合进行逆序遍历也是各不相同，比如 NavigableSet 提供了 descendingSet() 方法来逆序遍历：

for (var e : navSet.descendingSet()) {
  process(e);
}

Deque 通过 descendingIterator() 来逆序遍历：

for (var it = deque.descendingIterator(); it.hasNext();) {
  var e = it.next();
  process(e);
}

而 List 则是通过 listIterator() 来逆序遍历：

for (var it = list.listIterator(list.size()); it.hasPrevious();) {
  var e = it.previous();
  process(e);
}

由此可见，与顺序相关的处理方法散落在 JCF 的不同地方，使用起来极为不便。于是，Java 21 为我们提供了一个描述和操作有序集合的新接口，这个接口定义了一些与顺序相关的方法，将这些散落在各个地方的逻辑集中起来，让我们更方便地处理有序集合。

统一的有序集合接口

与顺序相关的操作主要包括三个方面：

• 获取集合的第一个或最后一个元素
• 向集合的最前面或最后面插入或删除元素
• 按照逆序遍历集合

为此，Java 21 新增了三个有序接口：SequencedCollection、SequencedSet 和 SequencedMap，他们的定义如下：

interface SequencedCollection<E> extends Collection<E> {
  SequencedCollection<E> reversed();
  void addFirst(E);
  void addLast(E);
  E getFirst();
  E getLast();
  E removeFirst();
  E removeLast();
}

interface SequencedSet<E> extends Set<E>, SequencedCollection<E> {
  SequencedSet<E> reversed();
}

interface SequencedMap<K,V> extends Map<K,V> {
  SequencedMap<K,V> reversed();
  SequencedSet<K> sequencedKeySet();
  SequencedCollection<V> sequencedValues();
  SequencedSet<Entry<K,V>> sequencedEntrySet();
  V putFirst(K, V);
  V putLast(K, V);
  Entry<K, V> firstEntry();
  Entry<K, V> lastEntry();
  Entry<K, V> pollFirstEntry();
  Entry<K, V> pollLastEntry();
}

他们在 JCF 大家庭中的位置如下图所示：

有了这些接口，对于所有的有序集合，我们都可以通过下面的方法来获取第一个和最后一个元素：

System.out.println("The first element is: " + list.getFirst());
System.out.println("The last element is: " + list.getLast());

逆序遍历也变得格外简单：

list.reversed().forEach(it -> System.out.println(it));

弃用 Windows 32-bit x86 移植，为删除做准备

这个特性比较简单。随着 64 位架构的普及，32 位操作系统逐渐被淘汰，比如微软从 Windows 10 开始就只提供 64 位版本了，Windows 10 将是最后一个支持 32 位的 Windows 操作系统，而且 2025 年 10 月后将不再支持。

64 位架构相比于 32 位，在性能和安全方面都有巨大的提升。比如 64 位架构可以提供更大的内存地址空间，从而提高应用程序的性能和扩展性，同时它也引入了更多的保护机制，提高了应用程序的安全性。

但由于架构的差异，同时兼容 32 位和 64 位需要不少的维护成本，很多 Java 的新特性已经不支持 32 位系统了，比如虚拟线程，所以弃用 32 位势在必行。

在 Windows 32-bit x86 系统下构建 Java 21 的源码将报如下错误：

$ bash ./configure
...
checking compilation type... native
configure: error: The Windows 32-bit x86 port is deprecated and may be removed in a future release. \
Use --enable-deprecated-ports=yes to suppress this error.
configure exiting with result code 1
$

暂时可以通过 --enable-deprecated-ports=yes 参数来解决：

$ bash ./configure --enable-deprecated-ports=yes

小结

从今天开始，我将和大家一起踏上 Java 新特性的学习之旅，我们先从 Java 21 的 15 个 JEP 开始，这些特性涵盖了从简单的语言特性到复杂的运行时优化等多个方面，值得每一个 Java 开发人员学习和了解。

本篇作为系列的第一篇，学习了其中的两个简单特性：有序集合（Sequenced Collections） 和 弃用 Windows 32-bit x86 移植。

• 有序集合的引入解决了 Java 集合框架长期存在的不一致问题，通过提供统一的顺序操作接口，使得处理集合的第一个和最后一个元素、逆序遍历等操作变得简洁统一；
• 而 Windows 32-bit 支持的移植弃用则进一步精简了 Java 的维护成本，让团队能够更专注于高价值的功能开发；

在后续的篇章中，我们将深入探讨其他更加强大和复杂的特性，包括字符串模板、记录模式、虚拟线程等，敬请期待。