Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28

value class USDCurrency implements Comparable<USDCurrency> {
    private int cents; // 隐式 final
    public USDCurrency(int dollars, int cents) {
        this.cents = dollars * 100 + cents;
    }

    public USDCurrency plus(USDCurrency that) {
        return new USDCurrency(0, this.cents + that.cents);
    }
}

它也可以是一个值记录（value record）。规则如下：所有实例字段都隐式为 final，方法不能是 synchronized 的，类默认是 final 的（或者它可以形成一个由值类和抽象值类组成的层次结构），它不能继承自具有身份的类，但它可以愉快地实现接口。除了这些限制之外，它就是一个普通的类。

定义特征：没有身份。这是关键所在。一个普通对象具有身份：两个分别创建的 new Point(1,2) 是两个不同的对象，即使它们的内容完全相同。而值对象没有身份，就像没有两个“不同”的 int 类型的 4。由此引申出所有后果：

- == 的含义发生了变化。到目前为止，== 比较的是身份（是否是同一个地址）。对于值对象，== 检查的是可替换性：是否是相同类且字段相同（递归比较，基本类型字段逐位比较，对象字段再次通过 == 比较）。这就是为什么 new USDCurrency(3,95) == new USDCurrency(3,95) 返回 true。这是个好消息：它结束了在 Integer 上使用 == 时著名的混淆。但要注意：== 检查的是内部状态，而内部状态并不总是对象所代表的内容，因此对于“是否是相同数据”的比较，仍应使用 equals。

- synchronized 抛出异常。没有可同步的对象。尝试同步会导致 IdentityException。当你需要强制身份时，可以使用新的辅助方法 Objects.requireIdentity 和 Objects.hasIdentity。

现在最重要的概念陷阱是：值对象仍然可以为 null。这会让所有认为“值对象就像基本类型一样，永远不会为 null”的人感到惊讶。在 JDK 28 模型中，值类是一个引用类型，因此 USDCurrency d = null; 是完全合法的。不可为 null 的类型（带有 null 限制）是另一个、未来的 JEP。它们不在 JDK 28 中。我们稍后再回到这一点，因为它不是一个细节：它是实现完全性能的关键。

### 它在内存中的存储方式

JEP 401 给 JVM 提供了自由，使得值对象可以通过两种主要方式优化。

标量化（scalarization）是一种 JIT 编译器技术。对值对象的引用被“分解成基本元素”，简化为它的本质，即字段的集合，没有任何包装。JIT 不再传递指向 Color 的指针，而是直接传递三个字节 r、g、b（加上一个标志位，表示引用是否不为 null）。这种对象在实践中是免费的：无需分配，GC 也不需要处理。这有点像逃逸分析，但更可预测、影响范围更广：它甚至可以在 JIT 没有内联的方法调用边界上工作。限制是：当变量的类型是值类的超类型（例如 Object 或者重要的是擦除后的泛型参数）时，标量化通常无法工作。此时，对象必须在堆上被实例化。

堆扁平化（heap flattening）是第二种机制。对象的本质被编码为一个紧凑的位向量，并直接写入字段或数组单元中，而不需要指向内存中其他位置的指针。这正是密度和局部性产生的地方。

这里有一个值得注意的限制：扁平化数据必须能够原子地读取和写入（否则在并发访问时可能会出现“撕裂”现象）。在典型的平台上，目前“足够小”意味着小到仅需 64 位，包括空标志（null flag）。这就是为什么许多小型值类可以很好地扁平化，但一个包含两个 int 字段或一个 double 字段的类可能无法容纳在原子写入中，最终仍然作为堆上的普通对象存在。未来，128 位编码将出现，前述 JEP 关于限制空类型的提案将允许扁平化更大的类，但代价是放弃原子性保证。这正是非空性不再仅仅是装饰，而成为性能提升杠杆的时刻。

### 以新的视角看待装箱和拆箱

