Java 中的不可变关键字是个好主意吗？

Question

一般来说，我在 Java 中使用不可变对象的次数越多，我就越认为它们是一个好主意。从自动线程安全到无需担心克隆或复制构造函数，它们有很多优点。

这让我想到，“不可变”关键字会出错吗？显然，在语言中添加另一个保留字有一些缺点，我怀疑这主要是由于上述原因而实际上会发生 - 但忽略了我真的看不到很多缺点。

目前必须非常小心以确保对象是不可变的，即使这样，一个狡猾的 javadoc 评论声称一个组件对象是不可变的，而实际上它是不可变的，这可能会破坏整个事情。还有一种说法是，即使像字符串这样的基本对象也不是真正不可变的，因为它们很容易受到反射攻击。

如果我们有一个不可变的关键字，编译器肯定可以递归检查并给出一个铁一般的保证，即一个类的所有实例都是不可变的，这是目前无法做到的。尤其是随着并发越来越多，我个人觉得给这个效果加个关键字比较好。但是是否有任何我遗漏的缺点或实现细节使这成为一个坏主意？

Answer 1

一般来说，不可变对象应该优先于有状态对象，目前在 Java 中创建不可变对象相当困难。事实上，大多数面向对象语言对不可变对象的支持很差，而大多数函数式语言认为它们是理所当然的，例如 F#、Haskell 和 Clojure。

向 Java 添加不可变关键字可以使代码...

• 更容易写。不会弄乱finaland private，不会意外添加使类可变的方法，也可能不会手动标记类final（子类可以添加可变状态）。
• 更容易阅读。你不需要用英语说 class is immutable ，你可以在代码本身中说。不可变关键字是朝着自记录代码迈出的重要一步。
• 更快（理论上）。编译器对您的代码了解得越多，它可以进行的优化就越多。如果没有这个关键字，每次调用都new ImmutableFoo(1, 2, 3)必须创建一个新对象，除非编译器可以证明您的类不能被变异。如果ImmutableFoo用immutable关键字标记，每个这样的调用都可以返回相同的对象。我很确定new必须始终创建一个新对象，这使得这一点无效，但与编译器的有效通信仍然是一件好事。

Scala 的 case 类类似于不可变关键字。在C# 5 中也考虑了一个不可变的关键字。