Java 值对象探讨与实践

值类型与值对象

我们都知道，Java 语言中的类型分为两种：基本类型（primitive type）和引用类型（reference type），这不仅是语言层面的特性，也由 JVM 内在实现支持[1]。

其中，基本类型指是的 8 种基本的数值类型：boolean、byte、char、int、short、long、float、double；而引用类型，指的是对程序中创建的对象的引用，可以理解为指向对象的指针或句柄。Java 号称一切皆是对象，很可惜，这并不是事实，基本类型就不是对象。

那么，值类型又是什么呢？

在你编写程序时，是否经常会遇到一些需要表达数值或其它类型值的场景？比如复数、向量、颜色值、坐标点、时间、日期等。这些值通常无法用基本类型来表达，一则它可能是多个属性构成，二则针对值的一些操作或逻辑我们希望跟数据封装在一起，比如向量的点乘、叉乘、取模等。但如果使用对象来表达同样也会产生很多问题：

▐ 相等性比较

对这些对象的比较是有意义的，但是默认情况下 Java 对象比较的是地址，因此直接比较的结果通常不是我们期待的行为：

▐ 可变性

对引用类型的赋值、方法传参等会生成多个引用，这些引用都指向同一个对象。这在一些情况下是没有问题的，但在某些场景下可能导致对象发生预期之外的变化。如：

上面的 case 比较简单，只要对 Date 的特性有些了解就不会犯这样的错误。但如果对象经过多次传递，使用的位置离创建的位置很远的话，我们就未必能这么谨慎了。这种问题，Martin Flower 称之为 aliasing bug[2]。

▐ 性能

上面两点其实都容易解决，只是每个实现需要写很多样板代码。需要比较的对象只要重写 equals() 和 hashCode 方法即可；对于可变性问题，可以将对象设计为不可变对象，在修改时返回一个深拷贝副本来供客户端操作。满足上述两种条件的对象，我们可以称之为值对象。

那么，通过“对象”来实现我们对这种数据结构的诉求，是否是最好的方式呢？

我们知道，Java 中的对象通常是分配在堆上，通过引用来进行操作，不过这不是必然的。JVM 有一项技术叫逃逸分析[3]，可以在运行时分析出一个方法中创建的对象是否会逃逸到方法或线程外部，如果没有逃逸，可以进而执行一些编译优化，比如栈上分配、同步消除、标量替换等。如果一个对象被分配到栈上，就意味着当方法结束后就会自动销毁，省去了 GC 的开销，这对于优化应用内存占用和 GC 停顿时间来说，无疑是个好消息；而标量替换意味着压根就不会创建对象，相关数据被替换成基本类型数据直接分配到栈上，不仅省去了对象操作相关开销，也更利于 CPU 高速缓存或寄存器进行优化。

对于值对象来说，一般极少有共享的需求，假如能直接在栈上进行分配，那么将省去对象的存储、访问和 GC 的成本，对程序性能非常有利。不过进行逃逸分析也是有成本的，如果在语言层面直接支持的话，就可以进一步减少编译时分析的开销。不过，目前 Java 语言还做不到这一点。

当一门编程语言为上述类型的数据结构提供内在支持时，该类型可称之为值类型。而对于满足上述诉求的实例，无论是基于值类型实现还是普通对象类型实现，我们都可以称之为值对象。

不同编程语言对值类型的支持

▐ Java

上面已经说过，Java 语言层面原生并不支持值类型。不过，它提供了许多具有值类型特点的类，比如：8个基本类型对应的封装类、String、BigDecimal 等，这些类的共同特点之一就是不可变性，同时也都对比较操作做了实现，因此都可看作值对象。另外一个应该设计为不可变、但实际可变的类是 java.util.Date 类，也因为如此，Date 类饱受诟病。在 Java 8 中官方正式推出新的 时间/日期 API，试图取代 Date 相关接口，这些新的类全部被设计成了不可变类。

对于Java 是否应该从语言层面支持值类型的讨论由来已久，比如这篇JEP提案[4]早在 2012 时就提议支持值对象；oracle 论坛上的这篇博客[5]也对如何实现值对象做了探讨。最近有两篇提案，一个提出了 Primitive Object[6]的概念，可算是值类型的一种实现；另外一篇提议基于Primitive Object统一基本类型与对象类型[7]。不过，这两个提案仍处于 Submitted 阶段（JEP 提案从提出到发布的流程有几个阶段，可以看 这里[8] Process states 一节），能否被采纳、实现乃至发布到正式版本，还是未知之数。

