CON27-J. Do not execute classes that use ThreadLocal objects in a thread pool

According to the Java API class java.lang.ThreadLocal<T> documentation [[API 06]]:

This class provides thread-local variables. These variables differ from their normal counterparts in that each thread that accesses one (via its get or set method) has its own, independently initialized copy of the variable. ThreadLocal instances are typically private static fields in classes that wish to associate state with a thread (e.g., a user ID or Transaction ID).

The use of ThreadLocal objects is insecure in classes whose objects are required to be executed by multiple threads in a thread pool. The technique of thread pooling allows threads to be reused when thread creation overhead is too high or creating an unbounded number of threads can affect the reliability of the system. Every thread that enters the pool expects to see an object in its initial, default state. However, when ThreadLocal objects are modified from a thread which is subsequently made available for reuse, the reused thread sees the state of the ThreadLocal object as set by the previous thread instead of the expected default state [[JPL 06]].

Noncompliant Code Example

This noncompliant code example consists of an enumeration of days (Day) and two classes (Diary and DiaryPool). The class Diary uses a ThreadLocal variable to store thread-specific information, such as each thread's current day. The initial value of the current day is Monday; this can be changed later by invoking the setDay() method. The class also contains a threadSpecificTask() instance method that performs a thread-specific task.

The class DiaryPool consists of two methods doSomething1() and doSomething2() that each start a thread. The doSomething1() method changes the initial (default) value of the day in the diary to Friday and invokes threadSpecificTask(). On the other hand, doSomething2() relies on the initial value of the day (Monday) in the diary and invokes threadSpecificTask(). The main() method creates one thread using doSomething1() and two more using doSomething2().

public enum Day {
  MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY, SATURDAY, SUNDAY;
}

public final class Diary {
  private static final ThreadLocal<Day> days = 
    new ThreadLocal<Day>() {
      // Initialize to Monday 
      protected Day initialValue() {
        return Day.MONDAY;
      }
    };

  private static Day currentDay() {
    return days.get();
  }

  public static void setDay(Day newDay) {
    days.set(newDay);
  }
    
  // Performs some thread-specific task
  public void threadSpecificTask() {
    // Do task ...
  }
}

public final class DiaryPool {
  final int NoOfThreads = 2; // Maximum number of threads allowed in pool
  final Executor exec;
  final Diary diary;

  DiaryPool() {
    exec = (Executor) Executors.newFixedThreadPool(NoOfThreads);
    diary = new Diary();
  }

  public void doSomething1() {
    exec.execute(new Runnable() {
      @Override public void run() {
        Diary.setDay(Day.FRIDAY);
        diary.threadSpecificTask();
      }
    });
  } 

  public void doSomething2() {
    exec.execute(new Runnable() {
      @Override public void run() {
        diary.threadSpecificTask();
      }
    });
  }

  public static void main(String[] args) {
    DiaryPool dp = new DiaryPool();
    dp.doSomething1(); // Thread 1, requires current day as Friday
    dp.doSomething2(); // Thread 2, requires current day as Monday
    dp.doSomething2(); // Thread 3, requires current day as Monday
  } 
}

The DiaryPool class uses a thread pool to execute multiple threads. This allows threads to be reused when the pool becomes full. When this happens, the thread-local state of a previous thread may be inherited by a new thread that has just begun execution.

The following table shows a possible execution order:

In this execution order, the two tasks (t₁ and t₁) started using doSomething2() are expected to see the current day as Monday, however, one of them (t₃) inherits the day Friday from the first thread, when that thread is reused.

Noncompliant Code Example (Increase Thread Pool Size)

This noncompliant code example increases the size of the thread pool from 2 to 3 to mitigate the issue.

public final class DiaryPool {
  final int NoOfThreads = 3;
  // ...
}

Although this produces the required results for this example, it is not a scalable solution because changing the thread pool size is inadequate when more tasks can be submitted to the pool.

Compliant Solution (try-finally clause)

This compliant solution adds the removeDay() method to the Diary class and wraps the statements in the doSomething1() method of class DiaryPool in a try-finally block. The finally block restores the initial state of the thread-local object days by removing the current thread's value from it.

public final class Diary {
  // ...
  public static void removeDay() {
    days.remove();
  }
}

public final class DiaryPool {
  // ...

  public void doSomething1() {
    exec.execute(new Runnable() {
      @Override public void run() {
    	try {  
          Diary.setDay(Day.FRIDAY);
          diary.threadSpecificTask();
    	} finally {
    	  Diary.removeDay(); // Diary.setDay(Day.MONDAY) can also be used	
    	}
      }
    });
  }
 
  // ...
}

If the thread-local variable is read by the same thread again, it is reinitialized using initialValue() unless the thread explicitly sets the value before this happens [[API 06]]. This solution transfers the burden of maintainability to the client (DiaryPool) but is a good option when the Diary class cannot be refactored.

Compliant Solution (instance per call)

In this compliant solution, the class Diary does not use a ThreadLocal object. Also, the class DiaryPool uses local instances of class Diary within the methods doSomething1() and doSomething2(). The Day is uniquely maintained by each instance of the Diary class.

public final class Diary {
  private volatile Day day;

  Diary() {
    day = Day.MONDAY; // Default	
  }

  private Day currentDay() {
    return day;
  }

  public void setDay(Day d) {
    day = d;
  }

  // Performs some thread-specific task
  public void threadSpecificTask() {
    // Do task ...
  }
}

public final class DiaryPool {
  private final int NoOfThreads = 2; // Maximum number of threads allowed in pool
  private final Executor exec;

  DiaryPool() {
    exec = (Executor) Executors.newFixedThreadPool(NoOfThreads);
  }

  public void doSomething1() {
    final Diary diary = new Diary(); // First instance
    exec.execute(new Runnable() {
      @Override public void run() {
        diary.setDay(Day.FRIDAY);
        diary.threadSpecificTask();
      }
    });
  } 

  public void doSomething2() {
    final Diary diary = new Diary(); // Second instance
    exec.execute(new Runnable() {
      @Override public void run() {
        diary.threadSpecificTask();
      }
    });
  }

  public static void main(String[] args) {
    DiaryPool dp = new DiaryPool();
    dp.doSomething1(); // Thread 1, requires current day as Friday
    dp.doSomething2(); // Thread 2, requires current day as Monday 
    dp.doSomething2(); // Thread 2, requires current day as Monday
  } 
}

Creating two Diary instances in class DiaryPool allows the first thread to work with the object instance having the current day as Friday and the other two threads to work with the object instance having the current day as Monday.

The following table shows a possible execution order that conforms to the requirements:

Exceptions

EX1: Sometimes the state of the ThreadLocal object does not change beyond its initial value. For example, there may be only one type of database connection represented by the initial value of the ThreadLocal object. In the absence of mutability, it is safe to use a thread pool.

Risk Assessment

When objects of classes that use ThreadLocal data are executed in a thread pool by different threads, the objects might acquire stale values, resulting in corrupt state.

Automated Detection

TODO

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

References

[[API 06]] class java.lang.ThreadLocal<T>
[[JPL 06]] 14.13. ThreadLocal Variables

CON26-J. Do not publish partially initialized objects      11. Concurrency (CON)      VOID CON28-J. Prevent partially initialized objects from being used