The {{ Wiki Markup java.lang.ThreadLocal<T>
}} class provides thread-local variables. According to the Java API \[ [API 2006|AA. Bibliography#API 06]\2014]:
These variables differ from their normal counterparts in that each thread that accesses one (via its
get
orset
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 (for examplee.g., a user ID or transaction ID).
The use of {{ Wiki Markup 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 to reduce thread creation overhead or when creating an unbounded number of threads can diminish the reliability of the system. Each task that enters the pool expects to see {{ThreadLocal
}} objects in their initial, default state. However, when {{ThreadLocal
}} objects are modified on a thread that is subsequently made available for reuse, the next task executing on the reused thread sees the state of the {{ThreadLocal
}} objects as modified 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.
...
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 task's current day. The initial value of the current day is Monday; this it 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 handHowever, doSomething2()
relies on the initial value of the day (Monday) and invokes threadSpecificTask()
. The main()
method creates one thread using doSomething1()
and two more using doSomething2()
.
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 ...
}
}
public final class DiaryPool {
final int numOfThreads = 2; // Maximum number of threads allowed in pool
final Executor exec;
final Diary diary;
DiaryPool() {
exec = (Executor) Executors.newFixedThreadPool(numOfThreads);
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
}
}
|
...
Time | Task | Pool Thread | Submitted By by Method | Day |
---|---|---|---|---|
1 | t1 | 1 |
| Friday |
2 | t2 | 2 |
| Monday |
3 | t3 | 1 |
| Friday |
...
This noncompliant code example increases the size of the thread pool from two to three in an attempt to mitigate the issue.:
Code Block | ||
---|---|---|
| ||
public final class DiaryPool {
final int numOfthreads = 3;
// ...
}
|
...
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 days
object by removing the current thread's value from it.
Code Block | ||
---|---|---|
| ||
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 the {{ Wiki Markup initialValue()
}} method unless the task has already set the variable's value explicitly \[ [API 2006|AA. Bibliography#API 06]\2014]. This solution transfers the responsibility for maintenance to the client ({{DiaryPool
}}) but is a good option when the {{Diary
}} class cannot be modified.
Compliant Solution (beforeExecute()
)
This compliant solution uses a custom ThreadPoolExecutor
that extends ThreadPoolExecutor
and overrides the beforeExecute()
method. The beforeExecute()
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
.
Code Block | ||
---|---|---|
| ||
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(NumOfthreads, NumOfthreads,
10, TimeUnit.SECONDS, new ArrayBlockingQueue<Runnable>(10));
diary = new Diary();
}
// ...
}
|
Exceptions
TPS04-J-EX0: It is 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.
...
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
TPS04-J | medium Medium | probable Probable | high High | P4 | L3 |
Bibliography
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="34518462-038e-4692-9fb7-c3968a319a55"><ac:plain-text-body><![CDATA[ | [[API 2006AA. Bibliography#API 06]API 2014] | ]]></ac:plain-text-body></ac:structured-macro> | <ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="c902141c-11cf-4f1e-ad71-cb858fab48ad"><ac:plain-text-body><![CDATA[ | |
[[JPL 2006AA. Bibliography#JPL 06]] | Section 14.13, " | ]]></ac:plain-text-body></ac:structured-macro> | " |
...
10. Thread Pools (TPS) 11. Thread-Safety Miscellaneous (TSM)