▐ C++

C++ 中没有值对象这一概念，不过在创建对象时，允许开发者选择在堆上还是在栈上创建。比如下面的示例代码，直接通过 A a; 的方式创建的对象是分配在栈上的，而通过 new A(); 的方式创建的对象分配在堆上，并且返回一个指向该对象的指针。在栈上创建的对象在函数执行结束时会自动销毁。

更进一步，对 A 类型的对象进行赋值（34行）或方法传参（38行）时，会产生一次拷贝操作，生成一个新的对象，新对象的作用域分别为当前函数和被调函数，相应函数执行结束时也会被销毁。而对指针类型的对象进行赋值（43行）和方法传参（45行）时，尽管创建了新的指针对象，新的指针仍然指向相同的对象。

可见 C++ 中对类类型和指针类型的使用，分别具有值类型和引用类型的一些特点。

▐ C#

C# 语言中是明确的提出了值类型[9]这一概念的，struct 就是一种值类型。MSDN文档中说明：“默认情况下，在分配中，通过将实参传递给方法并返回方法结果来复制变量值。” 在赋值操作时，也同样会对对象进行拷贝。如下面的代码所示，我们可以看到将 p1 赋值给 p2，p2 修改状态后，p1 中的数据仍然保持不变。

另外，在 C# 中值类型是分配在栈上的，值类型与引用类型之间可以进行转化，称之为装箱和拆箱，上面的 Java Primitive Object 提案似乎也借鉴了 C# 的设计思想。

▐ 其它语言

其它编程语言对值类型的支持不尽相同。以函数式编程为例，大多数函数式编程语言中变量都是不可变的，因此在函数式语言中定义的数据结构都可看作是值类型。

DDD 中的值对象

尽管 Java 并没有对值对象提供语言层面的类型支持，但这并不妨碍我们在自己的代码中创建事实上的值对象。实际上值对象[10]的定义可以并不仅限于类似向量、颜色值、坐标点这样一些使用范围。Martin Flower 认为，值对象在编程中的作用被极大的忽视了，善于值对象可以非常有效的简化你的系统代码；Vaughn Vernon 在《实现领域驱动设计》一书中甚至说，我们应该尽量使用值对象建模而不是实体对象。实际上，当提到“值对象”这个概念时，最常见的就是在 DDD（领域驱动设计）这个上下文中。

Eric Evans 在《领域驱动设计 软件核心复杂性应对之道》一书中提出了实体（Enity）与值对象（Value Object）的概念。Vaughn Vernon 在《实现领域驱动设计》中做了进一步阐述。

在 DDD 中，实体代表具有个性特征或需要区分不同个体的对象，它具有唯一标识和可变性。对于实体对象，我们首要考虑的并不是其属性，而是能代表其本质特征的唯一标识，无论对象属性如何变化，它都是同一个对象，它的生命周期具有连续性，甚至对对象进行持久化存储然后基于存储来重建对象，它仍然是同一个对象的延续。

而值对象，它通常是一些属性的集合，是对对象的度量和描述。值对象应该是不可变的，当度量和描述改变时，可以用另外一个值对象替换。值可以跟其它值对象进行相等性比较。

可以看到，在 DDD 中的值对象的定义跟我们上面的描述非常相似。《实现领域驱动设计》对于值对象的阐述非常详尽，想要进一步了解的可以阅读该书第 6 章内容。

使用值对象的好处

因为值对象通常设计为不可变对象，因此值对象的好处首先就是不可变对象的好处。另外在支持值类型的语言中，值对象的创建、操作、销毁会有更好的性能。

▐ 线程安全

在 Java 编程语言中，出现线程安全问题的必要条件有两个：对象状态被多个线程共享；对象状态可变。因此解决线程安全问题的思路也主要从几个方向出发：无状态；状态不可变；不共享状态；通过同步机制来序列化对象状态的访问。

而不可变对象状态是不变的，因此是线程安全的，可以放心应用到并发环境中，无需额外的同步机制在多个线程中共享。

▐ 避免 Alias Bug

Aliasing bug 的概念上文已经讲过，主要是指多个对象的引用被分享到多个环境中后，在某个环境的改动会导致从另外一个环境中看到预期之外的变化。

