10万字总结Java8到21新特性详解

Java 17 新特性—概述

Java 17，发布于 2021 年 9 月，是一个长期支持（LTS）版本。

JEP 356：增强型伪随机数生成器

在 Java 17 之前，Java 的伪随机数生成主要依赖于 java.util.Random 类及其子类，如 ThreadLocalRandom 和 SecureRandom。这些类虽然功能强大，但在某些特定应用场景中存在局限性，如需要特定类型的随机数生成器（例如具有更长周期的生成器），或需要更细粒度的控制和更广泛的算法选择。

Java 17 引入增强的伪随机数生成器其目的是在 Java 标准库中引入更多种类的随机数生成器，并提供一种更为统一且易于使用的方式来访问和使用这些生成器。它的主要内容包括：

1. 新的接口和实现：引入新的接口 RandomGenerator，以及多个实现此接口的类，每个类代表一种不同类型的随机数生成器。
2. 更广泛的算法选择：提供了多种基于不同算法的随机数生成器，比如 LCG（线性同余生成器）、Xoroshiro、Xoshiro 等，每种算法都有其特点和适用场景。
3. 更好的性能和质量：新的生成器在性能和生成数质量方面进行了优化，以满足更加复杂和高效的应用需求。

JEP 382：新的 macOS 渲染管线

在 Java 17 之前，Java 在 macOS 平台上的图形渲染主要依赖于 OpenGL。随着 Apple 宣布逐步废弃 OpenGL 支持，并推荐使用更现代的 Metal API，Java 需要适应这一变化，以确保其在 macOS 平台上的图形性能和兼容性。

该特性是引入一个新的渲染管道，使用 Apple 的 Metal API 替代 OpenGL。目前默认情况下，这是禁用的，因此渲染仍然使用OpenGL API；要启用metal，应用程序应通过设置系统属性指定其使用：

-Dsun.java2d.metal=true
复制代码

JEP 391：macOS/AArch64 端口

由于早期的 Java 版本并不支持在 ARM 架构的 M1 上运行，这就需要 Java 在 macOS 上支持 ARM64 架构（即 AArch64），从而确保 Java 应用程序和开发者能够在这个新平台上继续运行和开发。

Java 17 引入该特性，去主要目标是在 macOS 上为 ARM64 架构（AArch64）提供官方支持，解决以下问题：

1. 兼容性：确保 Java 可以在 Apple 的 M1 芯片上顺利运行。
2. 性能：优化 Java 在 ARM64 架构上的性能，使其充分利用 M1 芯片的高效能。

JEP 398：移除 Applet API

Applet API 是 Java 最早期的组成部分之一，它允许在浏览器中运行 Java 程序。随着时间的推移，网络技术发展，特别是 HTML5 和 JavaScript 的崛起，使得 Applet 的重要性大大降低。同时，Applets 通常需要浏览器插件来运行，这导致了安全性问题和兼容性问题。且随着主流浏览器逐渐放弃对 Java 插件的支持，Applet 的实用性进一步下降。

Java 17 将Applet API 标记为弃用，并在未来的 Java 版本中移除它。

JEP 406：模式匹配的 Swith 表达式（预览）

在 Java 16 中， JEP 394 扩展了 instanceof 运算符，可以采用类型模式并执行模式匹配。虽然可以不需要强制转换了，但是仍然需要大量的 if...else。而 Switch 表达式虽然简化了 if…else ，但是它无法像 instanceof 一样不需要强制转换。为了解决这个痛点，Java 17 引入模式匹配的 Switch 表达式特性 ，目前该特性为预览特性。

该特性扩展了 switch 表达式和语句，允许它们使用模式匹配，这就意味着我们可以在 switch 的 case 标签中使用模式，如类型模式，使得代码更加灵活和表达性更强。而且也无需进行显式的类型转换了。例如，可以使用 case Integer i 这样的语法来匹配并自动转换类型。

JEP 407：删除 RMI 激活

RMI (远程方法调用) 激活系统是 Java RMI 框架的一部分，它允许远程激活对象。它在 Java 15 中被标记为弃用，Java 17 删除 RMI 激活。

