rspec/rules/S2168/java/rule.adoc

Double-checked locking is the practice of checking a lazy-initialized object's state both before and after a ``++synchronized++`` block is entered to determine whether or not to initialize the object.


It does not work reliably in a platform-independent manner without additional synchronization for mutable instances of anything other than ``++float++`` or ``++int++``. Using double-checked locking for the lazy initialization of any other type of primitive or mutable object risks a second thread using an uninitialized or partially initialized member while the first thread is still creating it, and crashing the program.


There are multiple ways to fix this. The simplest one is to simply not use double checked locking at all, and synchronize the whole method instead. With early versions of the JVM, synchronizing the whole method was generally advised against for performance reasons. But ``++synchronized++`` performance has improved a lot in newer JVMs, so this is now a preferred solution. If you prefer to avoid using ``++synchronized++`` altogether, you can use an inner ``++static class++`` to hold the reference instead. Inner static classes are guaranteed to load lazily.


== Noncompliant Code Example

----
@NotThreadSafe
public class DoubleCheckedLocking {
    private static Resource resource;

    public static Resource getInstance() {
        if (resource == null) {
            synchronized (DoubleCheckedLocking.class) {
                if (resource == null)
                    resource = new Resource();
            }
        }
        return resource;
    }

    static class Resource {

    }
}
----


== Compliant Solution

----
@ThreadSafe
public class SafeLazyInitialization {
    private static Resource resource;

    public static synchronized Resource getInstance() {
        if (resource == null)
            resource = new Resource();
        return resource;
    }

    static class Resource {
    }
}
----
With inner static holder:

----
@ThreadSafe
public class ResourceFactory {
    private static class ResourceHolder {
        public static Resource resource = new Resource(); // This will be lazily initialised
    }

    public static Resource getResource() {
        return ResourceFactory.ResourceHolder.resource;
    }

    static class Resource {
    }
}
----
Using "volatile":

----
class ResourceFactory {
  private volatile Resource resource;

  public Resource getResource() {
    Resource localResource = resource;
    if (localResource == null) {
      synchronized (this) {
        localResource = resource;
        if (localResource == null) {
          resource = localResource = new Resource();
        }
      }
    }
    return localResource;
  }

  static class Resource {
  }
}
----


== See

* https://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html[The "Double-Checked Locking is Broken" Declaration]
* https://wiki.sei.cmu.edu/confluence/x/6zdGBQ[CERT, LCK10-J.] - Use a correct form of the double-checked locking idiom
* https://cwe.mitre.org/data/definitions/609.html[MITRE, CWE-609] - Double-checked locking
* https://docs.oracle.com/javase/specs/jls/se7/html/jls-12.html#jls-12.4[JLS 12.4] - Initialization of Classes and Interfaces
* Wikipedia: https://en.wikipedia.org/wiki/Double-checked_locking#Usage_in_Java[Double-checked locking]