Java 8为什么不包含不可变的集合？

Java团队做了很多出色的工作，消除了Java 8中函数编程的障碍。特别是，对java.util集合的更改在将转换链接到非常快速的流式操作方面做得很好。考虑到他们在集合上添加一流的函数和函数方法做得多么出色，为什么他们完全无法提供不可变的集合甚至不可变的集合接口呢？

在不更改任何现有代码的情况下，Java团队可以随时添加与可变接口相同的不可变接口，减去“ set”方法并使现有接口从其扩展，如下所示：

                  ImmutableIterable
     ____________/       |
    /                    |
Iterable        ImmutableCollection
   |    _______/    /          \   \___________
   |   /           /            \              \
 Collection  ImmutableList  ImmutableSet  ImmutableMap  ...
    \  \  \_________|______________|__________   |
     \  \___________|____________  |          \  |
      \___________  |            \ |           \ |
                  List            Set           Map ...

当然，诸如List.add（）和Map.put（）之类的操作当前会返回给定键的布尔值或先前值，以指示该操作是成功还是失败。不可变集合必须将此类方法视为工厂，并返回包含添加元素的新集合-该集合与当前签名不兼容。但这可以通过使用其他方法名称（例如ImmutableList.append（）或.addAt（）和ImmutableMap.putEntry（））来解决。由此产生的冗长性将远远超过使用不可变集合的好处所抵消，并且类型系统将防止调用错误方法的错误。随着时间的流逝，旧的方法可能会被弃用。

永恒收藏的胜利：

• 简单性-当基础数据不变时，关于代码的推理就更简单了。
• 文档-如果某个方法采用不可变的集合接口，则您将知道它不会修改该集合。如果某个方法返回一个不可变的集合，则说明您无法对其进行修改。
• 并发-不可变集合可以在线程之间安全地共享。

作为尝过假定不变性的语言的人，很难回到猖mutation的突变的狂野西部。Clojure的集合（序列抽象）已经具有Java 8集合提供的所有功能以及不可变性（尽管由于同步的链表而不是流，因此可能会使用额外的内存和时间）。Scala具有可变的集合和不可变的集合，具有完整的操作集，尽管这些操作很急切，但调用.iterator可以提供一个惰性视图（还有其他惰性评估它们的方法）。我看不出没有不可变的集合，Java如何能够继续竞争。

有人可以指出我的历史或讨论吗？当然，它在某个地方是公开的。

因为不可变的集合绝对需要共享才能使用。否则，每个操作都会将其他整个列表放入某个位置的堆中。诸如Haskell之类的完全不可变的语言会产生大量垃圾，而无需进行积极的优化和共享。具有只能用于<50个元素的集合不值得放在标准库中。

此外，不可变集合通常具有与其可变的集合完全不同的实现。考虑一下ArrayList，高效的不可变ArrayList根本不是数组！应该使用具有大分支因子的平衡树来实现，Clojure使用32 IIRC。通过添加功能更新使可变集合“不可变”，就像内存泄漏一样，是一个性能错误。

此外，在Java中共享不可行。Java为可变性和引用相等性提供了太多不受限制的钩子，以致于共享“仅仅是一种优化”。如果您可以修改列表中的元素，并且意识到您刚刚修改了该列表的其他20个版本中的元素，可能会有点烦您。

这还排除了非常重要的优化的大类，以实现有效的不可变性，共享，流融合（随便命名），可变性破坏了它。（这将是FP福音传教士的一个很好的口号）

可变集合不是不可变集合的子类型。相反，可变且不可变的集合是可读集合的同级后代。不幸的是，“可读”，“只读”和“不可变”的概念似乎变得模糊起来，即使它们意味着三件事。

• 可读的集合基类或接口类型保证可以读取项目，并且不提供任何直接的方法来修改集合，但不能保证接收引用的代码不能以允许修改的方式强制转换或操纵它。

• 只读的集合接口不包含任何新成员，而只能由一个类实现，该类保证没有办法以某种方式操纵对它的引用以使集合变型或接收对某物的引用可以做到的。但是，它不保证该集合不会被引用内部的其他内容修改。请注意，只读收集接口可能无法阻止可变类的实现，但可以指定允许突变的任何实现或从实现派生的类都应被视为“非法”实现或实现的派生。

• 不可变集合是只要存在对它的任何引用，它将始终保存相同数据的集合。不可变接口的任何实现方式都不能始终响应特定请求而返回相同的数据，这是不可行的。

有时具有实现或衍生自相同“可读”类型的高度关联的可变和不可变集合类型，并使可读类型包括，和方法AsImmutable，这很有用。这样的设计可以使想要将数据持久保存在集合中的代码调用; 如果该集合是可变的，则该方法将生成一个防御性副本，但如果该副本已经不可变，则跳过该副本。AsMutableAsNewMutableAsImmutable

Java Collections Framework确实提供了通过java.util.Collections类中的六个静态方法来创建集合的只读版本的功能：

