Page History

...

The use of {{ThreadLocal}} objects requires care 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 whento reduce thread creation overhead is too expensive or when creating an unbounded number of threads can diminish the reliability of the system. EveryEach threadtask that enters the pool expects to see an object{{ThreadLocal}} objects in itstheir initial, default state. However, when {{ThreadLocal}} objects arewere modified fromon a thread that is subsequently made available for reuse, the next task executing on the reused thread sees the state of the {{ThreadLocal}} objectobjects as setmodified by the previous task that executed on that thread \[[JPL 2006|AA. Bibliography#JPL 06]\].

Programs must ensure that each task that executes on a thread from a thread pool sees only correctly-initialized instances of ThreadLocal objects.

Noncompliant Code Example

This noncompliant code example consists of an enumeration of days (Day) and two classes (Diary and DiaryPool). The Diary class uses a ThreadLocal variable to store thread-specific information, such as each threadtask'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.

...

Although increasing the size of the thread pool resolves the problem for this example, it is not a scalable solution fails to scale because changing the thread pool size is insufficient when more additional tasks can be submitted to the pool.

...

If the thread-local variable is read by the same thread again, it is reinitialized using the {{initialValue()}} method, unless the threadtask has already set the variable's value explicitly \[[API 2006|AA. Bibliography#API 06]\]. This solution transfers the responsibility for maintenance to the client ({{DiaryPool}}) but is a good option when the {{Diary}} class cannot be modified.

...

class CustomThreadPoolExecutor extends ThreadPoolExecutor {
  public CustomThreadPoolExecutor(int corePoolSize, int maximumPoolSize,
     long keepAliveTime, TimeUnit unit, BlockingQueue<Runnable> workQueue) {
        super(corePoolSize, maximumPoolSize, keepAliveTime, unit, workQueue);
  }

  @Override
  public void beforeExecute(Thread t, Runnable r) {
    if (t == null || r == null) {
      throw new NullPointerException();
    }
    Diary.setDay(Day.MONDAY);
    super.beforeExecute(t, r);
  }
}

public final class DiaryPool {
  // ...
  DiaryPool() {
    exec = new CustomThreadPoolExecutor(NoOfThreads, NoOfThreads,
             10, TimeUnit.SECONDS, new ArrayBlockingQueue<Runnable>(10));
    diary = new Diary();
  }
  // ...
}

Exceptions

TPS04-EX1: There It is no need unnecessary to reinitialize a ThreadLocal object that does not change state after initialization. For example, there may be only one type of database connection represented by the initial value of the ThreadLocal object.

...

Objects using ThreadLocal data and executed by different threads tasks in a thread pool without reinitialization might be in an unexpected state when reused.

Automated Detection

...

Related Vulnerabilities

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

...

...