最近我们的项目中就遇到这样一个 bug，某个对象会被缓存到本地内存中，取出对象后，返回给 UI 层的某个属性值需要根据请求环境做一些判断与变更，由于未做防御性拷贝，导致变化污染了缓存对象，后面的请求出现错误的结果。

而不可变对象不允许修改属性值，任何状态的变化必须通过创建副本来实现，因此可以有效的避免该类 bug。

▐ 简化逻辑复杂程度

• 任何使用到值对象的地方，它的状态始终是合法的。通常不可变对象会在创建时进行自校验，因此一旦创建完成，它始终处于合法有效的状态之中，没有任何行为能使破坏它的一致性状态。
• 可以安全的共享给其它对象、其它线程，而不用担心状态发生变化，简化了代码维护者对流程、逻辑的理解。
• 可以作为构件简化其它对象的状态管理。当其它对象使用不可变对象作为其构件时，由于不可变对象自身状态不变，使得它在被传入和获取时不需要进行防御性拷贝，简化了对象状态的跟踪。

▐ 使你的设计更清晰

值对象与基础类型数据相比，富含业务语义，在任何使用到它的地方，其含义一看便知。它还可以封装跟数据相关的业务逻辑，避免为了复用代码而创建 util 类，更符合面向对象的思想。

▐ 可比较、可以被集合类使用

相信这一点不需要再说明了。

值对象 Java 实践

那么，如何在我们的代码中创建不可变对象呢？我们分为部分内容来讲，第一部分是指导思想，第二部分是如何进行实践。

▐ 值对象创建指南

• 创建不可变对象

在 《Effective Java 第三版》 第 17 条 最小化可变性一节中，将不可变类的设计归纳为五条原则：

• 不要提供修改对象状态的方法
• 确保这个类不能被继承
• 把所有属性设置为 final
• 把所有的属性设置为 private
• 确保对任何可变组件的互斥访问

第 2、3、4 点很容易理解。对第 1 点，也就是说对任何涉及状态变更的操作，都不能直接修改原始对象的状态，而是通过创建对象的副本，比如下面对复数对象的“加”操作：

对于第 2 点，确保类不能被继承，除了将类设为 final，还有一种方式是将构造方法设为 private，并向外提供静态工厂方法来创建实例。

而第 5 点的意思是，“如果你的类有任何引用可变对象的属性，请确保该类的客户端无法获得 对这些对象的引用”。举例而言，下面的 Period 类，尽管满足上面的 1~4 点，但由于其状态变量中包含了引用对象，引用对象通过构造方法与访问方法与外界共享，导致它的状态也会发生变化（第 7 行、第 10 行）：

一个解决方案是，不使用 Date 对象，而是使用 Java 8 中提供的 LocalDate 对象，该对象是不可变的。另一种方案，在引用共享的位置对对象进行拷贝。 由此可以延伸出：

• 尽可能使用不可变对象作为构建对象的组件；
• 必要时对构造方法参数和方法返回值进行防御性拷贝：(第 6、7、14、18 行)

这里还要注意几点：- 进行防御性拷贝应在参数检查之前执行，以避免参数检查可拷贝期间受其它线程对参数更改的影响。

• 必要时，对实现 serializable 接口的类进行反序列化重写 readObject 方法，以避免字节码攻击。对于这一点，简单来讲就是由于 Java 对象的反序列默认通过 readObject 方法重建对象，而不会调用我们提供的构造方法，这使得攻击者可以通过修改字节码数据，从而绕开构造方法中的参数校验的防御性拷贝。具体可以看 《Effective Java 第三版》 第 88 条 保护性的编写 readObject 方法。

• 当构造方法参数过多时，可以借助 builder 设计模式

这一点可参照《Effective Java 第三版》 第 2 条。这里不展开了。

• 尽可能重用实例

由于不变对象在修改数据时会进行拷贝，因此它的一个主要问题就是可能会创建过多的对象，这会带来性能问题。一个方案是，对可能会经常用到的对象提供公共的静态 final 常量。这一点，既可以通过公共的常量字段来实现，也可以通过静态工厂方法来实现。

• 相等性判断

需要重写 equals() 和 hashCode() 方法。至于为什么以及如何实现，相信大家都知道了，就不展开讲了。

• 创建即合法

这一点也很好理解，既然值对象是不可变的，那么创建完成之后没有任何方法可以改变的状态，因此必须在构造时进行必要的合法性校验，使创建出来的对象满足其所有的不变性条件（Invariants）。

