List.of(...)或Collections.unmodifiableList()

Question

如果你有一个List<String> strings实例,你会继续写:

Collections.unmodifiableList(strings)

或切换到:

List.of(strings.toArray(new String[strings.size()]))

实例的性能(内存和运行时)的初始影响是什么？List.of变体中是否有运行时优势？

Answer 1

这不是一个很好的比较,因为这些方法做了不同的事情:

• Collections::unmodifiable...创建一个不可修改的视图.它不是不可变的,因为如果您正在更改原始的后备集合(list在您的示例中),它会发生变化.
• ...::of另一方面,创建一个不可变的副本.更改原始列表不会影响它.

从性能视图可以看出,不可修改的包装器的创建更便宜,因为它只创建一个具有单个字段的实例.新工厂方法将创建至少一个对象,可能由数组支持(如果您有三个或更多元素),它需要复制到该对象中.

新的不可变集合的访问速度可能更快,但必须进行基准测试.

但正确性胜过表现.你需要什么？如果您需要一个不可变的副本,请使用新方法(或Immutable...我更喜欢的番石榴).如果你需要一些不可变的东西,请使用unmodifiable...并扔掉原件(并确保它保持原样).如果您需要调用者无法编辑的视图,请使用unmodifiable....

Answer 2

根据JEP 269（集合的便利工厂方法）：

目标

在将创建紧凑、不可修改的集合实例的集合接口上提供静态工厂方法。API 故意保持最小。

非目标

• 目标不是提供一个完全通用的“集合构建器”工具，例如，让用户控制集合实现或各种特性，如可变性、预期大小、加载因子、并发级别等。

• 支持具有任意数量元素的高性能、可扩展集合并不是目标。重点是小集合。

• 提供不可修改的集合类型不是目标。也就是说，这个提议没有暴露类型系统中不可修改的特性，即使提议的实现实际上是不可修改的。

• 提供“不可变的持久性”或“功能性”集合不是目标。