TPS04-J
5.5TPS04-J. Ensure ThreadLocal variables are reinitialized when using thread pools
The java.lang.ThreadLocal<T> class provides thread-local variables. According to the Java API [Sun 2009b]
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 when creating an unbounded number of threads can diminish 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 that is subsequently made available for reuse, the reused thread sees the state of the ThreadLocal object as set by the previous thread [Arnold 2006].
5.5.1Noncompliant 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 threadspecific 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 DiaryPool class consists of the doSomething1() and doSomething2()methods that each start a thread. The doSomething1() method changes the initial (default) value of the day to Friday and invokes threadSpecificTask(). On the other hand, doSomething2() relies on the initial value of the day (Monday) 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();
CMU/SEI-2010-TR-015 | 139
TPS04-J
}
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
}
}
CMU/SEI-2010-TR-015 | 140
TPS04-J
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, NoOfThreads threads 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. The thread-local state of the thread persists when a thread is recycled.
The following table shows a possible execution order:
Time |
Task |
Pool Thread |
Submitted By Method |
Day |
1 |
t1 |
1 |
doSomething1() |
Friday |
|
|
|
|
|
2 |
t2 |
2 |
doSomething2() |
Monday |
|
|
|
|
|
3 |
t3 |
1 |
doSomething2() |
Friday |
|
|
|
|
|
In this execution order, the two tasks (t2 and t3) that started using doSomething2() are expected to observe the current day as Monday. However, because pool thread 1 is reused, t3 observes the day to be Friday.
5.5.2Noncompliant Code Example (Increase Thread Pool Size)
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 increasing the size of the thread pool resolves the problem for this example, it is not a scalable solution because changing the thread pool size is insufficient when more tasks can be submitted to the pool.
5.5.3Compliant Solution (try-finally Clause)
This compliant solution adds the removeDay() method to the Diary class and wraps the statements in the doSomething1() method of the DiaryPool class in a try-finally block. The finally block restores the initial state of the thread-local days object 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() {
CMU/SEI-2010-TR-015 | 141
TPS04-J
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 the initialValue() method, unless the thread has already set the variable’s value explicitly [Sun 2009b]. This solution transfers the responsibility for maintenance to the client (DiaryPool) but is a good option when the Diary class cannot be modified.
5.5.4Compliant Solution (beforeExecute())
This compliant solution uses a custom ThreadPoolExecutor that extends ThreadPoolExecutor and overrides the beforeExecute() method. That method is invoked before the Runnable task is executed in the specified thread. The method reinitializes 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);
}
}
CMU/SEI-2010-TR-015 | 142