导读

Java 酝酿十余年的瓦尔哈拉（Project Valhalla） 项目迎来了关键里程碑。

值类型规范 JEP 401 将合并进 OpenJDK 主线，作为预览功能搭载于 JDK 28。本次改动规模空前，涉及近 20 万行代码；但是架构负责人 Brian Goetz 坦言，该特性即便到下一个长期支持版 JDK 29，大概率仍维持预览状态，开发者不必急于大规模迁移。

甲骨文（Oracle）工程师洛伊斯・福尔坦（Lois Foltan）确认，瓦尔哈拉项目核心提案 ——JEP 401「值类与值对象」，将于 7 月初并入 OpenJDK 主线代码仓库，适配 JDK 28 版本。

当前正式 JDK 版本为 JDK 26，JDK 27 预计于 2026 年 9 月发布，JDK 28 定于 2027 年 3 月上线，而下一个长期支持（LTS）版本 JDK 29 则规划在 2027 年 9 月推出。

福尔坦在 OpenJDK 邮件列表中表示道，本次改动体量极大，她请求社区其他代码提交者在合并窗口期，尽量不要提交大规模重构代码，保障合并流程顺利完成。本次合并对应的 PR 修改了 1816 个文件，新增代码超 197000 行。

JEP 401 诞生于 2022 年 8 月，旨在解决 Java 长期存在的性能短板：除int、double等少数基础原始类型外，其余自定义对象都会附带对象头、身份标识，在数组、高频数据场景产生大量内存开销，这也是大数据、AI、高性能计算场景 Java 内存占用居高不下的核心原因。

核心设计思路：剥离对象身份，解锁底层优化

Java 首席架构师布莱恩・戈茨（Brian Goetz）解读了 JEP 401 的设计逻辑：现有机制迫使所有对象都遵循引用语义，而 JEP 401 第一步就是移除值类的「对象身份」，由此释放大量底层优化空间，小型数据对象的性能提升尤为明显。

但完整落地纯值语义，还需要解决更多底层限制：空值（null）处理、并发竞争下的原子安全（ASUR）等问题，C# 结构体等同类语言特性也在持续打磨这部分能力。

戈茨称，本次改造最大的难点，是在不破坏开发者对「对象封装、完整性」固有认知的前提下，完成底层模型重构。类本身是一套成熟的抽象屏障，改动底层模型很容易打破现有代码的编写习惯。

瓦尔哈拉项目会主动引入少量不兼容变更，典型例子：如果代码对Integer包装类对象执行同步锁synchronized，运行时会直接抛出异常。

版本进度提醒：短期不会转正

戈茨明确提醒开发者，不要对该特性快速转正抱有过高期待：即便到 JDK 29（下一个 LTS 版本），JEP 401 大概率依旧处于预览阶段。“指望它在 JDK 29 脱离预览状态，实在过于乐观。此前向量 API 等大型特性，也经历了多轮预览迭代才正式定型。”

扩展解读

1. 关于瓦尔哈拉项目

瓦尔哈拉项目（Project Valhalla）是 OpenJDK 自 2014 年启动的核心升级计划，与虚拟线程 Loom、本地互操作 Panama 并称 Java 三大长期演进项目，是 Java 8 引入 Lambda 之后，类型系统最大幅度重构。核心目标：

• 新增value关键字定义无身份值类，像普通对象一样支持方法、校验逻辑；
• JVM 自动扁平化存储、标量替换，消除堆分配开销，性能对标原生基础类型；
• 解决泛型不支持原始类型的历史痛点，优化集合、数组内存密度。
• 
  

2. 预览版使用规则

JDK 28 中 JEP 401 默认关闭，开发者启动程序时需要手动开启预览参数才能使用值类语法；API、语法、底层行为仍存在调整可能性，生产业务不建议直接大规模落地，仅适合技术预研、内部工具试水。

3. 行业价值

对于大数据、量化交易、AI 数值计算、游戏服务等高频创建小型数据实体的场景，值类型可大幅降低 GC 压力、减少内存占用，缩小 Java 与 C++、Rust 在数值密集场景的性能差距，补齐 Java 高性能计算短板。

相关术语注释

• Project Valhalla：瓦尔哈拉项目，Java 值类型升级计划
• JEP 401：值类与值对象规范（本次落地核心提案）
• Preview Feature：预览特性，语法 / API 不稳定，不保证跨版本兼容
• Scalarization（标量化）：JIT 优化手段，将值对象拆解为寄存器变量，避免堆内存分配
• Heap Flattening（堆扁平化）：数组 / 对象字段内的值类不再单独分配堆内存，直接平铺存储
• Object Identity（对象身份）：传统 Java 对象具备唯一标识，支持==身份判断、同步锁；值类无身份，仅基于字段值判等

作者：场长