Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0

Wiki MarkupStarting 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 2005b|AA. References#Bloch 05b]\]. Consequently, programs must ensure that class initialization is complete before starting any threads.

Noncompliant Code Example (Background Thread)

...

Code Block
bgColor#FFcccc
public final class ConnectionFactory {
  private static Connection dbConnection;
  // Other fields ...

  static {
    Thread dbInitializerThread = new Thread(new Runnable() {
        @Override public void run() {
          // Initialize the database connection
          try {
            dbConnection = DriverManager.getConnection("connection string");
          } catch (SQLException e) {
            dbConnection = null;
          }
        }
    });

    // Other initialization, for example, start other threads

    dbInitializerThread.start();
    try {
      dbInitializerThread.join();
    } catch (InterruptedException ie) {
      throw new AssertionError(ie);
    }
  }

  public static Connection getConnection() {
    if (dbConnection == null) {
      throw new IllegalStateException("Error initializing connection");
    }
    return dbConnection;
  }

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

Wiki MarkupStatically initialized fields are guaranteed to be fully constructed before they are made visible to other threads (see rule [TSM03-J. Do not publish partially initialized objects] for more information). Consequently, the background thread must wait for the main (or foreground) thread to finish initialization before it can proceed. However, the {{ConnectionFactory}} 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 2005b|AA. References#Bloch 05b]\].

Similarly, it is inappropriate to start threads from constructors (see rule TSM01-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 introduces liveness issues.

...

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

Exceptions

Anchor
unmigrated
CON20-
wiki
EX1
CON20-
markup
EX1

<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="539a4319-cca0-4f42-a6e1-ec515db54f87"><ac:parameter ac:name="">CON20-EX1</ac:parameter></ac:structured-macro> *TSM02-EX0:* Programs are permitted to start a background thread (or threads) during class initialization, provided the thread cannot access any fields. For example, the following {{ObjectPreserver}} class (based on \ [[Grand 2002|AA. References#Grand 02]\]) provides a mechanism for storing object references, which prevents an object from being garbage-collected even when the object is never again dereferenced.

Code Block
bgColor#ccccff
public final class ObjectPreserver implements Runnable {
  private static final 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);
  }
}

...

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

TSM02-J

low

probable

high

P2

L3

Bibliography

...

[ [Bloch 2005bAA. References#Bloch 05b]]

8, Lazy Initialization

]]></ac:plain-text-body></ac:structured-macro>

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="69f2e8e8-c276-4f5c-96fb-25253726f4ec"><ac:plain-text-body><![CDATA[

[ [Grand 2002AA. References#Grand 02]]

Chapter 5, Creational Patterns, Singleton ]]></ac:plain-text-body></ac:structured-macro>

Issue Tracking

Tasklist
Review List
Review List
||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?|

...