Java record 怎样处理可变集合的防御性复制

我在整理一组只读配置对象时遇到过一个很容易被 record 语法掩盖的问题：字段确实是 final，但字段指向的 List 仍可能和调用方共用同一个对象。结果是，record 自己没有提供修改方法，外部代码却能通过原始集合改变它后来读到的内容。

处理方式很明确：可变集合进入 record 时，在 canonical constructor 或 compact constructor 中建立防御性复制；需要只读集合时可以使用 List.copyOf。不过它解决的是集合结构的别名问题，不是所有元素的递归深拷贝。这个区别决定了代码该写到哪一步。

先看 record 为什么仍会暴露可变状态

record 自动生成的字段是私有且 final，访问器也会直接返回组件值。这个设计保证了组件引用不会被 record 自己重新指向另一个对象，却没有改变被引用对象本身的可变性。因此下面的写法看起来简洁，实际仍然保存了调用方的集合引用：

import java.util.ArrayList;
import java.util.List;

record UserGroup(String name, List members) {}

var source = new ArrayList();
source.add("alice");
var group = new UserGroup("reviewers", source);

// 调用方仍持有 source，后续修改会影响 group.members() 看到的内容。
source.add("bob");
System.out.println(group.members()); // [alice, bob]

这里并不是 record 的字段被重新赋值，而是 source 和 members 指向同一份可变列表。官方 Record API 将 record 描述为“浅层不可变”的透明载体，并明确把对可变组件做防御性复制列为显式构造器或访问器的典型用途。

在 compact constructor 里切断集合别名

对组件做复制最顺手的位置是 compact constructor。它保留 record 头部的组件声明，同时允许我们在隐式字段初始化前规范化构造参数：

import java.util.List;

record UserGroup(String name, List members) {
    UserGroup {
        // 复制集合结构并拒绝 null 集合，避免内部状态与调用方共享引用。
        members = List.copyOf(members);
    }
}

var source = new java.util.ArrayList();
source.add("alice");
var group = new UserGroup("reviewers", source);

// 这里修改的是调用方集合，record 内部已经保存了另一份集合结构。
source.add("bob");
System.out.println(group.members()); // [alice]

List.copyOf 的价值有两个：它创建与输入集合结构相互独立的结果，并让结果集合不支持结构修改。这样既避免了构造后调用方继续 add 的别名问题，也避免了调用者通过 accessor 拿到集合后直接改动 record 的集合结构。

如果项目需要兼容更早的 Java 版本，也可以使用 new ArrayList(members) 复制，再通过 Collections.unmodifiableList 暴露只读边界。选择哪种写法应由项目的 Java 基线决定，但关键原则不变：复制要发生在对象接管外部引用的入口。

把 null 和异常边界写清楚

List.copyOf 不接受 null 集合，也不接受包含 null 元素的输入。对配置、请求参数或反序列化数据来说，这种失败通常比构造一个含糊的半有效对象更容易排查；如果业务允许空值，要在复制前把它转换成明确的空列表或先做校验。

import java.util.List;

record PermissionSet(List values) {
    PermissionSet {
        // 业务约定 null 表示“没有权限”，先归一化为空集合再复制。
        var normalized = values == null ? List.of() : values;
        values = List.copyOf(normalized);
    }
}

这里的空值转换是业务规则，不是 List.copyOf 的默认行为。若 null 代表数据缺失而不是空集合，就应该保留校验失败，让调用方修正输入，而不是无条件吞掉信息。

防御性复制不等于深拷贝

最容易被忽略的边界是：List.copyOf 复制的是集合结构和元素引用。假设元素是一个可变的 Permission 对象，调用方不能再向 record 的列表中添加或删除元素，但仍可能通过自己持有的 Permission 引用修改对象字段。

import java.util.List;

final class Permission {
    private String code;

    Permission(String code) {
        this.code = code;
    }

    // 演示元素对象自身仍可被修改；实际项目可改为不可变 record。
    void rename(String nextCode) {
        this.code = nextCode;
    }

    String code() {
        return code;
    }
}

record PermissionSet(List values) {
    PermissionSet {
        // 这里只保护列表结构，不复制每个 Permission 对象。
        values = List.copyOf(values);
    }
}

var permission = new Permission("read");
var set = new PermissionSet(List.of(permission));
permission.rename("write");
System.out.println(set.values().get(0).code()); // write

如果元素也必须不可变，有三种常见选择：让元素本身使用不可变类型；在构造器中把每个元素映射成新的不可变值对象；或者明确把这个 record 定义为“集合结构只读，但元素由外部生命周期管理”。不要用“record + List.copyOf”自动推导出深层不可变结论。

最后检查访问器和对象语义

完成构造器复制后，我通常会再看三件事。第一，访问器是否直接返回内部集合；对 List.copyOf 结果来说，这通常已经足够阻止结构修改，但如果返回的是自定义可变容器，仍要在访问器处复制或包装。第二，元素是否需要深层复制；这取决于元素对象是否会跨边界继续被修改。第三，equals、hashCode 和序列化是否符合业务预期，因为它们会读取组件当前可见的值，而不是读取“构造时快照”。

常见问题

record 的组件字段是 final，为什么还需要复制 List？

final 只限制字段引用重新指向其他列表，不限制原列表内容变化。复制是为了切断调用方与 record 之间的共享引用。

List.copyOf 会复制 List 里的每个对象吗？

不会。它主要复制集合结构并复用元素引用；元素对象是否不可变，需要单独设计。

只在 accessor 里返回 List.copyOf 可以吗？

这能减少外部通过访问器修改结构的机会，但构造时 record 内部仍可能和调用方共用原始列表。通常应先在构造入口复制，必要时再在访问器处建立额外边界。

List.copyOf 适合所有可变集合吗？

它适合把现有集合转成不可修改的 List 结果；如果业务需要保留 null、特殊排序语义或深层快照，应先写清规则，再选择复制实现。

我现在把这条规则当成 record 的一个接管边界：只要组件来自外部且内部状态要稳定，就在构造入口复制；只要元素自身还会变化，就继续往元素类型追问，而不是停在“用了 record”这一步。