JEP 409：密封类（正式特性）

为了限制 Java 的继承，Java 15 引入密封类作为预览特性。密封类允许类设计者明确控制哪些其他类或接口可以实现或扩展它们，从而提供更精确的多态性控制。同时，Java 16 第二次作为预览特性，最终在 Java 17 中成为正式特性。

Java 版本	更新类型	JEP	更新内容
Java 15	预览特性	JEP 360	引入了密封类作为预览特性。
Java 16	第二次预览	JEP 397
Java 17	正式特性	JEP 409	成为正式特性。

JEP 410：移除实验性的 AOT 和 JIT 编译

Java 9 引入了实验性的 Ahead-of-Time (AOT) 编译器和一个实验性的 Just-In-Time (JIT) 编译器，即 Graal 编译器。这些特性最初被引入是为了探索和评估在 Java 虚拟机中提供不同类型编译器的可能性。经过一段时间的实验和社区反馈，发现这些实验性编译器的维护成本较高，而且在实际应用中的使用率并不高。

故而，Java 17 将 Jaotc AOT 编译器和基于 Graal 编译器的实验性 JIT 编译器移除。这样可以简化 JDK 的代码库，降低维护成本。

JEP 411：废弃安全管理器

安全管理器是 Java 平台的一部分，用于提供对 Java 应用的安全限制。它在早期 Java 版本中是重要的安全特性，用于控制 Applets 和其他类型的应用的权限。但是，随着 Java 平台的发展和安全模型的演进，安全管理器的重要性逐渐降低，现代应用通常通过操作系统级别的安全措施和应用架构设计来实现安全。

Java 17 将安全管理器标记为弃用，并在将来的版本中移除。

JEP 412：外部函数与内存 API（第二次孵化）

传统上，Java 使用 Java Native Interface (JNI) 来与本地代码互操作。虽然功能强大，但 JNI 使用复杂且易出错，且性能开销较大。

Java 17 引入一套新的 API，使得 Java 程序能够安全、高效地调用外部函数（如 C 语言函数）和操作外部内存。API 包括：

• 引入了外部函数接口，允许 Java 程序调用 C 语言等外部语言编写的函数。
• 引入了外部内存接口，允许 Java 程序安全地访问和操作本地内存。

Java 版本	更新类型	JEP	更新内容
Java 14	孵化器	JEP 370	引入了外部内存访问 API
Java 15	第二孵化器	JEP 383	优化外部内存访问 API
Java 16	孵化器	JEP 389	引入了外部链接器 API
Java 16	第三孵化器	JEP 393	继续优化
Java 17	孵化器	JEP 412	引入了外部函数和内存 API

JEP 414：向量 API（第二次孵化）

向量 API 是在 Java 16 中作为孵化器引入的，主要是解决 Java 在进行高性能数值计算时的性能限制。Vector API 通过提供一套标准的 API，使得 Java 程序能够以一种高效、简洁且跨平台一致的方式进行向量计算。

Java 17 基于此前版本的反馈和经验进行了改进，第二次孵化。

Java 版本	更新类型	JEP	更新内容
Java 16	第一次孵化	JEP 338	提供一个平台无关的方式来表达向量计算，能够充分利用现代处理器上的向量硬件指令。
Java 17	第二次孵化	JEP 414	对 API 进行了改进，增加了性能优化和新的功能。

---

Java 17 新特性— 模式匹配 的Switch 表达式

Switch 表达式

Java 12 引入 Switch 表达式，它解决了传统 Switch 语句的两个缺陷：

1. “Fall-through” 行为：在没有显式 break 语句的情况下，Switch 语句会从一个 case “穿透” 到下一个 case，忽略了这个会导致不可饶恕的错误。
2. 代码冗余：每个 case，我们都需要重复类似的代码结构，增加了代码的冗余和维护难度。

