为什么我们需要不可变类？

Question

我无法了解我们需要不可变类的场景。
你有遇到过这样的要求吗？或者您能给我们任何应该使用此模式的真实示例吗？

Answer 1

不可变类的一个尚未被提及的特性：存储对深度不可变类对象的引用是存储其中包含的所有状态的有效方法。假设我有一个可变对象，它使用深度不可变对象来保存 50K 的状态信息。进一步假设，我希望有 25 次“复制”我的原始（可变）对象（例如，用于“撤消”缓冲区）；复制操作之间的状态可能会发生变化，但通常不会。制作可变对象的“副本”只需要复制对其不可变状态的引用，因此 20 个副本相当于 20 个引用。相比之下，如果状态保存在 50K 的可变对象中，则 25 个复制操作中的每一个都必须生成自己的 50K 数据的副本；保存所有 25 个副本将需要保存超过 1 兆的大部分重复数据。尽管第一个复制操作会生成永远不会改变的数据副本，并且理论上其他 24 个操作可以简单地引用该数据，但在大多数实现中，第二个对象无法请求该数据的副本。知道不可变副本已经存在的信息(*)。

(*) 有时有用的一种模式是可变对象有两个字段来保存其状态——一个采用可变形式，一个采用不可变形式。对象可以被复制为可变或不可变的，并且可以从一个或另一个引用集开始生命。一旦对象想要更改其状态，它就会将不可变引用复制到可变引用（如果尚未完成）并使不可变引用无效。当对象被复制为不可变对象时，如果未设置其不可变引用，则会创建一个不可变副本，并且不可变引用指向该副本。这种方法将比“完整的写入时复制”需要更多的复制操作（例如，要求复制一个已变异的对象，因为上次复制将需要复制操作，即使原始对象再也不会发生变异） ）但它避免了 FFCOW 带来的线程复杂性。

Answer 2

为什么是不可变类？

一旦对象被实例化，它的状态在生命周期内就不能改变。这也使得它线程安全。

示例：

显然是 String、Integer 和 BigDecimal 等。这些值一旦创建，在生命周期内就无法更改。

用例：
使用其配置值创建数据库连接对象后，您可能不需要更改其状态，您可以使用不可变类

Answer 3

来自有效的 Java；
不可变类只是其实例无法修改的类。所有的
每个实例中包含的信息在创建时提供，并且是
在对象的生命周期内固定。 Java 平台库包含许多
不可变类，包括 String、装箱原始类和 BigInte-
ger 和 BigDecimal。这样做有很多充分的理由：
比可变类更容易设计、实现和使用。他们不太容易
错误并且更安全。

Answer 4

不可变类非常适合缓存目的，因为您不必担心值更改。不可变类的另一个好处是它本质上是线程安全的，因此在多线程环境中您不必担心线程安全。

Answer 5

其他答案似乎过于专注于解释为什么不变性是好的。它非常好，我只要有可能就使用它。 但是，这不是你的问题。我将逐点回答您的问题，以确保您获得所需的答案和示例。

我无法了解我们需要不可变类的场景。

这里的“需要”是一个相对术语。不可变类是一种设计模式，与任何范例/模式/工具一样，它可以使构建软件变得更容易。类似地，在 OO 范式出现之前就已经编写了很多代码，但算我一个“需要”OO 的程序员吧。不可变的类，比如面向对象，并不是严格意义上需要的，但我会表现得像我需要它们一样。

您曾经遇到过这样的要求吗？

如果您没有以正确的视角看待问题域中的对象，您可能看不到不可变对象的需求。如果您不熟悉何时有利地使用不可变类，可能很容易认为问题域不需要任何不可变类。

我经常使用不可变类，将问题域中的给定对象视为值或固定实例。这个概念有时取决于视角或观点，但理想情况下，很容易切换到正确的视角来识别好的候选对象。

通过确保阅读各种书籍/在线文章以更好地了解如何思考不可变类，您可以更好地了解不可变对象在哪里真正有用（如果不是绝对必要的话） 。一篇帮助您入门的好文章是 Java 理论与实践：是否要改变变异？

我将尝试在下面给出几个示例，说明人们如何以不同的视角（可变与不可变）看待对象，以阐明我所说的视角的含义。

...您能给我们任何应该使用此模式的真实示例吗？

既然你要求提供真实的例子，我会给你一些，但首先，让我们从一些经典的例子开始。

