摘要：Value Objects 是 Java 语言演进史上一次触及根本的变革，源自 Project Valhalla 长达十余年的探索。它通过消除对象身份、移除对象头与间接引用，让对象像基本数据类型一样紧凑高效地驻留内存，彻底化解了自 1995 年“二元类型系统”诞生以来持续数十年的“性能税”。这一特性将重塑 Java 的内存模型与性能表现，被视为 Java 迈入下一个 30 年的关键底牌。

随着 java 27 发布日期的临近，java 28 的功能也开始审议了，其中有一个非常重磅的功能已经targeted了，就是 JEP 401 Value Objects。

这项功能来自 Project Valhalla，立项于2014年，可谓是十年磨一剑，将成为 Java 有史以来最强的更新。

历史地位

1995 年 Java 诞生时，设计者做出了一个折中妥协：“二元类型系统”。这种分裂导致了后来的Integer自动装箱开销、List<Integer>内存碎片化与 CPU Cache Miss 等持续数十年的“性能税”。Value Objects 彻底消除了这个“原罪”，实现了 Valhalla 的终极愿景：Codes like a class, works like an int!。

在 Java 30 年的历史长河中，划时代的更新我认为有三个

1. Java 5 (2004)泛型 (Generics) 奠定了现代 Java 强类型编程的框架
2. Java 8 (2014)函数式编程 (Lambda 表达式) 使 Java 代码在保证类型安全的前提下变得非常灵动
3. Java 21 (2023)虚拟线程 (Virtual Threads) 重构了 Java 的线程模型，性能空前释放

而即将到来的 Value Object 将会是比这些还要重要的历史级更新，泛型和函数式编程虽然大大改变了程序员的编码习惯，但本质上都只能算是语法糖，都没有动 Java 最根本的内存模型（此处非指JMM，是对象和基本数据类型的内存结构）。虚拟线程算是一套工具类，接管了本来属于操作系统的调度工作，可以算是此前最重磅的更新。Value Object 的革命性就在于，它重塑了“对象”本身的定义。 消除了 Identity，改写了垃圾回收（GC）对内存的观察方式与 CPU 寄存器分配逻辑。它是 Java 迈入下一个 30 年、应对现代 CPU 硬件架构和云原生高密度计算的最关键一张底牌。 它标志着 Java 彻底摆脱了“笨重、耗内存”的历史刻板印象，在保持高级语言抽象能力的同时，能获得接近硬件底层的性能表现。

下面我们由几个问题入手，从外围一窥 Value Object。

Value Objects 有何不同

• 无身份（identity-free）
• 无对象头
• 无间接引用
• ==对比值而不是内存地址
• 不能被 synchronized
• 不可修改
• ...

Value Objects 有很多特点，所有这些的根源在于无身份（identity-free），就像内存里存了两个int值1，你无法区分哪个是哪个，它的值就是一切，这应该就是 Value Objects 这个名称的由来吧。

Value Objects 与 Records

一看到 Value Objects 容易让人想到 DDD 中的值对象，就进一步联想到 Java 16 发布的 Records 特性。但实际上 Value Objects 跟 Records 是完全两个维度的东西，甚至可以组合使用，成为 Value Objects 版的 Records。

value record Point(int x, int y) {}

Records 是 Project Amber，这个项目的目标就是探索小而美的语言特性（explore and incubate smaller, productivity-oriented Java language features），简言之就是发糖——语法糖。所以 Records 就是类的一种应对特殊使用场景的简写形式。而 Value Objects 则是直击本质，成为与基本数据类型和对象并列的第三种数据类型。

不向后兼容？

Value Objects 的 == 与普通对象不同，并且不能用于 synchronized，Java 不向后兼容了吗？这可能确实是极少见的 Java 不向后兼容的情况，也能从侧面看出本次改动的收益之大。为了这次不兼容，Java 16 还专门上线 JEP 390: Warnings for Value-Based Classes，提前6年做了预告，也是为了能平滑过渡。

有人给出 == 更符合直觉，synchronized(包装类型) 是反模式，等等理由，说这不算不向后兼容。但在我看来就是文字游戏罢了，Date 的 getMonth()，0-11代表1-12月也不符合直觉，甚至 Date 本身在今天看来就是反模式，为了向后兼容，Java 也从来不会动它。只能说 Value Objects 给的实在太多了。

包装类型缓存

Integer a = 1000; Integer b = 1000; System.out.println(a == b); Integer c = 50; Integer d = 50; System.out.println(c == d);

类似上面这种代码，大家在刷面试题是肯定没少见，Value Objects 上线后，大家的面试题就得更新一下了。

自动拆装箱（Autoboxing）

Autoboxing 还是有的，不过开销大大降低。Value Objects 作为对象，是可以为 null 的，而基本数据类型不行，所以两者还是有区别的，以前有的问题也还是有，比如 null 拆箱报错。

总结

Value Objects 是 Java 语言演进史上一次真正触及根本的变革。它通过消除对象身份（identity）、移除对象头与间接引用，让对象能够像基本数据类型一样紧凑、连续地驻留内存，从而彻底化解了自 1995 年“二元类型系统”诞生以来就存在的“性能税”。这不仅意味着List<Integer>这类容器不再碎片化、CPU Cache Miss 大幅减少，更标志着 Java 在保持高级语言抽象能力的同时，重新获得了接近硬件底层的性能表现。

从长期看，Value Objects 的影响将远超语法层面。它重塑了“对象”本身的定义，改写了垃圾回收对内存的观察方式与 CPU 寄存器分配逻辑，为 Java 迈入下一个 30 年、应对云原生高密度计算与数据密集型应用提供了最关键的一张底牌。可以预见，主流框架（如 Spring Data、Hibernate）与集合库都会围绕这一新数据类型进行深度优化，Java 生态的整体内存效率与并发能力将迎来一次系统性升级。

对开发者而言，现在正是提前布局的时机。建议持续关注 JEP 401 的最新进展，理解 Value Objects 与 Records、基本数据类型之间的边界与组合方式，并重新审视项目中依赖对象身份、synchronized或包装类型缓存的既有代码。当 Value Objects 正式落地时，那些曾经需要靠技巧规避的性能问题，将有机会以更自然、更优雅的方式得到解决。