JDK 19 只有 7 个新特性:
- JEP 405: Record Patterns(记录模式)[1] (预览)
- JEP 422: Linux /RISC-V Port[2]
- JEP 424: Foreign Function & Memory API(外部函数和内存 API)[3] (预览)
- JEP 425: Virtual Threads(虚拟线程)[4] (预览)
- JEP 426: Vector(向量)API[5] (第四次孵化)
- JEP 427: Pattern Matching for switch(switch 模式匹配)[6]
- JEP 428: Structured Concurrency(结构化并发)[7] (孵化)
这里只对 424、425、426、428 这 4 个我觉得比较重要的新特性进行详细介绍。
JEP 424: 外部函数和内存 API(预览)
java 程序可以通过该 API 与 Java 运行时之外的代码和数据进行互操作。通过高效地调用外部函数(即 JVM 之外的代码)和安全地访问外部内存(即不受 JVM 管理的内存),该 API 使 Java 程序能够调用本机库并处理本机数据,而不会像 JNI 那样危险和脆弱。
外部函数和内存 API 之前在 JDK 17 中孵化,在 JDK 18 中重新孵化。
在没有外部函数和内存 API 之前:
- Java 通过 `sun.misc.Unsafe`[8] 提供一些执行低级别、不安全操作的方法(如直接访问系统内存资源、自主管理内存资源等), Unsafe 类让 Java 语言拥有了类似 C 语言 指针一样操作内存空间的能力的同时,也增加了 Java 语言的不安全性,不正确使用 Unsafe 类会使得程序出错的概率变大。
- Java 1.1 就已通过 Java 原生接口(JNI)支持了原生方法调用,但并不好用。JNI 实现起来过于复杂,步骤繁琐(具体的步骤可以参考这篇文章: Guide to JNI (Java Native Interface)[9] ),不受 JVM 的语言安全机制控制,影响 Java 语言的跨平台特性。并且,JNI 的性能也不行,因为 JNI 方法调用不能从许多常见的 JIT 优化(如内联)中受益。虽然 JNA [10] 、 JNR[11] 和 JavaCPP[12] 等框架对 JNI 进行了改进,但效果还是不太理想。
引入外部函数和内存 API 就是为了解决 Java 访问外部函数和外部内存存在的一些痛点。
Foreign Function & Memory API (FFM API) 定义了类和接口:
- 分配外部内存 : MemorySegment 、、 Memory Address 和 Segment Allocator );
- 操作和访问结构化的外部内存: MemoryLayout , VarHandle ;
- 控制外部内存的分配和释放: MemorySession ;
- 调用外部函数: Linker 、 FunctionDescriptor 和 SymbolLookup 。
下面是 FFM API 使用示例,这段代码获取了 C 库函数的 radixsort 方法句柄,然后使用它对 Java 数组中的四个 字符串 进行排序。
JEP 425: 虚拟线程(预览)
虚拟线程是 JDK 而不是 OS 实现的轻量级线程(Lightweight Process, LWP ),许多虚拟线程共享同一个操作系统 线程 ,虚拟线程的数量可以远大于操作系统线程的数量。
虚拟线程在其他 多线程 语言中已经被证实是十分有用的,比如 Go 中的 Goroutine、 Erlang 中的进程。
虚拟线程避免了上下文切换的额外耗费,兼顾了多线程的优点,简化了高并发程序的复杂,可以有效减少编写、维护和观察高吞吐量并发应用程序的工作量。
JEP 426: 向量 API(第四次孵化)
向量(Vector) API 最初由 JEP 338[13] 提出,并作为 孵化 API[14] 集成到 JDK 16 中。第二轮孵化由 JEP 414[15] 提出并集成到 JDK 17 中。第三轮孵化由 JEP 417[16] 提出并集成到 JDK 18 中。
向量计算由对向量的一系列操作组成。向量 API 用来表达向量计算,该计算可以在运行时可靠地编译为支持的 CPU 架构上的最佳向量指令,从而实现优于等效标量计算的性能。
向量 API 的目标是为用户提供简洁易用且与平台无关的表达范围广泛的向量计算。
这是对数组元素的简单 标量 计算:
这是使用 Vector API 进行的等效向量计算:
JEP 428: 结构化并发(孵化)
JDK 19 引入了结构化并发,一种多线程编程方法,目的是为了通过结构化并发 API 来简化多线程编程,并不是为了取代 java.util.concurrent ,目前处于孵化器阶段。
结构化并发将不同线程中运行的多个任务视为单个工作单元,从而简化错误处理、提高可靠性并增强可观察性。也就是说,结构化并发保留了单线程代码的可读性、可维护性和可观察性。
结构化并发的基本 API 是 `StructuredTaskScope`[17] 。 StructuredTaskScope 支持将任务拆分为多个并发子任务,在它们自己的线程中执行,并且子任务必须在主任务继续之前完成。
StructuredTaskScope 的基本用法如下:
结构化并发非常适合虚拟线程,虚拟线程是 JDK 实现的轻量级线程。许多虚拟线程共享同一个操作系统线程,从而允许非常多的虚拟线程。