Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Wiki Markup
Starting and using background threads during class initialization can result in class initialization cycles and deadlock. This is true because 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.

Code Block
bgColor#FFcccc
 

{code:bgColor=#FFcccc}
public final class ConnectionFactory {
  private static Connection dbConnection;
  // Other fields ...
	  
  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;	
        }
      }
    });

    // 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();
  }
}
{code}

Wiki Markup
Statically initialized fields are guaranteed to be fully constructed before they are made visible to other threads (see [CON26-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 05b|AA. Java References#Bloch 05b]\]. 

...

Similarly,

...

it

...

is

...

inappropriate

...

to

...

start

...

threads

...

from

...

constructors

...

(see

...

CON14-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.

Code Block
bgColor#ccccff



h2. 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.

{code:bgColor=#ccccff}
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.

Code Block
bgColor#ccccff
{code}


h2. 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.

{code:bgColor=#ccccff}
public final class ConnectionFactory {
  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;
        }
      }
    };

  // Other fields ...

  static {
    // Other initialization (do not start any threads)
  }
    
  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();
  }
}
{code}

The

...

static

...

initializer

...

can

...

be

...

used

...

to

...

initialize

...

any

...

other

...

shared,

...

class

...

fields.

...

Alternatively,

...

the

...

fields

...

can

...

be

...

initialized

...

from

...

the

...

initialValue()

...

method.

...

Exceptions

Wiki Markup
*CON03: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.

{:=
Code Block
bgColor
#ccccff
}
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);
  }
}
{code} 

This is a singleton class. (See [

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

...

involves

...

creating

...

a

...

background

...

thread

...

using

...

the

...

current

...

instance

...

of

...

the

...

class.

...

The

...

thread

...

waits

...

indefinitely

...

by

...

invoking

...

Object.wait()

...

.

...

Consequently,

...

this

...

object

...

exists

...

for

...

the

...

remainder

...

of

...

the

...

Java

...

Virtual

...

Machine's

...

(JVM's)

...

lifetime.

...

Because

...

the

...

object

...

is

...

managed

...

by

...

a

...

daemon

...

thread,

...

the

...

thread

...

does

...

not

...

hinder

...

a

...

normal

...

shutdown

...

of

...

the

...

JVM.

...

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.

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

CON03- J

low

likely

high

P3

L3

Related Vulnerabilities

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

References

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

...

...

CON02-J.

...

Do

...

not

...

synchronize

...

on

...

objects

...

that

...

may

...

be

...

reused      11. Concurrency (CON)      CON04-J.

...

Synchronize

...

using

...

an

...

internal

...

private

...

final

...

lock

...

object

...