还记得装箱（boxing）的古老成本吗？将 int 包装成 Integer 的成本。在新的模型中，包装类本身会变成值类（当预览功能开启时，Integer、Long、Double 等类将失去其身份）。由于装箱不再具有身份，JVM 可以对其进行标量化和扁平化处理。其效果是：Integer[] 开始接近 int[] 的效率，装箱的开销，如 JEP 401 所述，显著减少。伴随的 JEP 402（增强原始类型装箱）更进一步，平滑了原始类型与其包装类之间的转换，为编写如 List<int> 的代码铺平了道路。但这是另一个仍在成熟中的部分，因此不要假设它会与 JEP 401 完全同步推出。

### 数组

这是效果最明显的地方。不再需要存储指向一百万个分散对象的百万个指针，Color[] 数组可以直接存储连续颜色的 32 位编码（再次强调：加上空标志）。从内存角度来看，这样的数组开始像普通的 int[] 一样表现：一块连续的数据块，处理器可以按顺序逐行缓存访问。

为了让所有这些都得以实现，一些非常基础的底层机制被重新构建：新的值修饰符；严格的构造规则（所有字段必须在任何对象可见之前设置，实际上是在 super() 调用之前，以确保 final 字段的“突变”永远不会被观察到）；重新定义 == 为可替代性测试；在引用比较字节码（acmp）中添加值对象检查；标量化和扁平化机制；IdentityException；以及现有“基于值”的类的迁移。简而言之，这不仅仅是语法糖。这是对一个假设的重建：自 1995 年以来，Java 中的每个对象都具有身份。

## 5. 一个实际例子 - 在 Valhalla 之前和之后，逐步分析

让我们从最简单的例子入手，并逐步追踪，即使不了解 JVM 的内部机制，也能清楚理解。

在 Valhalla 之前：

内存中发生了什么？points 数组是一个包含一百万个指针的数组。每个指针都指向堆中某个位置的一个独立的 Point 对象。每个对象不仅仅是两个 int（8 字节），还包括一个头（大约十几个字节的元数据）。这些对象是分散的：分配器在不同的时间、不同的位置创建了它们。当你遍历数组并求和坐标时，处理器对每个点都要执行以下操作：从数组中读取指针，跳转到指定的地址（可能造成缓存未命中），读取字段。这个过程要重复一百万次。这正是第 1 节中提到的“松散”布局。

在 Valhalla 之后：

代码中的区别只在于一个词：value。但内存中的区别却是根本性的。JVM 现在可以将值本身存储在数组中，紧密地依次排列：每个点 8 字节（加上一个可能的 null 标志），在一个连续的块中。每个元素没有头，没有指针，也没有在堆中四处跳转。

[图片：Point[] 数组的两种变体：“之前”（一个指向分散的带有头的框的箭头数组）和“之后”（一个统一的数字对条带）]

现在遍历数组时，处理器可以按顺序读取数据。每个 64 字节的缓存行都会立即带入几个完整的点。以内存带宽速度求和一百万个坐标，而不是因未命中而受阻。在数据密集型代码中，这可能带来倍数级的差异，而不仅仅是百分比级的差异。

而且，对可维护性来说最重要的是，你不需要为此付出抽象的代价。Point 仍然是一个类：它有名称，有构造函数，可以有验证（例如 if (x < 0) throw ...），可以有方法。你不需要像之前那样，将点拆分成两个原始的 int[] xs 和 int[] ys 数组，并祈祷你永远不会混淆索引。你获得了原始数据的密度和类的可读性。这就是整个 Project Valhalla 在一个例子中的体现。

### 6. 专用泛型 - 类型擦除为何有害（以及正在采取哪些措施）

这是 Valhalla 的第二部分，说实话，也是更难理解的部分。让我们从问题的根源开始。

Java 通过类型擦除实现泛型。实际上：List<String> 和 List<Integer> 在运行时是相同的普通 List，类型参数 T 被擦除为 Object。这经常被嘲笑，但值得知道的是，这是一个有意为之、有正当理由的决定，而不是懒惰。擦除为 Java 提供了渐进迁移的兼容性：你可以将一个现有的非泛型类转换为泛型，而无需破坏任何现有的源文件或编译后的类，客户端可以立即、稍后或永远不迁移。2004 年，当 Java 已经拥有一个庞大的代码库时，另一个选择（“这里有泛型，但扔掉你所有的库”）将是一个糟糕的交易。今天，这会更糟糕。

