关于Java 24中List.copyOf(...)方法存在冗余数组创建的疑问

你观察得太细致了——这个冗余数组创建的问题，本质是Java集合框架在代码复用、安全性和性能之间做的权衡，咱一步步拆解来看：

先复盘现有代码的冗余点 #

从你贴的源码能清晰看到整个流程的冗余：

1. List.copyOf 调用 ImmutableCollections.listCopy，当无法直接返回原集合时，会执行 List.of(coll.toArray())
2. 当集合元素数量超过2个时，List.of 会触发 listFromArray 方法，而这个方法的核心逻辑是重新创建数组并复制元素：

@SafeVarargs static <E> List<E> listFromArray(E... input) {
    // copy and check manually to avoid TOCTOU
    @SuppressWarnings("unchecked") E[] tmp = (E[])new Object[input.length];
    // implicit nullcheck of input
    for (int i = 0; i < input.length; i++) {
        tmp[i] = Objects.requireNonNull(input[i]);
    }
    return new ListN<>(tmp, false);
}

这里的矛盾点在于：coll.toArray() 已经生成了一个全新的数组，但 listFromArray 又做了一次完全没必要的复制操作。

为什么Java团队会这么设计？ #

核心是两个层面的权衡选择：

• 通用API的防御性安全要求：List.of(E...) 是公共API，它必须能处理任意传入的数组——这个数组可能是用户手动创建的、甚至可能被外部代码持有并修改。listFromArray 里的防御性复制是为了避免TOCTOU（时间检查到时间使用）漏洞：如果传入的数组在空值检查和存入不可变列表之间被外部修改，可能会引入null元素或非法值。而 List.copyOf 只是复用了这个通用实现，没有为 coll.toArray() 这个特定场景做定制化优化。
• 代码复用的优先级高于局部性能：Java团队一直很注重减少重复代码，维护成熟的通用实现比为单个场景写专用逻辑的长期成本更低。List.copyOf 复用 List.of 的代码，能避免重复的空值检查、数组处理逻辑，但代价就是牺牲了这部分可以优化的性能。

你的优化思路完全合理 #

你提出的「遍历 coll.toArray() 结果做非空检查，再直接传入 ListN 构造」的方案，确实能精准砍掉冗余的数组复制，在大集合场景下能明显提升性能，逻辑上完全站得住脚。

至于你提到的新增 directCopyOf 方法的想法，也非常贴合性能敏感场景的需求——当用户能自行保证集合中无null元素时，跳过空值检查能进一步降低开销。不过Java团队在新增API时会非常谨慎，需要权衡API复杂度和性能收益的平衡点，这个需求是否能落地，还要看社区的反馈和团队的优先级。

内容来源于stack exchange