经典值对象

字符串和整数通常被视为值。因此，发现 String 类和 Integer 包装类（以及其他包装类）在 Java 中是不可变的就不足为奇了。颜色通常被认为是一个值，因此是不可变的 Color 类。

反例

相比之下，汽车通常不被视为价值对象。对汽车建模通常意味着创建一个具有变化状态（里程表、速度、燃油水平等）的类。然而，在某些领域它可能是一个价值对象。例如，一辆汽车（或者特别是汽车模型）可能被视为应用程序中的值对象，用于查找给定车辆的合适机油。

扑克牌

曾经编写过扑克牌程序吗？我做到了。我可以将一张扑克牌表示为具有可变花色和等级的可变对象。一手抽牌扑克牌可能有 5 个固定实例，其中替换我手中的第 5 张牌意味着通过更改其花色和等级 ivar 将第 5 个扑克牌实例突变为新牌。

然而，我倾向于将扑克牌视为一种不可变的物体，一旦创建，它就具有固定不变的花色和等级。我的抽牌扑克手牌将有 5 个实例，更换我手中的一张牌将涉及丢弃其中一个实例并向我的手牌添加一个新的随机实例。

地图投影

最后一个例子是，当我编写一些地图代码时，地图可以以各种 预测。原始代码让地图使用固定但可变的投影实例（如上面的可变扑克牌）。更改地图投影意味着改变地图投影实例的 ivars（投影类型、中心点、缩放等）。

然而，如果我将投影视为不可变值或固定实例，我觉得设计会更简单。更改地图投影意味着让地图引用不同的投影实例，而不是改变地图的固定投影实例。这也使得捕获命名投影（例如 MERCATOR_WORLD_VIEW）变得更加简单。

Answer 6

一般来说，不可变类更容易正确设计、实现和使用。 String 就是一个例子：java.lang.String 的实现比 C++ 中的 std::string 简单得多，主要是因为它的不变性。

不可变性产生特别大差异的一个特定领域是并发性：不可变对象可以在多个线程之间安全地共享，而可变对象必须通过仔细的设计和实现来实现线程安全 - 通常这远非如此一项微不足道的任务。

更新： Effective Java 第二版 详细解决了这个问题 - 请参阅第 15 项：最小化可变性。

另请参阅这些相关帖子：

• 字符串类型不可变的非技术优势
• Java 中不可变对象的缺点？

Answer 7

Joshua Bloch 的《Effective Java》概述了编写不可变类的几个原因：

• 简单 - 每个类仅处于一种状态
• 线程安全 - 因为状态无法更改，因此不需要同步
• 以不可变风格编写可以生成更健壮的代码。想象一下，如果字符串不是不可变的；任何返回 String 的 getter 方法都需要实现在返回 String 之前创建一个防御性副本 - 否则客户端可能会意外或恶意地破坏对象的该状态。

一般来说，使对象不可变是一种很好的做法，除非导致严重的性能问题。在这种情况下，可变构建器对象可以用于构建不可变对象，例如 StringBuilder

Answer 8

哈希图是一个典型的例子。地图的键必须是不可变的。如果键不是不可变的，并且您更改了键上的值，使得 hashCode() 会产生新值，则映射现在已损坏（键现在位于哈希表中的错误位置。）。

Answer 9

Java 实际上是一本参考资料。有时一个实例会被多次引用。如果您更改这样的实例，它将反映到其所有引用中。有时您只是不想用它来提高鲁棒性和线程安全性。然后，不可变类很有用，因此人们被迫创建一个新实例并将其重新分配给当前引用。这样，其他引用的原始实例就保持不变。

想象一下，如果 String 是可变的，Java 会是什么样子。

Answer 10

让我们看一个极端的情况：整数常量。如果我写一个像“x=x+1”这样的语句，我想 100% 确信数字“1”不会以某种方式变成 2，无论程序中其他地方发生什么。

好吧，整数常量不是一个类，但概念是相同的。假设我写：

String customerId=getCustomerId();
String customerName=getCustomerName(customerId);
String customerBalance=getCustomerBalance(customerid);

