当前位置：首页 > 文章列表 > 文章 > java教程 > Java record 怎么防止可变集合从外部改进来：List.copyOf、数组克隆和构造器核对

Java record 怎么防止可变集合从外部改进来：List.copyOf、数组克隆和构造器核对

来源：17golang原创 2026-07-18 11:53:02 0浏览收藏

订单创建接口刚进入服务层，日志里的 labels 还是 [new]；几行代码后却变成了 [new, rush]。排查到最后，record 没有被重新赋值，真正变化的是调用方仍握在手里的 ArrayList。record 能把组件字段固定住，却不会自动切断所有可变对象的别名。

实践要点

List.copyOf 会隔离后续对输入集合的结构性改动，但集合元素本身仍可能可变。
数组要在 compact constructor 中复制一次，并在访问器返回时再复制一次，才能挡住两个方向的改动。
用“构造后改输入、读取后改返回值”两轮检查，比只看 record 没有 setter 更能发现边界问题。

没有 setter，为什么订单命令还是会漂移

record 的组件对应私有字段和访问器，JLS 也规定 record 类隐式为 final。这解决的是“字段能否被重新指向”的问题，不等于组件指向的对象已经不可变。List、byte[]、Map 都可能把同一份可变状态交给多个位置。

接口边界最容易踩中这个坑。控制器把请求体转换成命令对象，后面某个过滤器又继续往原始列表里补标记；或者验签代码复用了同一份字节数组。此时 record 里的引用没有变，引用指向的内容却变了。

先做一个能看见问题的小实验

先别急着把所有组件都复制。先写出最小 record，再在创建完成后改动输入对象。这个过程能很快分辨“字段不可重新指向”和“数据不可被外部改写”不是一回事。

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

public record CreateOrderCommand(
        String customerId,
        List labels,
        byte[] signature
) {}

var inputLabels = new ArrayList(List.of("new"));
var inputSignature = new byte[] {1, 2};
var command = new CreateOrderCommand("u-7", inputLabels, inputSignature);

inputLabels.add("rush");
inputSignature[0] = 9;

// command.labels() 现在会看到 [new, rush]
// command.signature()[0] 现在会看到 9

这里没有任何 setter，也没有发生重新赋值；问题只是 record 保存了原始引用。先把这个复现留在测试里，后面改构造器时才能看到修复是否真的起作用。

Java record 可变引用的原创工程证据图，以低饱和时间线展示输入集合、record 保存引用、外部修改与订单命令内容漂移的过程

在 compact constructor 里截断输入侧别名

针对只包含不可变元素的列表，List.copyOf 是很合适的边界写法：它返回不可修改的 List，之后再改输入集合，返回的 List 不会跟着反映这种结构变化。数组没有这层集合工厂保障，直接复制更直白。

import java.util.Arrays;
import java.util.List;
import java.util.Objects;

public record CreateOrderCommand(
        String customerId,
        List labels,
        byte[] signature
) {
    public CreateOrderCommand {
        customerId = Objects.requireNonNull(customerId, "customerId");
        labels = List.copyOf(labels);
        signature = Arrays.copyOf(
                Objects.requireNonNull(signature, "signature"),
                signature.length
        );
    }

    @Override
    public byte[] signature() {
        return Arrays.copyOf(signature, signature.length);
    }
}

这段代码的关键不是“写得更复杂”，而是明确谁拥有数据：构造完成后，命令对象拥有自己的列表结构和自己的数组内容。调用方继续保留它的输入，也不会再影响命令对象。

List.copyOf 不会把元素做成深层副本

List.copyOf 固定的是 List 容器，不会递归复制每个元素。若组件是 List、List> 或自定义可变 DTO，外部仍可通过元素引用改到 record 里看到的内容。

这时要先做一个取舍：能否把组件类型换成 String、另一个 record 或不可变值对象？如果不能，才为元素写专门的复制函数。只把外层 List 换成 List.copyOf，却把它称为“完全不可变”，会让后面的缓存键、审计快照和并发排查更难解释。

数组还要防住访问器把内部引用交出去

只在构造器里复制数组还不够。默认 accessor 会把内部数组本身返回，调用方拿到后依旧能改内部内容。因此数组场景要有两道门：输入进入时复制，读取出去时也复制。

组件类型	构造时处理	访问器返回	要留意的边界
`String`、`UUID`	通常直接保存	通常直接返回	值对象本身不可变
`List`	`List.copyOf`	直接返回	元素也应是不可变值
`byte[]`	`Arrays.copyOf`	再次 `Arrays.copyOf`	输入和输出两侧都可能改数据
可变 DTO 列表	逐项转换为值对象或复制	只返回安全视图	外层不可改不代表元素不可改

Java record 数组防御式复制的原创工程证据图，以低饱和工程控制台展示构造器复制、访问器复制和最终核对的两道边界

用两轮改动确认边界真的生效

修复后别只看代码外观。第一轮改构造时传入的对象，第二轮改 accessor 拿到的对象；两次都不能影响命令里的状态。下面的检查可以放到单元测试里，错误信息也能把问题定位到输入侧还是输出侧。

var labels = new ArrayList(List.of("new"));
var signature = new byte[] {1, 2};
var command = new CreateOrderCommand("u-7", labels, signature);

labels.add("rush");
signature[0] = 9;
if (!command.labels().equals(List.of("new"))) {
    throw new IllegalStateException("input labels leaked");
}
if (command.signature()[0] != 1) {
    throw new IllegalStateException("input array leaked");
}

var clientCopy = command.signature();
clientCopy[0] = 8;
if (command.signature()[0] != 1) {
    throw new IllegalStateException("accessor array leaked");
}

这个检查只验证别名边界，不替代业务校验。像标签数量、签名字节长度、枚举值是否合法，仍应在 compact constructor 中按业务规则判断；数据复制和数据合法性是两件要分别留痕的事。