zoukankan      html  css  js  c++  java
  • Effective Java 71 Use lazy initialization judiciously

    Lazy initialization - It decreases the cost of initializing a class or creating an instance, at the expense of increasing the cost of accessing the lazily initialized field. Depending on what fraction of lazily initialized fields eventually require initialization, how expensive it is to initialize them, and how often each field is accessed, lazy initialization can (like many "optimizations") actually harm performance.  

    The only way to know for sure is to measure the performance of the class with and without lazy initialization.  

    Principle

    • Normal initialization of an instance field - Under most circumstances, normal initialization is preferable to lazy initialization.

      // Normal initialization of an instance field

      private final FieldType field = computeFieldValue();  

    • synchronized accessor - If you use lazy initialization to break an initialization circularity, use a synchronized accessor, as it is the simplest, clearest alternative:

      // Lazy initialization of instance field - synchronized accessor

      private FieldType field;

      synchronized FieldType getField() {

      if (field == null)

      field = computeFieldValue();

      return field;

      }

      Both of these idioms (normal initialization and lazy initialization with a synchronized accessor ) are unchanged when applied to static fields, except that you add the static modifier to the field and accessor declarations.  

    • lazy initialization holder class idiom - If you need to use lazy initialization for performance on a static field, use the lazy initialization holder class idiom .

      // Lazy initialization holder class idiom for static fields

      private static class FieldHolder {

      static final FieldType field = computeFieldValue();

      }

      static FieldType getField() { return FieldHolder.field; }  

    • Double-check idiom - If you need to use lazy initialization for performance on an instance field, use the double-check idiom.

      // Double-check idiom for lazy initialization of instance fields

      private volatile FieldType field;

      FieldType getField() {

      FieldType result = field;

      if (result == null) { // First check (no locking)

      synchronized(this) {

      result = field;

      if (result == null) // Second check (with locking)

      field = result = computeFieldValue();

      }

      }

      return result;

      }  

    • Single-check idiom - Occasionally, you may need to lazily initialize an instance field that can tolerate repeated initialization.

      // Single-check idiom - can cause repeated initialization!

      private volatile FieldType field;

      private FieldType getField() {

      FieldType result = field;

      if (result == null)

      field = result = computeFieldValue();

      return result;

      }  

      Note

      When the double- check or single-check idiom is applied to a numerical primitive field, the field's value is checked against 0 (the default value for numerical primitive variables) rather than null.  

    • Racy single-check idiom - If you don't care whether every thread recalculates the value of a field, and the type of the field is a primitive other than long or double , then you may choose to remove the volatile modifier from the field declaration in the single-check idiom(e.g. String instances to cache their hash codes).

      // racy single-check idiom - can cause repeated initialization!

      private FieldType field;

      private FieldType getField() {

      FieldType result = field;

      if (result == null)

      field = result = computeFieldValue();

      return result;

      }  

      Summary

      You should initialize most fields normally, not lazily. If you must initialize a field lazily in order to achieve your performance goals, or to break a harmful initialization circularity, then use the appropriate lazy initialization technique. For instance fields, it is the double-check idiom; for static fields, the lazy initialization holder class idiom. For instance fields that can tolerate repeated initialization, you may also consider the single-check idiom.

  • 相关阅读:
    JavaScript学习总结(八)——JavaScript数组
    oracle数据库优化学习笔记
    把连续日期组织起来的算法
    转:andriod的盈利模式分析
    ASP.NET 页生命周期
    .NET垃圾回收机制[引用]
    IIS 7.0 的 ASP.NET 应用程序生命周期
    table滑动选择行及从表记录对应js代码
    hdu 3594 Cactus
    Java 计算器
  • 原文地址:https://www.cnblogs.com/haokaibo/p/use-lazy-initialization-judiciously.html
Copyright © 2011-2022 走看看