Switch 表达式引入了 -> 操作符，用于替代传统的冒号（:）。与传统的 Switch 语句不同，使用 -> 的 case 分支不会出现 "fall-through" 现象，因此不需要 break 语句来防止穿透，如下：

    public static String getTypeOfDay(String day) {
        String typeOfDay = switch (day) {
            case "MONDAY", "TUESDAY", "WEDNESDAY", "THURSDAY", "FRIDAY" -> "Weekday";
            case "SATURDAY", "SUNDAY" -> "Weekend";
            default -> "Unknown";
        };
        return typeOfDay;
    }

它虽然解决这两个问题，但是还是有一个不好的地方，就是返回值，比如在处理复杂的逻辑时，仍需依赖外部变量来返回结果，所以 Java 13 对 Switch 表达式进行了扩展，引入 yield关键字来处理多分支结构中的返回值，如下：

    public static String getTypeOfDay(String day) {
        return switch (day) {
            case "MONDAY", "TUESDAY", "WEDNESDAY", "THURSDAY", "FRIDAY" ->  "Weekday";
            case "SATURDAY", "SUNDAY" ->  "Weekend";
            default -> {
                if (day.isEmpty()) {
                   yield "day is empty";
                } else {
                    yield "Unknown";
                }
            }
        };
    }

但是，不知道小伙伴们注意没有，Switch 表达式只有一种类型，如果我们要处理多种类型呢？我们只能这样处理 ：

Object obj = ... // 某个对象

switch (obj.getClass().getName()) {
    case "java.lang.String":
        String str = (String) obj;
        // 处理字符串
        break;
    case "java.lang.Integer":
        Integer i = (Integer) obj;
        // 处理整数
        break;
    case "com.lang.Long":
        Long lon = (Long) obj;
        // 处理MyClass实例
        break;
    // 其他类型
}

这里面的强制转换是不是比较烦？而且有没有很熟悉 ？Java 14 引入的模式匹配是不是可以解决？

模式匹配

instanceof 用于检查一个对象是否是特定类的实例或者该类的子类的实例。它通常用在条件语句中，以确定对象的类型，从而避免在向下转型时发生 ClassCastException。在 Java 14 前，我们一般都是这样写：

if (object instanceof String) {
    // 返回 true，确认是 String 类型，强制转换为 String 类型后使用
    String str = (String) object;
}

if 语句里面的强制转换显得很是多余，所以 Java 14 引入模式匹配的 instanceof 来解决这个问题，它允许在 instanceof 操作符的条件判断中直接定义一个变量，如果对象是指定的类型，这个变量会被初始化为被检查的对象，可以立即使用，无需额外的类型转换，如：

if (obj instanceof String str) {
    // 可以直接使用 str，而不需要显式的类型转换
}

但是这里需要写大量的 if...else，如果它和上面的 Switch 表达式相结合是不是就可以产生不一样的化学反应？

Switch 模式匹配

用于 instanceof 的模式匹配在Java 16 成为正式特性，到了 Java 17 模式匹配的应用扩展到了switch表达式，这标志着 Switch 表达式又得到了一次增强。

在 Java 17 中，switch 表达式允许使用模式匹配来处理对象类型，这样就可以直接在 switch 语句中检查和转换类型，而不需要额外的 if...else 结构和显式类型转换。

switch 模式匹配支持以下几种模式：

1. 类型模式
2. 空模式
3. 守卫模式
4. 常量模式

类型模式

这是一种比较常见的模式，它允许在 switch 语句的 case 分支中直接匹配对象的类型。例如，case String s 允许你在该分支中直接作为字符串类型的 s 来使用，避免了显式的类型检查和强制类型转换。举个例子来说明下：

    @Test
    public void switchTest() {
        Object[] objects = { "Hello", 123, "World", "Java", 3.14, "skjava" };
        for (Object obj: objects) {
            if (obj instanceof Integer intR) {
                System.out.println("为整数型：" + intR);
            } else if (obj instanceof Float floatR) {
                System.out.println("为浮点型：" + floatR);
            } else if (obj instanceof Double doubleR) {
            System.out.println("为双精度浮点数：" + doubleR);
            } else if (obj instanceof String str) {
                System.out.println("为字符串：" + str);
            } else {
                System.out.println("其他类型：" + obj);
            }
        }
    }

