...
Wiki Markup |
---|
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 couldcan 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 willsees see 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]\]. |
...
Code Block | ||
---|---|---|
| ||
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 ... System.out.println("The current day is: " + currentDay()); } } 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() { public void run() { Diary.setDay(Day.FRIDAY); diary.threadSpecificTask(); } }); } public void doSomething2() { exec.execute(new Runnable() { 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 } } |
This noncompliant code example frequently produces an incorrect output, for example:
Code Block |
---|
The current day is: FRIDAY
The current day is: FRIDAY
The current day is: MONDAY
|
The following table shows a possible execution ordering:
Time | Pool Thread | Submitted By Method | Day |
---|---|---|---|
1 | 1 |
| Friday |
2 | 2 |
| Monday |
3 | 1 or 2 |
| Friday |
The The issue is that the DiaryPool
class uses a thread pool to execute multiple threads. This allows threads to be reused when the pool is 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. In this case, even though the threads that were started using doSomething2()
are expected to see the current day as Monday, one of them inherits the day Friday from the first thread, when that thread is reused. Increasing
Noncompliant Code Example (Increase Thread Pool Size)
This noncompliant code example increases the size of the thread pool size appears to fix the problem because it prints the expected state (Friday occurs only once):
Code Block |
---|
The current day is: FRIDAY
The current day is: MONDAY
The current day is: MONDAY
|
from 2 to 3 to mitigate the issue.
Code Block | ||
---|---|---|
| ||
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 on demand is infeasibleThe execution order may differ depending on thread scheduling, however, Friday occurs just once in this case. Note that increasing the thread pool size from time to time is not a feasible option.
Compliant Solution (try-finally
clause)
...
Code Block | ||
---|---|---|
| ||
public final class Diary {
private static 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 ...
System.out.println("The day is: " + currentDay());
}
}
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() {
public void run() {
diary.setDay(Day.FRIDAY);
diary.threadSpecificTask();
}
});
}
public void doSomething2() {
final Diary diary = new Diary(); // Second instance
exec.execute(new Runnable() {
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
}
}
|
As expected, this code prints an order in which Friday occurrs just once, for example:
...
The following table shows a possible execution ordering that conforms to the requirements:
Time | Pool Thread | Submitted By Method | Day |
---|---|---|---|
1 | 1 |
| Friday |
2 | 2 |
| Monday |
3 | 1 or 2 |
| Monday |
Classes that cannot be refactored and whose design incorporates ThreadLocal
data should not be executed in thread pools.
...