问题是，擦除与 Valhalla 在我们最关心性能的地方发生了冲突。由于 T 被擦除为 Object，放入 List<Point> 中的值对象必须作为堆上的普通对象进行实例化。换句话说：你漂亮且可以扁平化的 Point 在泛型集合中失去了扁平化：容器保存的是引用，而不是扁平的值。你在 Point[] 中获得的密度在 ArrayList<Point> 中完全蒸发。

修复计划，就像 Valhalla 的其他部分一样，分为两个阶段：

第一阶段：通用泛型。这是一个语言层面的更改：它允许类型变量也覆盖值类型，也就是说，你可以甚至表达像 `ArrayList<Point>` 或 `List<int>` 这样的结构。目前仍然通过擦除实现。程序员主要会感受到新的编译器警告，关于“空值污染”，因为类型为 `T` 的字段默认初始值为 `null`，即使 `T` 是一个值类型。处理这些警告将使 API 变得“可专门化”。

第二阶段：专门化泛型。这些是未来 JVM 的扩展，将为具体的类型参数生成异构的、专门化的类布局（在项目术语中称为“物种”和“类型限制”）。只有到那时，`ArrayList<Point>` 才会真正由扁平内存支持。这部分目前仍主要是研究工作。

这对库和框架的影响是巨大的，这正是为什么它会逐步进行的原因。最终，集合、流和整个 API 都可以基于值类型变成扁平的、无需分配的。但库作者必须处理新的警告，并在设计时考虑到专门化。老实说：最初的通用泛型草案经历了重写，而专门化的全部好处将取决于未来的版本。JDK 28 并不会带来它。

### 7. JDK 28 具体意味着什么

让我们在这里集中说明这一点，因为很容易在“它已经在这里了！”和“它还没到”之间迷失。

已被接受的内容：JEP 401（值类和对象）作为预览功能，目标是 JDK 28（2027 年 3 月发布），计划在 2026 年 7 月左右整合到主线版本中。涉及 197,000 行代码，1,816 个文件，Lois Foltan 方面的协调工作，对其他提交者请求暂时不要进行大规模更改。默认情况下是禁用的：如果你想尝试这种语法，必须启用 `--enable-preview`。

实际到达用户的内容：声明值类和值记录的能力；将 JDK 中现有的“基于值”的类（包括像 Integer 这样的原始包装类）迁移到预览的值类中；对符合条件的类进行标量化和扁平化；更便宜的装箱操作。

仍可能演变的内容，以及 JDK 28 中没有的内容：空值限制类型（不可为空）；完整的专门化泛型；128 位编码；一个完全成熟的 JEP 402。还有语法本身，因为这是预览功能，这正是它的预期：它可以根据反馈在每次发布时发生变化。因此 Goetz 关于“只有第一部分”的引言。

对生态系统的影响：对于高性能 Java（数据、向量计算、机器学习、游戏开发、金融、编解码器）来说，这是实现密集数据而不放弃抽象的路径，这正是这些领域中一些人等待多年的东西。框架和库将开始迁移它们的基于值的类。你还需要注意代码中（有意或无意）依赖于身份的 `==` 和 `synchronized` 周围可能出现的大量行为意外。还有一个在规划时值得记住的点：JDK 28 不是一个“LTS”版本：下一个 LTS 可能是 2027 年 9 月的 JDK 29。因此，大多数公司只有在 LTS 中才能遇到稳定版的 Valhalla，但正是 JDK 28 中的预览功能才真正开启了与实际代码的反馈循环。如果你正在做能从这受益的事情，现在就是开始实验和提交反馈的时刻。

## 8. 总结

