Effective Java(3rd)-Item83 明智地使用延迟初始化

  延迟初始化是延迟字段的初始化，直到需要它的值。如果不需要该值，则不会初始化字段。这种技术既适用于静态字段，也适用于实例字段。虽然延迟初始化主要是一种优化，但它也可以用来打破类和实例初始化中的有害循环[Bloch05, Puzzle 51]。
  和大多数优化一样，延迟初始化的最佳建议是 “除非必要，否则不要做”( item67 )。延迟初始化是一把双刃剑。它降低了初始化类或创建实例的成本，代价是增加了访问延迟初始化字段的成本。根据这些字段中最终需要初始化的部分、初始化它们的开销以及初始化后访问每个字段的频率，延迟初始化实际上会损害性能(就像许多“优化”一样)。

  也就是说，延迟初始化有其用途。如果一个字段只在类的一小部分实例上访问，并且初始化该字段的代价很高，那么延迟初始化可能是值得的。唯一确定的方法是使用和不使用延迟初始化来度量类的性能。
  在存在多个线程的情况下，延迟初始化很棘手。如果两个或多个线程共享一个延迟初始化的字段，那么必须使用某种形式的同步，否则会导致严重的错误( item78).本项目中讨论的所有初始化技术都是线程安全的。

  在大多数情况下，常规初始化优于延迟初始化。下面是一个通常初始化的实例字段的典型声明。注意final修饰语的使用(item17):

image.png

  如果使用延迟初始化来破坏初始化循环，请使用同步访问器因为这是最简单明了的选择:、

image.png

  这两种习惯用法(使用同步访问器进行常规初始化和延迟初始化)在应用于静态字段时都没有改变，只是在字段和访问器声明中添加了静态修饰符。
  如果需要在静态字段上使用延迟初始化来提高性能，请使用lazy initialization holder类习惯用法。**这个习惯用法利用了这样一个保证:一个类在使用之前不会被初始化[JLS, 12.4.1]。它是这样的:

image.png

  第一次调用getField时，它读取FieldHolder.field字段，导致初始化FieldHolder类。这个习惯用法的优点是getField方法不是同步的，只执行字段访问，所以延迟初始化实际上不会增加访问成本。一个典型的VM只会同步字段访问来初始化类。一旦类初始化后，VM对代码进行修补，以便后续对字段的访问不涉及任何测试或同步。
  如果需要使用延迟初始化来提高实例字段的性能，请使用双重检查习惯用法。**这个习惯用法避免了初始化后访问字段时的锁定成本( item79 )。这个习语背后的意思是检查字段的值两次(因此得名double check):一次没有锁定，然后，如果字段似乎没有初始化，第二次使用锁定。只有当第二个检查指示字段未初始化时，调用才初始化字段。由于初始化字段后没有锁定，因此将字段声明为volatile非常重要( item78 )。下面是这个习语:

image.png

  这段代码可能看起来有点复杂。特别是，可能不清楚是否需要局部变量(结果)。该变量的作用是确保字段在已经初始化的常见情况下只读取一次。虽然不是严格必需的，但这可能会提高性能，而且与应用于低级并发编程的标准相比，这更优雅。在我的机器上，上述方法的速度大约是没有局部变量的明显版本的1.4倍
  虽然您也可以将双重检查习惯用法应用于静态字段，但是没有理由这样做:延迟初始化holder类习惯用法是更好的选择
  双重检查习语的两个变体值得注意。有时候，您可能需要惰性地初始化一个实例字段，该字段可以容忍重复初始化。如果您发现自己处于这种情况，您可以使用double-check习语的变体来避免第二个检查。毫无疑问，它被称为singlecheck习语.它是这样的。注意，字段仍然声明为volatile:

image.png

  本项目中讨论的所有初始化技术都适用于基本字段和对象引用字段。当将双重检查或单检查习惯用法应用于数值基元字段时，将对该字段的值进行检查
0(数值基本变量的默认值)，而不是null。
  如果您不关心是否每个线程都重新计算字段的值，并且字段的类型是long或double之外的原语，那么您可以选择在单检查习惯用法中从字段声明中删除volatile修饰符。这种变体称为生动的单检查习语。：它加快了某些架构上的字段访问速度，代价是需要额外的初始化(每个访问该字段的线程最多需要一个初始化)。这绝对是一种奇特的技术，不是日常使用的。
  总之，您应该正常初始化大多数字段，而不是延迟初始化。如果必须延迟初始化字段以实现性能目标或打破有害的初始化循环，则使用适当的延迟初始化技术。例如字段，它是双重检查的习惯用法;对于静态字段，延迟初始化holder类习惯用法。对于可以容忍重复初始化的实例字段，您还可以考虑单检查习惯用法。
本文写于2019.7.23，历时1天