随着技术的不断更新迭代，一些曾经被认为是 “标准答案” 的观点和方法，已经不再适应当前的需求，甚至被视为过时的做法。在新的 JDK 版本中，许多新的特性、工具和方法被引入，使得 Java 编程变得更加简洁、高效和强大。所以，是时候对 “八股文” 进行一次知识库的清理和更新了。

一、String 里不再使用 char[]

在 JDK9 之前，String 内部是通过 char 数组（char[]）来保存字符数据的。但在 JDK9 以后，String 的实现内部改为使用 byte 数组（byte[]）。这样做的主要原因是为了节省内存空间，因为对于大量的拉丁文系列字符（如英文、数字、常见的标点符号等），使用 byte 数组存储比使用 char 数组可以节省一半的空间。

同时，String 类的内部还引入了一个名为 coder 的 byte 类型的字段。这个字段是用来标识存储在 byte 数组中的数据是何种字符编码的。在新的 String 类的实现中，存在两种可能的字符编码：ISO-8859-1（一个字符占用一个字节）和 UTF-16（一个字符占用两个字节）。对于 ISO-8859-1 编码的字符串，coder 的值为 0，而对于 UTF-16 编码的字符串，coder 的值为 1。这样，通过检查 coder 字段的值，就可以知道存储在 byte 数组中的数据应该使用什么样的编码方式进行处理，从而避免了因为字符编码不同而导致的处理错误。

二、switch 支持的类型不再局限于基本类型与 String

讲这一点之前，首先要了解什么是 “模式匹配”，模式匹配是一种语言特性，用来检查某一个值是否匹配某种模式，并根据结果执行相应的代码，在 Scala 和 Haskell 中模式匹配是一项核心特性，而在 Java 中，模式匹配的概念在 JDK14 后被引入。

简单而言，模式匹配可以让你检查一个变量或值的类型是否符合设定的的某些规则（模式），如果符合 / 不符合，就可以执行一些特定的操作。比如通过模式匹配，可以指定下面这样的操作（JDK14）：

Object obj = "hello";
    if (obj instanceof String str) {
        System.out.println(str.length());
    }

在这个例子中，“String str” 就是一个模式，同时完成了类型检查（instanceof）和向下转型（赋值给变量 str），使得代码更为简洁。在 JDK17 中，switch 也支持了这一功能：

Object obj = 10L;
    switch (obj) {
        case String str -> System.out.println("str: " + str);
        case Integer intNum -> System.out.println("int: " + intNum);
        case Long longNum -> System.out.println("long: " + longNum);
        default -> throw new IllegalStateException("Unexpected value");
    }

不过目前的模式匹配主要还是应用在类型检查的时候自动转换（略简陋），在其他语言中，模式匹配还可以实现各种功能，比如在匹配的同时提取复杂数据结构中的值：

val list = List(1, 2, 3)
list match {
  case head :: tail => println(s"head: $head, tail: $tail")
  case Nil => println("empty list")
}

在这个例子中 head :: tail 就是一个模式，将队列的头尾分别放入 head 和 tail 对象中，从而执行下一步操作。

三、synchronized 的偏向锁已经被废弃了

首先来回顾一下什么是偏向锁。偏向锁是 Java 中 synchronized 关键字的一种优化手段，基本思想是同一个线程的反复访问无需加锁，主要目标是消除数据在没有竞争的情况下的同步操作，提高运行时性能。实际执行时，如果一个线程获得了锁，那么锁就进入偏向模式，此时记录下线程 ID，当这个线程再次请求锁时，无需再做任何同步操作，这样就省去了大量有关锁申请的操作。

但是在真实情况中，偏向锁并不总能带来预期的性能优势，相反地，在某些情况下（多核处理器环境），偏向锁的撤销需要进入全局安全点（即 safepoint，虚拟机将所有的线程暂停执行），会带来比较长的停顿时间。

偏向锁想法是好的，但是增加了 JVM 的复杂性，同时也并没有为所有应用都带来性能提升。因此，在 JDK15 中，偏向锁被默认关闭，在 JDK18 中，偏向锁已经被彻底废弃（无法通过命令行打开）。