为什么我称这是平台历史上最大的变化之一？因为 Valhalla 并没有在语言上又添加一个功能；它改变了语言最深层的假设。“每个对象都有身份”这一原则自 1995 年以来一直适用于 Java，它是所有其他内容的基础。让程序员可以选择是否放弃这一假设（决定哪些对象需要身份，哪些不需要）并不是一次重构，而是基础的转变。这正是为什么它能够开启未来十年的工作：统一基本类型和对象、专门化泛型、更密集的集合、更快的数值计算。

同时，这也是标题的诚实版本：“Valhalla 进入 JDK 28”是一个半真半假的说法。这只是多阶段发布的第一步，也是预览阶段。但正是这个团队的纪律（简化模型以适应人类，将性能相关的工作作为可选）才导致了这一变化耗时十二年，也正是因为这一点，它现在才有可能被发布。

对我们这些程序员来说，有一个要点比语法更重要：要内化“身份”与“值”的区别。其余的内容（==、扁平化、泛型）都是这一区别的结果。而且，早期访问构建已经可以使用了：你可以在竞争对手之前，亲自在自己的代码中尝试这一功能。

## 最后，我经常被问到的问题 😊

1. 值类只是记录类吗？不，它们是两个相互独立的决定。记录类意味着“我放弃单独的内部状态”（内容 = 组件）。值类意味着“我放弃身份”。你可以有任意组合：普通类、记录类、值类、值记录类。

2. 我可以使用 == 比较值对象吗？可以，但 == 现在意味着不同的内容：可替换性，即对所有字段（递归地）进行比较，而不是内存地址。对于“它们是否表示相同的数据”这个问题，通常还是使用 equals 更好，因为 == 看的是内部状态，而内部状态并不总是等于表示的状态。

3. 值类可以为 null 吗？在 JDK 28 模型中，是的。值类仍然是引用类型。不可为 null 的类型（带有 null 限制）是另一个、未来的 JEP，它们将解锁更大值类的扁平化。它们不在 JDK 28 中。

4. Integer 变成值类，这会不会破坏我的代码？在大多数情况下，不会。二进制文件仍然可以链接，唯一新的编译错误是尝试对这种类型进行同步。你可能会注意到的变化是那些依赖于身份的代码：对 Integers 使用 == 将开始按值进行比较，而 synchronized (someInteger) 将不再起作用。如果你依赖于这两者中的任何一个，那你的代码本来就是脆弱的。

5. 我能获得一个快速且扁平的 ArrayList<Point> 吗？目前还不能。由于类型擦除，泛型集合中的对象在堆上被实例化。扁平化的泛型集合需要通用和专门化的泛型：这是未来。在 JDK 28 中，扁平化直接适用于值类型的字段和数组，例如 Point[]。

6. 这与 C# 中的 struct 有什么不同？C# 中的 struct 有身份和可变性，因此赋值或传递时的复制语义必须被明确定义，这为程序员带来了更复杂的模型，也限制了运行时的自由度。Valhalla 中的值对象没有身份，它们在内存中的布局由 JVM 自行决定。这为人类带来了更简单的模型，也为机器带来了更多的自由。

7. 难道逃逸分析不是已经在做这些事情了吗？正如我之前提到的，部分是这样。逃逸分析可以在证明对象不依赖于身份时避免分配对象，但它不可预测，而且当对象出现在字段中、数组中或“逃逸”到优化范围之外时，它无法提供帮助。值对象的标量化是可预测的，并且可以扩展到更远的范围，包括跨方法调用边界。

8. 我是否需要重写代码才能受益？对于你自己的类，通常只需为那些表示“简单领域值”且不依赖于身份的类添加值修饰符即可；迁移过程大多是兼容的。你甚至会获得一些免费的收益，因为JDK正在迁移它自己的类（如原始包装类）。

10. 我什么时候才能看到完整的Valhalla，包括泛型、非空类型以及所有其他特性？将在未来的版本中实现。团队会逐步发布：JDK 28是值类的第一个预览版本。完整的故事（专用泛型、限制空类型的类型、128位编码等）将分布在多个版本中，很可能在下一个LTS版本时才趋于稳定。

PS：你可以在 jdk.java.net/valhalla 找到早期访问版本，这可能是最快形成自己观点的方法，比我再写一篇关于该主题的文章更快。