Guava ImmutableList ......究竟是什么支持它？答案

【问题标题】：Guava ImmutableList... what exactly is backing it?Guava ImmutableList ......究竟是什么支持它？
【发布时间】：2014-12-15 01:12:26
【问题描述】：

出于好奇，我下载了 Google Guava 的源代码，以了解支持不可变集合的原因。

我正在浏览 ImmutableList，我注意到它仍然由一个老式数组支持，如 Object[]

所以我只是好奇，Object[] 数组本质上可能是可变的，而且它不是线程安全的。我已经知道 ArrayList 和 CopyOnWriteArrayList 由 Object[] 数组支持，但它们是可变的。

那么 ImmutableList 是否只是不可变和线程安全的，因为它的内部属性被很好地封装和保护了？它是否也是不可变的和线程安全的，因为封装确保在构造后不会修改它？是否有朝一日这样的低级数组会被替换为更好的东西而不是遗留的东西，并且本质上是不可变的和最终的，而不是通过仔细封装而不是不可变的？

【问题讨论】：

如果仔细封装有效，他们为什么还要费心添加不可变数组？（而且你只需要编写仔细的封装一次）。
另一种观点：他们确实添加了不可变数组。他们被称为ImmutableList。
另一种看待它的方式：堆内存都是可变的，而使其不可变的原因是“只有小心封装”。不可变的低级数组可能对某些东西有用，但如果封装足以实现不可变列表，则不需要它们。如果您不打算改变某些东西，并且该语言允许您将其标记为不可变，这有点像您永远不会意外改变它的编译时测试。
（除非我忘记了一些线程安全问题，但我希望封装使数据竞争变得不可能。）

【解决方案1】：

是的，ImmutableList 是“唯一”不可变的，因为它不允许修改其内部支持数组。

这与java.lang.String 的情况完全相同，它也包装了一个私有char[]。同样，非常有用的并发库主要是作为常规 Java 类实现的，仅依赖于非常少（而且非常基本）的 JVM 同步原语。

所以这应该足够了。显然，编写这些库类的人必须小心且知识渊博，但是通过将更“低级”的代码移动到 JVM 原语中，这一要求并不会神奇地消失。（同意，您现在可以使用像反射这样的黑暗巫术来打自己的脚，但这几乎不会偶然发生，并且在常规使用中，“用户空间”实现同样有效）。

会有一天吗

这纯属猜测。但显然有关于“值类型”的工作，这是一个相关的主题。

【讨论】：