CON03-J. Do not use background threads during class initialization

Starting and using background threads during class initialization can result in class initialization cycles and eventually, deadlock. This is because the main thread responsible for performing class initialization may block waiting for the background thread, which in turn will wait for the main thread to finish class initialization. This issue can arise, for example, when a database connection is established in a background thread while class initialization is underway. [[Bloch 05b]]

Noncompliant Code Example (background thread)

This noncompliant code example begins initializing the class Lazy. The code in the static block is responsible for initialization, and starts a background thread. The background thread attempts to initialize a database connection but needs to wait until initialization of all members of the Lazy class, including dbConnection, has finished.

public final class Lazy {
  private static Connection dbConnection;
	  
  static {
    Thread dbInitializerThread = new Thread(new Runnable() {
      public void run() {
        // Initialize the database connection
        try {
          dbConnection = DriverManager.getConnection("connection string");	 
        } catch (SQLException e) {
          dbConnection = null;	
	}
      }
    });
	    
    dbInitializerThread.start();
    try {
      dbInitializerThread.join();
    } catch(InterruptedException ie) {
      throw new AssertionError(ie);
    }
    // Other initialization   
  }
	  
  public static Connection getConnection() {
    if(dbConnection == null) {
      throw new IllegalStateException("Error initializing connection");  
    }
    return dbConnection;
  }
	  
  public static void main(String[] args) {
    // ...
    Connection connection = getConnection();
  }
}

Recall that statically-initialized fields are guaranteed to be fully constructed before becoming visible to other threads (see [CON26-J. Do not publish partially initialized objects] for more information). Consequently, the background thread must wait for the foreground thread to finish initialization before it can proceed. However, the Lazy class's main thread invokes the join() method which waits for the background thread to finish. This interdependency causes a class initialization cycle that results in a deadlock situation. [[Bloch 05b]]

Similar to this noncompliant code example, threads should not be started from constructors. See CON14-J. Do not let the "this" reference escape during object construction for more information. Starting timers to perform recurring tasks from within code responsible for initialization also results in liveness issues.

Compliant Solution (static initializer, no background threads)

This compliant solution also uses a static initializer for initialization and does not spawn a background thread from it.

public final class Lazy {
  private static Connection dbConnection;

  static {
    // Initialize a database connection
    try {
      dbConnection = DriverManager.getConnection("connection string");
    } catch (SQLException e) {
      dbConnection = null;	
    }        
    // Other initialization
  }

  // ...
}

Compliant Solution (ThreadLocal)

This compliant solution uses a ThreadLocal object to initialize the database connection so that every thread can obtain its own instance of the connection.

public final class Lazy {
  private static final ThreadLocal<Connection> connectionHolder
    = new ThreadLocal<Connection>() {
      public Connection initialValue() {
        try {
          Connection dbConnection = DriverManager.getConnection("connection string");
          return dbConnection;
        } catch (SQLException e) {
          return null;
        }
      }
    };
    
  public static Connection getConnection() {
    Connection connection = connectionHolder.get();
    if(connection == null) {
      throw new IllegalStateException("Error initializing connection");  
    }
    return connection;
  }

  public static void main(String[] args) {
    // ...
    Connection connection = getConnection();
  }
}

It is also safe to set other shared class variables from the initialValue() method.

Exceptions

CON03:EX1: The ObjectPreserver class (based on [[Patterns 02]]) is shown below: This class provides a mechanism for storing object references, which prevents an object from being garbage-collected, even if the remaining program no longer maintains a reference to the object.

public final class ObjectPreserver implements Runnable {
  private static ObjectPreserver lifeLine = new ObjectPreserver();

  private ObjectPreserver() {
    Thread thread = new Thread(this);
    thread.setDaemon(true);
    thread.start(); // Keep this object alive
  }
 
  // Neither this class, nor HashMap will be garbage collected.
  // References from HashMap to other objects will also exhibit this property
  private static final ConcurrentHashMap<Integer,Object> protectedMap 
    = new ConcurrentHashMap<Integer,Object>();
  
  public synchronized void run() {
    try {
      wait();
    } catch(InterruptedException e) { 
      Thread.currentThread().interrupt(); // Reset interrupted status 
    }
  }

  // Objects passed to this method will be preserved until
  // the unpreserveObject method is called
  public static void preserveObject(Object obj) {    
    protectedMap.put(0, obj);  
  }
  
  // Returns the same instance every time
  public static Object getObject() {
    return protectedMap.get(0);	  
  }
  
  // Unprotect the objects so that they can be garbage collected
  public static void unpreserveObject() {
    protectedMap.remove(0);
  }
}

This is a singleton class (see CON23-J. Address the shortcomings of the Singleton design pattern for more information on how to defensively code singleton classes). The initialization creates a background thread referencing the object, and the thread itself waits indefinitely. Consequently, this object exists for the remainder of the JVM's lifetime; however, as it is managed by a daemon thread, the thread (and object) do not hinder a normal shutdown of the JVM.

While the initialization does involve a background thread, the background thread does not access any fields, and creates no liveness or safety issues. Consequently, this code is a safe and useful exception to this guideline.

Risk Assessment

Starting and using background threads during class initialization can result in deadlock conditions.

Automated Detection

Currently, SureLogic Flashlight does not detect all violations of this guideline. It does not detect:

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

References

[[Bloch 05b]] 8. "Lazy Initialization"
[[Patterns 02]] Chapter 5, Creational Patterns, Singleton

CON02-J. Always synchronize on the appropriate object      11. Concurrency (CON)      CON04-J. Synchronize using an internal private final lock object