我们用 Switch 表达式来改造下：

    @Test
    public void switchTest() {
        Object[] objects = { "Hello", 123, "World", "Java", 3.14, "skjava" };
        for (Object obj: objects) {
            switch (obj) {
                case Integer intR -> System.out.println("为整数型：" + intR);
                case Float floatR -> System.out.println("为浮点型：" + floatR);
                case Double doubleR -> System.out.println("为双精度浮点数：" + doubleR);
                case String str -> System.out.println("为字符串：" + str);
                default -> System.out.println("其他类型：" + obj);
            }
        }
    }

相比上面的 if...else 简洁了很多。同时在 Java 17 之前，Switch 选择器表达式只支持特定类型，即基本整型数据类型byte、short、char和int；对应的装箱形式Byte、Short、Character和Integer；String类；枚举类型。现在有了类型模式，Switch 表达式可以是任何类型啦。

空模式

在Java17之前，向switch语句传递一个null值，会抛出一个NullPointerException，现在可以通过类型模式，将 null 检查作为一个单独的case标签来处理，如下：

    @Test
    public void switchTest() {
        Object[] objects = { "Hello", 123, "World", "Java", 3.14, "skjava" };
        for (Object obj: objects) {
            switch (obj) {
                // 省略...
                case null -> System.out.println("为空值");
                default -> System.out.println("其他类型：" + obj);
            }
        }
    }

case null 可以直接匹配值为 null 的情况。

守卫模式

守卫模式允许我们在 case 标签后添加一个额外的条件。只有当类型匹配并且额外条件为真时，才会进入该 case 块。

比如上面例子，我们要将字符串那块逻辑调整下，比如长度大于 5 的为长字符串，小于 5 的为短字符串，在不使用守卫模式的情况下，我们一般这样写：

    @Test
    public void switchTest() {
        Object[] objects = { "Hello", 123, "World", "Java", 3.14, "skjava" };
        for (Object obj: objects) {
            switch (obj) {
                case Integer intR -> System.out.println("为整数型：" + intR);
                case Float floatR -> System.out.println("为浮点型：" + floatR);
                case Double doubleR -> System.out.println("为双精度浮点数：" + doubleR);
                case String str -> {
                    if (str.length() > 5) {
                        System.out.println("为长字符串：" + str);
                    } else {
                        System.out.println("为短字符串：" + str);
                    }
                }
                case null -> System.out.println("为空值");
                default -> System.out.println("其他类型：" + obj);
            }
        }
    }
复制代码

这种写法就显得不是那么友好，使用守卫模式如下：

    @Test
    public void switchTest() {
        Object[] objects = { "Hello", 123, "World", "Java", 3.14, "skjava" };
        for (Object obj: objects) {
            switch (obj) {
                case Integer intR -> System.out.println("为整数型：" + intR);
                case Float floatR -> System.out.println("为浮点型：" + floatR);
                case Double doubleR -> System.out.println("为双精度浮点数：" + doubleR);
                case String str && str.length() > 5 -> System.out.println("为长字符串：" + str);
                case String str -> System.out.println("为短字符串：" + str);
                case null -> System.out.println("为空值");
                default -> System.out.println("其他类型：" + obj);
            }
        }
    }

使用守卫模式，我们可以编写更灵活和表达性强的代码。

---

Java 17 新特性—增强型伪随机数生成器

随机数，这个没有小伙伴没有用过吧，Java 提供了几个用于生成随机数的类，他们使用起来是这么地简单，以至于我们很少去认真的对待随机数的具体结果，就好像它是真的随机一样。

Java 17 之前的伪随机数生成器

在 Java 17 之前，Java 的随机数生成主要依赖于下面两个核心类：

• java.util.Random
• java.security.SecureRandom

Random

该类是最最基本的伪随机数生成器，它用于生成一系列不完全是真正随机的数字。Random 提供了多种方法来生成不同类型的随机数，包括整数、长整数、浮点数等。

