Reading a shared primitive variable in one thread may not yield the value of the most recent write to the variable from another thread. Consequently, multiple threads the thread may observe a stale values value of the a shared variable and fail to perform the necessary actions on a timely basis. Visibility of the most recent update can be ensured by declaring the variable as volatile or correctly synchronizing the reads and writes to the variable.
Declaring a shared variable as volatile guarantees visibility in a thread-safe accesses manner only when both of the following conditions are met:
...
| Wiki Markup |
|---|
The first condition iscan sometimesbe relaxed when it can be ensured that only one thread ever updates the value of the variable \[[Goetz 06|AA. Java References#Goetz 06]\]. However, itcode isthat stillrelies possibleon foran readerinvariant threadssuch toas seesingle-thread staleconfinement valuesto ofbe thetrue variableat while the writing threadall times is inerror-prone the process of modifying its value, before writing it back. Furthermore, it is hard and difficult to maintain. code thatThis reliesbehavior onis anpermissible invariantunder suchthis asguideline single-threadbut confinement to be true at all timesnot recommended. |
Synchronizing the code makes it easier to reason about its behavior and is frequently , a more secure approach than simply using volatile. However, it is slightly more expensive and can cause synchronization has a somewhat higher performance overhead and can result in contention and deadlocks when used excessively.
...
If one thread invokes the shutdown() method to set the flag, it is possible that another a second thread might not observe this change. Consequently, the second thread may observe that done is still false and incorrectly invoke the sleep() method. In fact, a A compiler is allowed to optimize the code if it determines that the value of done is never modified by the same thread, with the end result being resulting in an infinite loop.
Compliant Solution (volatile)
This In this compliant solution declares , the done flag is declared as volatile to ensure that updates become writes are visible to other threads.
...
Compliant Solution (java.util.concurrent.atomic.AtomicBoolean)
This In this compliant solution uses an AtomicBoolean flag to ensure that updates become , the done flag is declared as AtomicBoolean. Atomic types also guarantee that writes are visible to other threads.
...
While this is an acceptable compliant solution, it has the following shortcomings as compared to the previously suggested ones:
...
intrinsic locks cause threads to block
...
and may introduce
...
contention; volatile
...
, on the other hand, does not block. Excessive synchronization can also make the program prone to deadlock
...
.
However, synchronization Synchronization is a more secure alternative in situations where the volatile keyword or a java.util.concurrent.atomic.Atomic* field is inappropriate, such as if a variable's new value depends on its old value. Refer to CON01-J. Ensure that compound operations on shared variables are atomic for more information on compound operations.
Exceptions
CON00-EX1: Objects of type Class need not be made visible because they are created by the Virtual Machine and their initialization always precedes any subsequent use . JMM Mailing List.
Risk Assessment
Failing to ensure the visibility of a shared primitive variables on accesses can lead to variable may result in a thread seeing observing a stale values value of the variablesvariable.
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
|---|---|---|---|---|---|
CON00- J | medium | probable | medium | P8 | L2 |
...