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 2005b]. Consequently, programs must ensure that class initialization is complete before starting any threads.
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 should wait until all members of the
ConnectionFactory class, including
dbConnection, are initialized.
Statically initialized fields are guaranteed to be fully constructed before they are made visible to other threads (see 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].
Similarly, it is inappropriate to start threads from constructors (see 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.
Compliant Solution (Static Initializer, No Background Threads)
This compliant solution initializes all fields on the main thread rather than spawning background threads from the static initializer.
Compliant Solution (
This compliant solution initializes the database connection from a
ThreadLocal object so that each thread can obtain its own unique instance of the connection.
The static initializer can be used to initialize any shared class field. Alternatively, the fields can be initialized from the
TSM02-J-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]) provides a mechanism for storing object references, which prevents an object from being garbage-collected even when the object is never again dereferenced.
This is a singleton class (see MSC07-J. Prevent multiple instantiations of singleton objects for more information on how to defensively code singleton classes). The initialization involves creating a background thread using the current instance of the class. The thread waits indefinitely by invoking
Object.wait(). Consequently, this object persists for the remainder of the Java Virtual Machine's (JVM) lifetime. Because the object is managed by a daemon thread, the thread cannot interfere with normal shutdown of the JVM.
Although the initialization involves a background thread, that thread neither accesses fields nor creates any liveness or safety issues. Consequently, this code is a safe and useful exception to this rule.
Starting and using background threads during class initialization can result in deadlock.
|CERT.TSM02.CSTART||Do not call the "start" method of threads from inside a constructor|
|S2693||Threads should not be started in constructors|
Chapter 8, "Lazy Initialization"
Chapter 5, "Creational Patterns, Singleton"