• 生成随机整数

Random rand = new Random();
int randomInt = rand.nextInt(50); // 生成一个0到49之间的随机整数

• 生成随机浮点数

Random rand = new Random();
double randomDouble = rand.nextDouble(); // 生成一个0.0到1.0之间的随机浮点数

java.util.Random 使用起来很简单，但是它有两个很明显的缺陷。

1. 具备可观测性：
   1. java.util.Random 使用的是一个线性同余生成器（LCG）算法，该算法简单但效率不高。
   2. 可观测这意味着 Random 的输出是完全可预测的，如果我们知道种子和算法，完全可以生成相同的随机序列。这在需要高安全性的随机数生成（如加密）时是不合适的。
2. 线程不安全：在多线程环境下，多个线程共享一个 Random 实例可能导致竞争条件和数据不一致。

ThreadLocalRandom

为了解决 Random 的线程不安全问题，Java 推出了 ThreadLocalRandom。ThreadLocalRandom 是一个适用于多线程环境下生成随机数的生成器，它通过为每个线程提供一个独立的随机数生成器实例来解决线程安全问题。

ThreadLocalRandom 使用线程局部变量（Thread-Local）的概念，每个线程访问 ThreadLocalRandom 时，实际上是访问它自己的一个独立实例，这就着不同线程之间的随机数生成器是完全隔离的，而且他们各自内部的种子是完全隔离的，这就保证了随机数生成的独立性，不会因为其他线程的操作而受到影响。

• 使用方法

ThreadLocalRandom random = ThreadLocalRandom.current();   // 获取 ThreadLocalRandom 实例

int randomInt = random.nextInt(10, 50); // 生成10到49的随机整数
double randomDouble = random.nextDouble(1.0, 5.0); // 生成1.0到5.0的随机浮点数

虽然 ThreadLocalRandom 解决了 Random 多线程的问题，但是它依然是基于线性同余生成器，导致它生成的随机数序仍然是可预测的。

SecureRandom

由于 java.util.Random 生成的随机数具备可预测性，所以它不适用一些安全要求较高的场景。java.security.SecureRandom 是 Java 提供的一个用于生成加密强度随机数的类，它是 java.security 包的一部分，专门为需要高安全性的应用场景设计，比如加密、安全令牌生成、会话密钥以及数字签名应用。

SecureRandom 生成的随机数具有高安全性，这是因为它使用了更加复杂和不可预测的算法，而且这些算法通常都是基于操作系统提供的随机性源，例如 Unix/Linux 系统的 /dev/random 和 /dev/urandom，或 Windows 的 CryptGenRandom API。所以它更加适用于加密和安全相关的领域。

当然，我们也可以手动设置种子，但是一般不推荐这样做，因为会降低随机数的不可预测性。

SecureRandom 也提供了多种方法来生成不同类型的随机数：

SecureRandom secureRandom = new SecureRandom();

int randomInt = secureRandom.nextInt();
double randomDouble = secureRandom.nextDouble();

我们还可以指定特定的算法来创建 SecureRandom 实例：

SecureRandom secureRandom = SecureRandom.getInstance("SHA1PRNG");

虽然 SecureRandom 生成的随机数具有强大的安全性，但也恰恰如此，导致SecureRandom 在生成随机数时的性能开销比普通的随机数生成器更高。而且在某些情况下，SecureRandom 可能会因为等待足够的熵（随机性）而导致阻塞，尤其是在使用 /dev/random 作为随机性源的系统上。

Java 17 新特性：增强型伪随机数生成器

RandomGenerator 接口

在 Java 17 之前，Java 主要依赖 java.util.Random 和其子类来生成伪随机数。这些生成器在某些应用场景下不够高效或缺乏必要的特性（例如，长期稳定性、非周期性、能够快速跳跃到序列中的任意位置），为了提供多种新的伪随机数生成器，以满足不同的需求，Java 17 引入增强型伪随机数生成器（PRNG）。

Java 17 为随机数提供了一个全新的接口 RandomGenerator，该接口是 Java 生成随机数的顶层接口&#x