Page History

According to the Java API class The {{java.lang.ThreadLocal<T>}} documentationclass provides thread-local variables. According to the Java API \[[API 06|AA. Java References#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 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 when thread creation overhead is too expensive or creating an unbounded number of threads can affectdiminish 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|AA. Java References#JPL 06]\].

...

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().

...

The DiaryPool class creates a thread pool that reuses a fixed number of threads operating off a shared unbounded queue. At any point, at most NoOfThreadsthreads will be active are actively processing tasks. If additional tasks are submitted when all threads are active, they will wait in the queue until a thread is available. When a thread is recycled in this manner, the The thread-local state of the thread persists when a thread is recycled.

The following table shows a possible execution order:

...

This noncompliant code example increases the size of the thread pool from two to three in an attempt 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 insufficient when more tasks can be submitted to the pool.

...

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|AA. Java References#API 06]\]. This solution transfers the burdenresponsibility offor maintainabilitymaintenance to the client ({{DiaryPool}}) but is a good option when the {{Diary}} class cannot be modified.

...

This compliant solution uses a custom ThreadPoolExecutor that extends ThreadPoolExecutor and overrides the beforeExecute() method. This method is invoked before the Runnable is executed in the specified thread . It is used to reinitialize the thread local variable before task r is executed by thread t.

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

CON33-EX1: If the state of the There is no need to reinintialize a ThreadLocal object that does not change state after initialization, it is safe to use a thread pool. For example, there may be only one type of database connection represented by the initial value of the ThreadLocal object.

Risk Assessment

When objects of classes that use Objects using ThreadLocal data are and executed by different threads in a thread pool by different threads without reinitialization , the objects might acquire stale values, resulting in corrupt statemight be in an unexpected state when reused.

...