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創建一個不可變的副本。 更改原始列表不會影響它。

從性能視圖可以看出，不可修改的包裝器的創建更便宜，因為它只創建一個具有單個字段的實例。 新工廠方法將創建至少一個對象，可能由數組支持（如果您有三個或更多元素），它需要復制到該對象中。

新的不可變集合的訪問速度可能更快，但必須進行基准測試。

但正確性勝過表現。 你需要什么？ 如果您需要一個不可變的副本 ，請使用新方法（或者我更喜歡的Guava的Immutable... ）。 如果你需要一些不可變的東西 ，可以使用unmodifiable...並扔掉原來的（並確保它保持原樣）。 如果您需要調用者無法編輯的視圖，請使用unmodifiable...

Answer 2

根據JEP 269（便利工廠收集方法） ：

目標

在集合接口上提供靜態工廠方法，這些方法將創建緊湊的，不可修改的集合實例。 API故意保持最小化。

非目標

• 提供完全通用的“集合構建器”設施並不是一個目標，例如，它允許用戶控制集合實現或各種特性，例如可變性，預期大小，加載因子，並發級別等。

• 支持具有任意數量元素的高性能，可伸縮集合並非目標。 重點是小集合。

• 提供不可修改的集合類型不是目標。 也就是說，即使提議的實現實際上是不可修改的，該提議也沒有暴露類型系統中的不可修改的特征。

• 提供“不可變持久性”或“功能性”集合不是目標。