四、G1 推出后，分代回收的策略也发生了变化

这个大家相对比较熟悉，因为 JDK7 已经引入了 G1 垃圾收集器，在 JDK9 中被设置为默认的垃圾收集器。在 G1 中，没有严格的年轻代和老年代的划分，而是分为多个大小相同的独立区域，每个区域在不同的时间点可能会扮演不同的角色。

五、不需要考虑 JDK 与 JRE 的关系了

JDK 和 JRE 都是 Java 的重要组成部分，但它们的角色和用途是不同的。JDK 是 Java 开发工具包，主要用于开发 Java 应用。它包含了 JRE，同时还提供了一些额外的工具，如编译器（javac）、调试器（jdb）等。JRE 则是运行 Java 应用程序所需的环境。它包含了 Java 虚拟机（JVM）和 Java 类库，也就是 Java 应用程序运行时所需的核心类和其他支持文件。

在 JDK 8 及之前的版本中，Oracle 会提供独立的 JRE 和 JDK 供用户下载。也就是说，你可以只安装 JRE 来运行 Java 程序，也可以安装 JDK 来开发 Java 程序。

然而从 JDK 9 开始，Oracle 不再单独发布 JRE。取而代之的是 jlink 工具，可以使用这个工具来生成定制的运行时镜像。这种方式简化了 Java 应用的部署，因你只需要分发包含你的应用和定制运行时镜像的包，不需要单独安装 JRE。

六、泛型可能不再是 “语法糖”

提起 Java 的泛型，很多人第一时间想到的就是 “语法糖”、“类型擦除”。类型擦除是 Java 泛型的一种实现机制。这意味着在编译时，泛型类型会被替换为它的限定类型（如果没有明确指定，那就是 Object），并且在字节码中并不保留泛型信息。

比如，如果你有一个如下的泛型类：

public class Box<T> {
    private T object;

    public void set(T object) { this.object = object; }
    public T get() { return object; }
}

在编译后，这个类会变成：

public class Box {
    private Object object;

    public void set(Object object) { this.object = object; }
    public Object get() { return object; }
}

类型擦除最大的优点就是保证了与老版本 Java 代码的兼容性**，因为在引入泛型之前的 Java 代码都是没有泛型信息的。但类型擦除毕竟是不得已为之，会有一些缺点，比如无法执行某些类型检查、导致方法签名冲突等。

接着， Valhalla 项目出现了，Valhalla 项目是 OpenJDK 的一个长期项目，它的主要目标是为 Java 引入一些改进和新特性，包括泛型的专门化。目前 Java 的泛型实现使用了类型擦除，这意味着泛型信息只存在于编译时，而在运行时则被擦除。泛型的专门化意味着泛型信息可以保留到运行时，从而可以根据类型参数生成特定的代码，提高运行效率，并且实现更安全的类型。

不过 Valhalla 项目的步子迈的有点大，进展比较慢，有很多人说这个项目 “凉了”。尽管如此，很多新特性已经在预览版本实现了，未来就会在正式版中出现。

七、Java 可以在接口中定义私有方法

Java 中的接口的目的是定义公开的 API，而不是实现方法细节，所以在 JDK8 以前都不支持默认和静态方法。但是出于便捷性的考虑，JDK8 中支持方法的默认实现，这样当一个接口有大量实现类的情况下，可以在不破坏原有实现的前提下迭代 API。

JDK8 中接口类的默认实现解决了模型抽象中的很多问题，随之而来的是在接口中的默认方法如果需要共享一些代码段，只能将这些代码段抽象出一个新的函数。如果这个函数是静态的（JDK8 支持接口中定义静态函数），那么在函数里无法访问其他非静态 API；如果是一个有默认实现的 API，就会导致实现类可以自由重载。而且最重要的是，不管怎么样，API 都会被暴露出去，这不是开发者想要看到的。

最终，JDK9 允许了开发者在接口中定义私有方法，从而提取和封装默认方法中的公共代码，减少代码的冗余。