不可变集合的真正优势是什么？
Scala 提供不可变集合，例如Set、List、Map。我知道不变性在并发程序中具有优势。然而，在常规数据处理中，不变性到底有什么优势呢？
例如，如果我枚举子集、排列和组合会怎样？ 不可变集合在这里有什么优势吗？
Scala provides immutable collections, such as Set, List, Map. I understand that the immutability has advantages in concurrent programs. However what are exactly the advantages of the immutability in regular data processing?
What if I enumerate subsets, permutations and combinations for example? Does the immutable collections have any advantage here?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
一般来说，不可变对象更容易/更简单地推理。
Generally speaking, immutable objects are easier/simpler to reason about.
确实如此。由于您正在枚举一个集合，因此您可能希望确保在枚举时不会无意中添加或删除元素。
不变性在很大程度上是函数式编程的一个范例。使集合不可变允许人们将它们视为原始数据类型（即修改集合或任何其他对象会导致创建不同的对象，就像将 2 与 3 相加不会修改 3，而是创建 5 一样）
It does. Since you're enumerating on a collection, presumably you'd want to be certain that elements are not inadvertently added or removed while you're enumerating.
Immutability is very much a paradigm in functional programming. Making collections immutable allows one to think of them much like primitive data types (i.e. modifying a collection or any other object results in creating a different object just as adding 2 to 3 doesn't modify 3, but creates 5)
扩展马特的答案：根据我的个人经验，我可以说，使用可变集合的基于搜索树（例如广度优先、深度优先、回溯）的算法的实现通常最终会变成一堆热气腾腾的垃圾：要么你忘记复制集合在递归调用之前，或者如果您取回集合，则无法正确取回更改。在这个领域，不可变集合显然更优越。当我无法解决 Java 集合的问题时，我最终用 Java 编写了自己的不可变列表。你瞧，第一个“不可变”的实现立即生效了。
To expand Matt's answer: From my personal experience I can say that implementations of algorithms based on search trees (e.g. breadth first, depth first, backtracking) using mutable collections end up regularly as a steaming pile of crap: Either you forget to copy a collection before a recursive call, or you fail to take back changes correctly if you get the collection back. In that area immutable collections are clearly superior. I ended up writing my own immutable list in Java when I couldn't get a problem right with Java's collections. Lo and behold, the first "immutable" implementation worked immediately.
如果您的数据在创建后不会更改，请使用不可变数据结构。您选择的类型将确定使用意图。任何更具体的问题都需要了解您的特定问题空间。
您可能确实在寻找子集、排列或组合生成器，那么数据结构的讨论就没有意义了。
另外，您提到您了解并发优势。据推测，您在排列和子集上使用了一些算法，并且该算法很有可能在某种程度上可以并行化。如果是这种情况，预先使用不可变结构可确保算法 X 的初始实现能够轻松转换为并发算法 X。
If your data doesn't change after creation, use immutable data structures. The type you choose will identify the intent of usage. Anything more specific would require knowledge about your particular problem space.
You may really be looking for a subset, permutation, or combination generator, and then the discussion of data structures is moot.
Also, you mentioned that you understand the concurrent advantages. Presumably, you're throwing some algorithm at permutations and subsets, and there's a good chance that algorithm can be parallelized to some extent. If that's the case, using immutable structures up front ensures your initial implementation of algorithm X will be easily transformed into concurrent algorithm X.
我有几个优点可以添加到列表中：
不可变集合不能在你的控制下失效
也就是说，Scala 类拥有不可变的 public val 成员是完全可以的。根据定义，它们是只读的。与 Java 相比，您不仅必须记住将成员设为私有，而且还要编写一个返回对象副本的
get方法，以便调用代码不会修改原始对象。不可变的数据结构是持久的。这意味着通过在
TreeSet上调用filter获得的不可变集合实际上与原始集合共享一些节点。这意味着时间和空间的节省，并抵消了使用不变性带来的一些损失。I have a couple advantages to add to the list:
Immutable collections can't be invalidated out from under you
That is, it's totally fine to have immutable public val members of a Scala class. They are read-only by definition. Compare to Java where not only do you have to remember to make the member private but also write a
getmethod that returns a copy of the object so the original is not modified by the calling code.Immutable data structures are persistent. This means that the immutable collection obtained by calling
filteron yourTreeSetactually shares some of its nodes with the original. This translates to time and space savings and offsets some of the penalties incurred by using immutability.一些不变性的优点：
1 - 误差范围更小（你总是知道集合和只读变量中有什么）。
2 - 您可以编写并发程序，而不必担心修改变量和集合时线程相互干扰。
some of immutability advantages :
1 - smaller margin for error (you always know what’s in your collections and read-only variables).
2 - you can write concurrent programs without worrying about threads stepping on each other when modifying variables and collections.