在构造期间不允许引用逃脱的其它理由当我们考虑同步的影响时，上面所详细讲述的关于线程安全构造的那些做法就变得更为重要。例如，当线程 A 启动线程 B 时，Java 语言规范（Java LanguageSpecification (JLS)）保证：当线程A 启动线程 B 时，所有那些对线程 A 可见的变量对线程 B 也是可见的，这非常类似 Thread.start() 中隐式同步。如果从构造函数中启动一个线程，并且正在构造的对象还没有完成，则我们会丢失这些可见性的保证。
因为 JMM 有一些令人迷惑的方面，Java Community Process JSR 133正对其进行修订，这将（尤其）会更改 volatile 和 final 的语义，使它们更符合其字面上含义。例如，在当前JMM 语义下，一个线程在其生存期中可能看到 final 字段有多个值。新的内存模型语义将防止这种情形，但只有在正确定义了构造函数的情况下 ― 这意味着在构造期间不允许 this 引用逃脱。
结束语对其它线程能够看见的还未完成构造的对象进行引用显然不是我们所期望的。归根结底，我们如何正确辨别完全构造好的对象和尚未构造好的对象呢？但通过公布来自构造函数内的 this 引用 ― 直接或间接地通过内部类 ― 我们这样做时，会导致无法预料的后果。为了防止这种危险，在创建内部类的实例或从构造函数启动线程时，尽量避免使用 this 。如果无法在构造函数中避免直接或间接使用 this ，则确保不让其它线程看见 this 引用。 |