看起来很简单。但如果字符串不是不可变的，那么我就必须考虑 getCustomerName 可能更改 customerId 的可能性，这样当我调用 getCustomerBalance 时，我会获得不同客户的余额。现在您可能会说，“为什么有人会编写 getCustomerName 函数来更改 id？这毫无意义。”但这正是您可能遇到麻烦的地方。编写上述代码的人可能会认为函数不会更改参数是显而易见的。然后有人必须修改该函数的另一种用法来处理客户在同一名称下拥有多个帐户的情况。他说，“哦，这是这个方便的 getCustomer name 函数，它已经在查找名称了。我只需让它自动将 id 更改为具有相同名称的下一个帐户，并将其放入循环中......”并且然后你的程序开始神秘地无法工作。这会是糟糕的编码风格吗？大概。但在副作用不明显的情况下，这恰恰是一个问题。

不变性简单来说就是某类对象是常量，我们可以将它们视为常量。

（当然，用户可以将不同的“常量对象”分配给变量。有人可以写
字符串 s="你好";
然后稍后写
s=“再见”；
除非我将变量设为最终变量，否则我无法确定它不会在我自己的代码块中发生更改。就像整数常量向我保证“1”始终是相同的数字，但并不是“x=1”永远不会因为写入“x=2”而改变。但我可以确信，如果我有一个不可变对象的句柄，那么我传递给它的函数都不能更改它，或者如果我制作它的两个副本，则对保存一个副本的变量进行更改将不会改变另一个。 ETC。

Answer 11

我们本身不需要不可变类，但它们肯定可以使某些编程任务变得更容易，尤其是在涉及多个线程时。您不必执行任何锁定即可访问不可变对象，并且您已经建立的有关此类对象的任何事实在将来仍然有效。

Answer 12

不可变性有多种原因：

• 线程安全：不可变对象不能更改，其内部状态也不能更改，因此无需同步它。
• 它还保证我通过（通过网络）发送的任何内容都必须处于与之前发送的状态相同的状态。这意味着没有人（窃听者）可以在我的不可变集中添加随机数据。
• 开发起来也更简单。您保证如果对象是不可变的，则不会存在子类。例如 String 类。

因此，如果您想通过网络服务发送数据，并且希望保证结果与发送的结果完全相同，请将其设置为不可变。

Answer 13

我对未来访客的 2 美分：

不可变对象是不错选择的 2 个场景是：

在多线程中

多线程环境中的并发问题可以通过同步很好地解决，但同步是昂贵的事情（不会在这里深究“为什么”），所以如果您使用不可变对象，那么就没有同步来解决并发问题，因为不可变对象的状态无法更改，如果状态无法更改，那么所有线程都可以无缝访问目的。 因此，不可变对象是多线程环境中共享对象的绝佳选择。

作为基于哈希的集合的键

使用基于哈希的集合时要注意的最重要的事情之一是该键应该使其 hashCode() 在对象的生命周期内始终返回相同的值，因为如果该值发生更改，则无法检索使用该对象进入基于哈希的集合的旧条目，因此会导致内存泄漏。 由于不可变对象的状态无法更改，因此它们是基于哈希的集合中作为键的绝佳选择。因此，如果您使用不可变对象作为基于哈希的集合的键，那么您可以确定会有因此不会出现任何内存泄漏（当然，当用作键的对象没有从其他任何地方引用时，仍然可能存在内存泄漏，但这不是这里的重点）。

Answer 14

我将从不同的角度来攻击这个问题。我发现不可变对象让我在阅读代码时变得更轻松。

如果我有一个可变对象，如果它在我的直接范围之外使用过，我永远不确定它的值是什么。假设我在方法的局部变量中创建 MyMutableObject，用值填充它，然后将其传递给其他五个方法。这些方法中的任何一种都可以更改我的对象的状态，因此必须发生以下两件事之一：

1. 我必须在考虑代码逻辑的同时跟踪五个附加方法的主体。
2. 我必须为我的对象创建五个浪费的防御副本，以确保将正确的值传递给每个方法。

第一个使得推理我的代码变得困难。第二个使我的代码性能下降——无论如何，我基本上都是在模仿一个具有写时复制语义的不可变对象，但无论被调用的方法是否实际上修改了我的对象的状态，我都会一直这样做。

如果我改用 MyImmutableObject，我可以确信我设置的值就是我的方法生命周期中的值。没有“幽灵般的远距离动作”可以从我的下方改变它，并且我不需要在调用其他五种方法之前为我的对象制作防御性副本。如果其他方法想要为了他们的目的改变东西他们必须制作副本 - 但他们只有在他们确实必须制作副本时才会这样做（而不是我在每个外部之前都这样做）方法调用）。我节省了自己的脑力资源来跟踪甚至可能不在当前源文件中的方法，并且节省了系统的开销，以防止万一无休止地制作不必要的防御性副本。

