不可变对象非常好，因为它们在多线程应用程序中不需要特别的关心或维护。然而，许多对象几乎不能自然地成为不可变对象。例如，一个订单被提交，处理后，在订单填写时分配一个永久ID。该ID无法在订单创建和提交时给出，但稍后（或者可能永远）到达。
可能的解决方案：
这些解决方案合理吗？还有其他想法吗？谢谢。
将类设置为不可变，并将null设置为ID的有效值。当您有要分配的ID时，用一个新的对象替换现有的不可变对象，该对象与旧对象完全相同，只是具有新的ID而不是旧的ID。我喜欢使用名为withX的方法来实现这个目的。
Foo foo = new Foo("bar");
...
foo = foo.withId(12345); // replace foo with new derived object
对我来说，它们听起来像是两个不同的对象，一个是“订单”，另一个是“已完成订单”。其中一个是另一个的副本，并带有一个id...
你对不可变性感兴趣的原因是什么？它将如何影响您的领域模型？例如，我曾经看到过“领域”对象具有id字段，只是为了取悦Hibernate，但它们在Hibernate给它们分配id值之前并不具备id值。在这种情况下，“领域”对象很弱。
从“业务透视”的对象模型（在我的学术示例中）来看，似乎不需要id。然而，从“技术透视”的模型来看，需要一个id（更具体地说，Hibernate需要一个id）。显然存在紧张关系，所以我喜欢清楚地表达我试图建模的内容（业务或技术）。
顺便问一下，在您的示例中，id代表什么？
因此，当我们考虑“身份”（以Eric Evans的意义）的概念时，为了使一个对象或实体存在，它必须具有一个身份（如果它们的身份相等，则实体相等，无论其内容是否相等）。对我来说，这意味着
新建一个没有身份（在这种情况下是id）的实体是没有意义的
我还建议
不存在“几乎”不可变的对象，它要么是不可变的，要么不是
如果您使用上述解决方法，则应明确指出您的对象不再是不可变的。这可能没问题（再次问问自己为什么需要不可变性？）。我认为，拥有可以具有null id的领域对象（稍后将其替换为副本）并不是一个好主意。这会产生“特殊情况”，可以通过不同的建模方式避免，并使您在许多地方处理特殊情况（可能性）。
我认为第二种方法最好，必要时使用同步。延迟初始化和同步对象getter的开销可能是微不足道的。
我还怀疑，如果比较完整的实现，第一种方法将具有等效（或更差）的开销。例如，它将需要同步Map，或者使用一个具有自身开销的并发映射。而且，该映射是一个共享数据结构，这意味着争用的机会比通常未共享对象上的getter更高。
定义一个ID持有者类，其中包含一个ID字段。当创建订单时，使用空白ID创建一个新的ID持有者对象，并将其分配给订单。订单本身在技术上是浅不可变的，但只要不尝试为不同的订单“重复使用”ID持有者对象，就可以对ID持有者对象进行的唯一更改是应该应用于订单或其任何副本的更改。
withX(..)还是像Stephen C建议的那样进行同步更好。还涉及到一些其他问题，例如应用程序显示（GUI或控制台）。我认为选择哪种方式取决于它将如何使用。在我的情况下，我仍在分析中。 - Pete