Page History

Instead of_Lazy initializinginitialization_ adefers memberthe objectconstruction usingof a constructor,member _lazyobject initialization_until canan beinstance usedis toactually deferrequired, therather constructionthan ofinitializing the member object untilin anthe instance is actually requiredclass's constructor. Lazy initialization also helps into breaking harmful circularities in class and instance initialization and in performing other optimizations \[[Bloch 2005|AA. Bibliography#Bloch 05]\].

A Lazy initialization uses either a class or an instance method is used for lazy initialization, depending on whether the member object is static. The method checks whether the instance has already been created and, if not, creates it. If When the instance already exists, it the method simply returns itthe instance:

// Correct single threaded version using lazy initialization
final class Foo {
  private Helper helper = null;

  public Helper getHelper() {
    if (helper == null) {
      helper = new Helper();
    }
    return helper;
  }
  // ...
}

In a multithreaded application, Lazy initialization must be synchronized so that in multithreaded applications, to prevent multiple threads do not create from creating extraneous instances of the member object:

...

The double-checked locking idiom improves performance by limiting synchronization to the rare case of new instance creation, and by foregoing synchronization during the common case of retrieving an already-created instance.

Incorrect forms of the double-checked idiom include those that allow publication of an uninitialized or partially initialized object to be published. Consequently, use of incorrect forms of the double-checked locking idiom is forbidden.

Noncompliant Code Example

The double-checked locking pattern uses block synchronization instead of rather than method synchronization, and installs an additional null check before attempting synchronization. This noncompliant code example uses the incorrect form of the double-checked locking idiom.

...

// Works with acquire/release semantics for volatile
// Broken under JDK 1.4 and earlier
final class Foo {
  private volatile Helper helper = null;

  public Helper getHelper() {
    if (helper == null) {
      synchronized (this) {
        if (helper == null) {
          helper = new Helper(); // If the helper is null, create a new instance
        }
      }
    }
    return helper; // If helper is non-null, return its instance
  }
}

IfWhen a thread initializes the {{Helper}} object, a [happens-before relationship|BB. Definitions#happens-before order] is established between this thread and any anotherother thread that retrieves and returns the instance \[[Pugh 2004|AA. Bibliography#Pugh 04], [Manson 2004|AA. Bibliography#Manson 04]\].

...

Variables that are declared static and initialized at declaration, or from a static initializer, are guaranteed to be fully constructed before being made visible to other threads. However, this solution forgoes the benefits of lazy initialization.

Compliant Solution (Initialize-on-Demand, Holder Class Idiom)

...

In this compliant solution, the Helper class is immutable and, consequently, is guaranteed to be fully constructed before becoming visible. In this case, there are no lacks any further requirements to ensure that the double-checked locking idiom does not result in avoids the publication of an uninitialized or partially initialized field.

...

*LCK10-EX1:* The noncompliant form of the double-checked locking idiom can be used for 32-bit primitive values (for example, {{int}} or {{float}}) \[[Pugh 2004|AA. Bibliography#Pugh 04]\]. Note that it doesfails not work for {{long}} or {{double}} because unsynchronized reads/writes of 64-bit primitives are notlack guaranteeda toguarantee beof atomicatomicity. (See rule [VNA05-J. Ensure atomicity when reading and writing 64-bit values].)

...

...