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

#1 楼

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

此外，不可变的集合通常具有与可变的集合不同的实现。考虑一下ArrayList，高效的不变ArrayList根本不是数组！应该使用具有大分支因子的平衡树来实现它，Clojure使用32 IIRC。就像添加内存泄漏一样，仅添加功能更新就使可变集合“不可变”是一种性能错误。 Java为可变性和引用相等性提供了太多不受限制的钩子，使得共享“仅仅是一种优化”。如果您可以修改列表中的元素，并且意识到您刚刚修改了列表中其他20个版本中的元素，可能会有点烦您。有效的不变性，共享，流融合的非常重要的优化，您将其命名为可变性。 （这对于FP宣传人员来说是一个很好的口号）

#2 楼

可变集合不是不可变集合的子类型。相反，可变且不可变的集合是可读集合的同级后代。不幸的是，“可读”，“只读”和“不可变”的概念似乎变得模糊起来，即使它们表示三种不同的含义。或接口类型保证可以读取项目，并且不提供任何直接修改集合的方法，但不能保证接收引用的代码不能以允许修改的方式强制转换或操纵它。只读集合接口不包含任何新成员，而只能由一个类实现，该类保证没有办法以某种方式操纵对它的引用以使集合变型或接收对某些可以这样做。但是，它不保证该集合不会被引用内部的其他内容修改。请注意，只读收集接口可能无法阻止可变类的实现，但可以指定允许突变的任何实现或从实现派生的类均应视为“非法”实现或实现的派生。
不可变集合是只要存在对它的任何引用，它将始终保存相同数据的集合。不能始终响应特定请求返回相同数据的不可变接口的任何实现都被破坏。

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

#3 楼

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


unmodifiableCollection（Collection c）
unmodifiableList（列表列表）
unmodifiableMap（地图m）
unmodifiableSet（集合s）
unmodifiableSortedMap（SortedMap m）
unmodifiableSortedSet（SortedSet s） br />正如有人在对原始问题的评论中指出的那样，返回的集合可能不会被视为不可变的，因为即使无法修改集合（不能从此类集合中添加或删除成员），实际引用的对象如果集合的对象类型允许，则可以修改此集合。如果该类型允许其对象发生突变，则该决定是在该类型的设计中做出的，我看不到对JCF的更改如何改变它。如果不可变性很重要，则集合的成员应为不可变类型。

#4 楼

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

有一定比例的Java程序员意识到unmodifiableCollection()类的Collections方法家族的存在，但是即使在其中，许多人仍然不用理它。

我不能怪他们：一个假装为可读写但如果您错误地调用其“写”方法的接口将抛出UnsupportedOperationException的接口是很邪恶的。

现在，像Collection这样的接口将缺少add()，remove()和clear()方法，这些接口将不是“ ImmutableCollection”接口；这将是一个“ UnmodifiableCollection”接口。实际上，永远不会有“ ImmutableCollection”接口，因为不变性是实现的本质，而不是接口的特征。我知道，这还不是很清楚。让我解释一下。

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

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

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

这些不可变的集合类必须是最终的，这样，当给您引用此类集合时，您肯定会知道无论您是什么人，或其他任何人，它都将作为不可变的集合运行

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


一组不可修改的集合接口。
一组可变的集合接口，扩展了不可修改的集合。
一组实现可变接口的可变集合类，以及扩展地说，也就是不可修改的接口。
一组不可修改的集合类，实现了不可修改的接口，但是大多数情况下作为类传递，以保证不可变。

我已经实现了所有上面的内容很有趣，我正在项目中使用它们，它们像魅力一样工作。

它们之所以如此不是Java运行时的一部分，可能是因为人们认为这样做太多/太复杂/太难理解了。

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

#5 楼

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

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

#6 楼

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

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

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