实际上，如果你使用上面建议的维基百科定义，String不是不可变的。

字符串的状态改变后构造。看一下hashcode()方法。String将hashcode值缓存在本地字段中，但直到第一次调用hashcode()才计算它。这种对hashcode的惰性求值将String置于一个有趣的位置，作为状态发生变化的不可变对象，但如果不使用反射，就无法观察到它发生了变化。

所以也许不可变的定义应该是一个不能被观察到已经改变的对象。

如果一个不可变对象在创建后状态发生了变化，但是没有人可以看到它(没有反射)，这个对象仍然是不可变的吗?

其中一个含义与值如何存储在计算机中有关，例如，对于一个。net字符串，它意味着内存中的字符串不能被更改，当你认为你正在更改它时，你实际上是在内存中创建了一个新的字符串，并将现有的变量(这只是一个指向其他地方的实际字符集合的指针)指向新的字符串。

不可变对象是指创建后不能修改的对象。一个典型的例子是字符串字面量。

越来越流行的D编程语言通过“不变”关键字具有“不变性”的概念。查看Dr.Dobb关于它的文章http://dobbscodetalk.com/index.php?option=com_myblog&show=Invariant-Strings.html&Itemid=29。它完美地解释了这个问题。

“不可变”意味着你不能改变值。如果你有一个String类的实例，你调用的任何方法，只要看起来是在修改这个值，实际上都会创建另一个String。

String foo = "Hello";
foo.substring(3);
<-- foo here still has the same value "Hello"

要保存更改，您应该这样做 Foo = Foo .sustring(3);

当您使用集合时，不可变与可变可能会很有趣。想想如果使用可变对象作为map的键，然后更改值会发生什么(提示:考虑equals和hashCode)。

不可变的对象在创建后不能改变其状态。

尽可能使用不可变对象有三个主要原因，所有这些都将有助于减少你在代码中引入的错误数量:

It is much easier to reason about how your program works when you know that an object's state cannot be changed by another method Immutable objects are automatically thread safe (assuming they are published safely) so will never be the cause of those hard-to-pin-down multithreading bugs Immutable objects will always have the same Hash code, so they can be used as the keys in a HashMap (or similar). If the hash code of an element in a hash table was to change, the table entry would then effectively be lost, since attempts to find it in the table would end up looking in the wrong place. This is the main reason that String objects are immutable - they are frequently used as HashMap keys.

当你知道一个对象的状态是不可变的时，你还可以在代码中做一些其他的优化——例如缓存计算的哈希——但这些都是优化，因此没有那么有趣。

不可变对象

一个对象被认为是不可变的，如果它的状态在被构造后不能改变。对于创建简单、可靠的代码，最大程度地依赖于不可变对象是一种被广泛接受的合理策略。

不可变对象在并发应用程序中特别有用。由于它们不能改变状态，因此不会被线程干扰破坏或在不一致的状态下观察到。

程序员通常不愿意使用不可变对象，因为他们担心创建新对象的成本，而不是在适当的地方更新对象。对象创建的影响经常被高估，并且可以被一些与不可变对象相关的效率所抵消。这包括减少垃圾收集带来的开销，以及消除保护可变对象不受损坏所需的代码。

下面的子节采用一个实例是可变的类，并从中派生一个具有不可变实例的类。在这样做的过程中，他们给出了这种转换的一般规则，并演示了不可变对象的一些优点。

源