▐ 如何实现

• 手写代码

有了指导思想，如何实现其实就一目了然了。只不过，要实现不可变对象，需要创建大量的样板代码，比如 equals() 和 hashCode() 方法的重写、builder 模式的创建等等。这些重复代码不仅写起来费力，而且会使类的核心业务逻辑隐藏在大量的样板代码中，降低了类的可读性。因此，最好实现方式还是借且代码生成工具。

• 基于代码生成工具

(i) lombok @value 注解

lombok 库的 @value 注解可以很方便的帮我们生成一个不可变的值对象类型。如：

如果我们使用 Intellij IDEA 工具，并且安装了 lombok 插件，可以在源代码处 右键 -> Refactor -> Delombok -> All lombok annotations，来查看 lombok 注解处理器处理过后生成的字节码对应的源代码大概是什么样子。

这里有一点需要注意，lombok 工具对于引用类型不会帮我们做防御性拷贝，因此假如我们的构成组件包含可变对象，需要我们自己去做防御性拷贝。做法很简单，只要提供我们自己的构造方法和 get 方法，lombok 就不会再帮我们生成对应的方法。

如果我们要对参数进行合法性校验，也同样需要提供自定义的构造方法，在构造方法中添加校验逻辑。

(ii) lombok @Builder 注解

lombok 的 @Builder 注解非常强大，可以应用在类上、构造方法上，也可以应用在静态工厂方法上。在构建时未传入的参数为该类型的默认值。同样的，如果你需要校验，可提供自定义的全参数构造方法。

上面我们提到过，对值对象的实例尽可能的重用。如果我们使用静态工厂方法，就可以实现这一点：

注意我们把 @Builder 注解放在了 of() 静态工厂方法上面，同时将构造方法设为 private。通过查看生成的代码，发现 builder 的 build() 方法直接调用了该工厂方法。

(iii) lombok @With 注解

@Value 注解会将生成的类设为不可变，如果我们需要修改对象的状态，怎么办？上面说过，修改状态需要创建拷贝。使用 @With 注解可以很方便的做到这一点。

(iv) 与 mapstruct 配合使用

在进行领域驱动设计时，我们经常会在不同的层或者模块之间使用不同的对象，比如持久化层使用跟数据库纪录进行映射的 DO 对象，而在领域层使用更具有业务意义的领域对象。如何在对象之间进行属性的拷贝呢？可以有很多种选择，我最常用的是 mapstruct 工具，该工具非常强大，不仅支持不同名称、不同类型字段的映射，还可以使用表达式、方法调用等。

对于它我们不做过多介绍，有兴趣可以看这里[11]。

在进行属性拷贝时，通常基于无参构造函数创建对象，然后设置对应属性。但是上面的类，我们在实现不可变特性时，不再提供无参构造函数。如何让 mapstruct 支持这种类呢？恭喜你，只要加了 @Builder 注解，什么都不需要做，mapstruct 已经内置提供了对 lombok @Builder 注解的支持。

至于使用其它手段的属性拷贝，我暂时没有去了解，熟悉的同学可以参与讨论。

(v) json 反序列化

我们知道，当使用 json 反序列化工具生成自定义类型的实例时，通常也是使用该类型的默认无参构造方法。假如没有该构造方法，运行时就会抛出异常。但是，我们不希望提供该构造方法来破坏对象的不可变性。怎么办呢？

这里又要祭出 lombok 的另一法宝，@Jacksonized 注解。加上这一注解后，我们的不可变对象就可以被 jackson json 库顺利的创建出来了（需要跟 @Builder 一起使用）。其实这个注解没什么复杂之处，能实现这点得益于 jackson json 库本身对 builder 模式的支持，@Jacksonized 注解只是按照 jackson json 的相关要求生成相关的 builder 类和方法而已。目前 fastjson 库似乎不支持使用 builder 模式来创建对象，不知道后面有没有相关的计划。

总结

本文通过一些简单的案例讨论了值类型与值对象的概念，并且探讨了不同语言对值类型的支持情况。然后对于在 Java 语言中如何创建值对象给出了一些指导原则，并介绍了一些可用于快速实现值对象的工具。值对象的使用是一种非常有用的编程技巧，可以使我们的业务语义更加清晰，并有效的简化代码逻辑的复杂程度。因此，建议大家在自己的代码中多尝试使用值对象，相信在这个过程中必然更有更深刻的认识和感受。

---