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

Statically 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. Bibliography#BlochReferences#Bloch 05b]\].

<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="90ebbdcec36980eb-a2e034f5-4fe04103-89769d33-e1476b8c90123018f58b974d"><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. Bibliography#GrandReferences#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.