延迟初始化是延迟字段的初始化,直到需要它的值。如果不需要该值,则不会初始化字段。这种技术既适用于静态字段,也适用于实例字段。虽然延迟初始化主要是一种优化,但它也可以用来打破类和实例初始化中的有害循环[Bloch05, Puzzle 51]。
和大多数优化一样,延迟初始化的最佳建议是 “除非必要,否则不要做”( item67 )。延迟初始化是一把双刃剑。它降低了初始化类或创建实例的成本,代价是增加了访问延迟初始化字段的成本。根据这些字段中最终需要初始化的部分、初始化它们的开销以及初始化后访问每个字段的频率,延迟初始化实际上会损害性能(就像许多“优化”一样)。
也就是说,延迟初始化有其用途。如果一个字段只在类的一小部分实例上访问,并且初始化该字段的代价很高,那么延迟初始化可能是值得的。唯一确定的方法是使用和不使用延迟初始化来度量类的性能。
在存在多个线程的情况下,延迟初始化很棘手。如果两个或多个线程共享一个延迟初始化的字段,那么必须使用某种形式的同步,否则会导致严重的错误( item78).本项目中讨论的所有初始化技术都是线程安全的。
在大多数情况下,常规初始化优于延迟初始化。下面是一个通常初始化的实例字段的典型声明。注意final修饰语的使用(item17):
如果使用延迟初始化来破坏初始化循环,请使用同步访问器因为这是最简单明了的选择:、
这两种习惯用法(使用同步访问器进行常规初始化和延迟初始化)在应用于静态字段时都没有改变,只是在字段和访问器声明中添加了静态修饰符。
如果需要在静态字段上使用延迟初始化来提高性能,请使用lazy initialization holder类习惯用法。**这个习惯用法利用了这样一个保证:一个类在使用之前不会被初始化[JLS, 12.4.1]。它是这样的:
第一次调用getField时,它读取FieldHolder.field字段,导致初始化FieldHolder类。这个习惯用法的优点是getField方法不是同步的,只执行字段访问,所以延迟初始化实际上不会增加访问成本。一个典型的VM只会同步字段访问来初始化类。一旦类初始化后,VM对代码进行修补,以便后续对字段的访问不涉及任何测试或同步。
如果需要使用延迟初始化来提高实例字段的性能,请使用双重检查习惯用法。**这个习惯用法避免了初始化后访问字段时的锁定成本( item79 )。这个习语背后的意思是检查字段的值两次(因此得名double check):一次没有锁定,然后,如果字段似乎没有初始化,第二次使用锁定。只有当第二个检查指示字段未初始化时,调用才初始化字段。由于初始化字段后没有锁定,因此将字段声明为volatile非常重要( item78 )。下面是这个习语:
这段代码可能看起来有点复杂。特别是,可能不清楚是否需要局部变量(结果)。该变量的作用是确保字段在已经初始化的常见情况下只读取一次。虽然不是严格必需的,但这可能会提高性能,而且与应用于低级并发编程的标准相比,这更优雅。在我的机器上,上述方法的速度大约是没有局部变量的明显版本的1.4倍
虽然您也可以将双重检查习惯用法应用于静态字段,但是没有理由这样做:延迟初始化holder类习惯用法是更好的选择
双重检查习语的两个变体值得注意。有时候,您可能需要惰性地初始化一个实例字段,该字段可以容忍重复初始化。如果您发现自己处于这种情况,您可以使用double-check习语的变体来避免第二个检查。毫无疑问,它被称为singlecheck习语.它是这样的。注意,字段仍然声明为volatile:
本项目中讨论的所有初始化技术都适用于基本字段和对象引用字段。当将双重检查或单检查习惯用法应用于数值基元字段时,将对该字段的值进行检查
0(数值基本变量的默认值),而不是null。
如果您不关心是否每个线程都重新计算字段的值,并且字段的类型是long或double之外的原语,那么您可以选择在单检查习惯用法中从字段声明中删除volatile修饰符。这种变体称为生动的单检查习语。:它加快了某些架构上的字段访问速度,代价是需要额外的初始化(每个访问该字段的线程最多需要一个初始化)。这绝对是一种奇特的技术,不是日常使用的。
总之,您应该正常初始化大多数字段,而不是延迟初始化。如果必须延迟初始化字段以实现性能目标或打破有害的初始化循环,则使用适当的延迟初始化技术。例如字段,它是双重检查的习惯用法;对于静态字段,延迟初始化holder类习惯用法。对于可以容忍重复初始化的实例字段,您还可以考虑单检查习惯用法。
本文写于2019.7.23,历时1天