（如果我走出 Java 世界，进入 C++ 世界等，我会变得更加棘手。我可以使对象看起来好像是可变的，但在幕后使它们透明地克隆到任何对象上）一种状态改变——即写时复制——没有人更明智。）

Answer 15

不可变对象是其状态一旦启动就不会改变的实例。
此类对象的使用是特定要求的。

不可变类有利于缓存目的并且是线程安全的。

Answer 16

凭借不变性，您可以确保底层不可变对象的行为/状态不会改变，这样您就可以获得执行其他操作的额外优势：

• 您可以使用多个核心/处理（并发/并行处理）轻松（因为操作顺序不再重要。）

• 可以对昂贵的操作进行缓存（因为您确信相同
  结果）。

• 可以轻松进行调试（因为运行历史不会成为问题
  不再）

Answer 17

使用final关键字并不一定会使某些东西变得不可变：

public class Scratchpad {
    public static void main(String[] args) throws Exception {
        SomeData sd = new SomeData("foo");
        System.out.println(sd.data); //prints "foo"
        voodoo(sd, "data", "bar");
        System.out.println(sd.data); //prints "bar"
    }

    private static void voodoo(Object obj, String fieldName, Object value) throws Exception {
        Field f = SomeData.class.getDeclaredField("data");
        f.setAccessible(true);
        Field modifiers = Field.class.getDeclaredField("modifiers");
        modifiers.setAccessible(true);
        modifiers.setInt(f, f.getModifiers() & ~Modifier.FINAL);
        f.set(obj, "bar");
    }
}

class SomeData {
    final String data;
    SomeData(String data) {
        this.data = data;
    }
}

只是一个例子来证明“final”关键字是为了防止程序员犯错，仅此而已。虽然重新分配缺少 Final 关键字的值很容易意外发生，但要更改值必须有意地达到这个长度。它用于文档并防止程序员错误。

Answer 18

不可变数据结构在编写递归算法时也很有帮助。例如，假设您正在尝试解决 3SAT 问题。一种方法是执行以下操作：

• 选择一个未分配的变量。
• 为其指定 TRUE 值。通过取出现在满足的子句来简化实例，然后递归求解更简单的实例。
• 如果 TRUE 情况下的递归失败，则将该变量分配为 FALSE。简化这个新实例，然后递归求解。

如果您有一个可变结构来表示问题，那么当您简化 TRUE 分支中的实例时，您必须：

• 跟踪您所做的所有更改，并在您意识到问题无法解决时撤消所有更改解决了。这会产生很大的开销，因为您的递归可能会非常深入，并且编码起来很棘手。
• 制作实例的副本，然后修改该副本。这会很慢，因为如果您的递归深度有几十级，您将必须制作该实例的许多副本。

但是，如果您以巧妙的方式对其进行编码，则可以拥有不可变的结构，其中任何操作都会返回问题的更新（但仍然不可变）版本（类似于 String.replace - 它不替换字符串，只是给你一个新的）。实现这一点的天真的方法是让“不可变”结构只需复制并在任何修改时创建一个新的结构，当具有可变结构时将其减少为第二个解决方案，并具有所有这些开销，但您可以用更多种方式来实现有效的方式。

Answer 19

“需要”不可变类的原因之一是通过引用传递所有内容并且不支持对象的只读视图（即 C++ 的 const）。

考虑一个支持观察者模式的类的简单情况：

class Person {
    public string getName() { ... }
    public void registerForNameChange(NameChangedObserver o) { ... }
}

如果 string 不是不可变的，则 Person 类就不可能实现 registerForNameChange() 正确，因为有人可以编写以下内容，有效地修改该人的姓名而不触发任何通知。

void foo(Person p) {
    p.getName().prepend("Mr. ");
}

在 C++ 中，getName() 返回 const std::string& 具有按引用返回并阻止访问变元的效果，这意味着在该上下文中不需要不可变类。

Answer 20

他们也给了我们保证。不变性的保证意味着我们可以扩展它们并创建新的模式以提高效率，这是其他方式不可能实现的。

http://en.wikipedia.org/wiki/Singleton_pattern