Page History

Starting and using background threads during class initialization can result in class initialization cycles and deadlock. For example, the main thread responsible for performing class initialization can 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 during class initialization \[[Bloch 05b|AA. Java References#Bloch 05b]\]. 

Noncompliant Code Example (Background Thread)

In this noncompliant code example, the static initializer starts a background thread as part of class initialization. The background thread attempts to initialize a database connection but needs to wait until all members of the ConnectionFactory class, including dbConnection, have been initialized.

...

Similarly, it is inappropriate to start threads from constructors (see CON16-J. Do not let the (this) reference escape during object construction for more information). Creating timers that perform recurring tasks and starting those timers from within code responsible for initialization also creates liveness issues.

Compliant Solution (static Initializer, No Background Threads)

This compliant solution does not spawn any background threads from the static initializer. Instead, all fields are initialized in the main thread.

public final class ConnectionFactory {
  private static Connection dbConnection;
  // Other fields ...

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

  // ...
}

Compliant Solution (ThreadLocal)

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

...

The static initializer can be used to initialize any other shared, class fields. Alternatively, the fields can be initialized from the initialValue() method.

Exceptions

<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="7d0bd18f87722c83-ac6a23a1-40804d7e-8d468f09-773561a4ccc02921ce453dce"><ac:parameter ac:name="">CON03>CON20-EX1</ac:parameter></ac:structured-macro>
*CON03CON20-EX1:* It is permissible to start a background thread during class initialization provided the thread does not access any fields. For example, the {{ObjectPreserver}} class (based on \[[Patterns 02|AA. Java References#Patterns 02]\]) shown below provides a mechanism for storing object references, which prevents an object from being garbage-collected, even if the object is not dereferenced in the future.

...

While the initialization does involve a background thread, the thread does not access any fields or create any 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.

Related Vulnerabilities

Any vulnerabilities resulting from the violation of this rule are listed on the CERT website.

References

\[[Bloch 05b|AA. Java References#Bloch 05b]\] 8. "Lazy Initialization"
\[[Patterns 02|AA. Java References#Patterns 02]\] Chapter 5, Creational Patterns, Singleton

Issue Tracking

||Completed||Priority||Locked||CreatedDate||CompletedDate||Assignee||Name||
|T|M|F|1269649993019|1269700561582|rcs_mgr|"Starting and using background threads during class initialization can result in class initialization cycles and deadlock. *For instance,* 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." ... see suggested words in bold...I am also generally unsure about the use of "can" vs. "may" because deadlocks are a "possibility" so perhaps "may" should be used?|

...