• unmodifiableCollection（Collection c）
• unmodifiableList（列表列表）
• unmodifiableMap（地图m）
• unmodifiableSet（Set s）
• unmodifiableSortedMap（SortedMap m）
• unmodifiableSortedSet（SortedSet s）

正如有人在对原始问题的评论中指出的那样，返回的集合可能不会被认为是不变的，因为即使无法修改集合（不能从此类集合中添加或删除成员），集合所引用的实际对象如果其对象类型允许，则可以对其进行修改。

但是，无论代码返回单个对象还是对象的不可修改集合，这个问题都将仍然存在。如果该类型允许其对象发生突变，则该决定是在该类型的设计中做出的，我看不到对JCF所做的更改如何改变它。如果不可变性很重要，则集合的成员应为不可变类型。

这个问题问得好。我很喜欢这样一种想法：在用Java编写并在全球数百万台计算机上运行的所有代码中，每天，每天24小时不间断地浪费掉全部时钟周期的一半，而要做的只是制作副本的安全副本。由函数返回。（并在创建这些集合后数毫秒内对其进行垃圾回收。）

一定比例的Java程序员知道类unmodifiableCollection()的方法族的存在Collections，但是即使在其中，许多人也不用理会它。

而且我不能怪他们：一个假装为可读写但UnsupportedOperationException如果您错误地调用其“写”方法中的任何一个都会抛出一个接口是一件很邪恶的事情！

现在，像一个接口Collection，其将被错过add()，remove()而clear()方法不会是一个“ImmutableCollection”界面; 这将是一个“ UnmodifiableCollection”接口。实际上，永远不会有“ ImmutableCollection”接口，因为不变性是实现的本质，而不是接口的特征。我知道，这还不是很清楚。让我解释。

假设有人将这种只读收集界面交给您；将它传递给另一个线程安全吗？如果您确定它代表了一个真正不变的集合，那么答案将是“是”。不幸的是，由于它是一个接口，所以您不知道它是如何实现的，因此答案必须是“ 否”：就您所知，它可能是一个对您来说实际上是可变的集合的（对您而言）不可修改的视图， （就像您从中获得的东西一样Collections.unmodifiableCollection()），因此在另一个线程对其进行修改时尝试从中读取将导致读取损坏的数据。

因此，您实质上描述的是一组不是“不可修改”的集合，而是一组“不可修改的”集合接口。重要的是要理解，“不可修改的”仅意味着阻止引用此接口的任何人修改基础集合，并且之所以被阻止是因为接口缺乏任何修改方法，而不是因为基础集合不一定是不变的。底层集合很可能是可变的。您对此一无所知，也无法控制。

为了拥有不可变的集合，它们必须是类，而不是接口！

这些不可变的集合类必须是最终的，因此，当您引用此类集合时，无论您是什么人，或任何引用它的人，都可以肯定地知道该集合将充当不可变的集合。用它做。

因此，为了在Java（或任何其他声明式命令性语言）中具有完整的集合集，我们需要以下内容：

1. 一组不可修改的收集接口。

2. 一组可变的收集接口，扩展了不可修改的接口。

3. 一组实现可变接口的可变集合类，并且扩展了不可修改的接口。

4. 一组不可变的集合类，实现了不可修改的接口，但大多数都作为类来传递，以确保不可变。

我已经实现了以上所有内容的乐趣，并且在项目中使用了它们，并且它们的工作就像是一种魅力。

它们不属于Java运行时的原因可能是因为人们认为这样做太多/太复杂/太难理解了。

就我个人而言，我认为上面所描述的还不够。似乎还需要做的另一件事是一组可变的接口和类，以实现结构不变性。（因为前缀“ StructurallyImmutable”太长了，所以可以简称为“刚性”。）

与其他对象相比，不可变集合可以进行深度递归，并且如果对象相等是通过secureHash实现的，则不会造成不合理的低效率。这就是所谓的默克尔森林。它可以针对每个集合，也可以位于其中的一部分内，例如排序映射的（自平衡二进制）AVL树。

除非这些集合中的所有java对象都具有唯一的ID或要哈希的某些位串，否则该集合就没有哈希值可以唯一地命名自己。

示例：在我的4x1.6ghz笔记本电脑上，我可以每秒运行200K sha256s，其最小大小适合1个哈希周期（最多55个字节），而long哈希表中的500K HashMap ops或3M ops。对于某些数据完整性和匿名全局可伸缩性很重要的事情，每秒200K / log（collectionSize）新集合的速度足够快。

性能。就其性质而言，馆藏可能很大。将1000个元素复制到具有1001个元素的新结构中，而不是插入单个元素，简直太可怕了。

并发。如果您有多个正在运行的线程，他们可能想要获取集合的当前版本，而不是获取12个小时前线程启动时传递的版本。

存储。在多线程环境中使用不可变的对象，您可以在其生命周期的不同点最终获得“相同”对象的数十个副本。对于Calendar或Date对象无关紧要，但是当它包含10,000个小部件时，它将杀死您。