| |
Java language provides a weaker synchronization mechanism, namely volatile variable used to ensure that the notification of the update operation variables to other threads.
When the variable type is declared as volatile, the compiler and runtime will be noted that this variable is shared, and therefore the action is not on the variable memory operations together with other reordering, volatile variables are not cached in registers or on processor invisible place, so when reading the volatile variable always returns the latest value written. Access volatile variable does not perform locking operation and, therefore, does not make the execution thread is blocked, so volatile variable is a more lightweight synchronization mechanism than sychronized keywords.
One kind of volatile variables typical usage: checking a status flag to determine whether to exit loop
volatile boolean asleep;
while (! asleep)
countSomeSheep ();
volatile variables are usually used with an operation is complete, interrupt, or state identification. Despite the volatile variables it can be used to represent other status information, but should be used with caution. For example, volatile enough to guarantee semantic increment operation (count ++) atomicity, unless you can ensure that only one thread of the variable write operation.
Locking mechanism to ensure both visibility and can guarantee atomicity, while volatile variable visibility only guarantee.
Use volatile should meet a number of conditions
First. Variable write operation does not depend on the current value of the variable, or you can ensure that only a single thread to update the values of variables
The variables are not included in the invariance conditions in conjunction with other state variables
Accessing locked variables are not required
Variable write operation does not depend on the current value of the variable, or you can ensure that only a single thread to update the values of variables
Common operations such as: i ++ operation, i write i need to rely on their own values, when there are multiple execution threads simultaneously i ++, A, B read the value of i, then ++ operator, the value may actually get ++ only once
The following code:
public class Volatiletest extends Thread {
static volatile int a = 0;
public void run ()
{
for (int i = 0; i < 10; i ++)
try
{
a = a + 1;
sleep (300);
}
catch (Exception e)
{
}
}
public static void main (String [] args) throws InterruptedException
{
Thread thread [] = new Thread [100];
for (int i = 0; i < 100; i ++)
thread [i] = new Volatiletest ();
for (int i = 0; i < 100; i ++)
thread [i] .start ();
for (int i = 0; i < 100; i ++)
thread [i] .join ();
. System out.println ( "a:" + a);
}
}
Run, you can learn a result is not necessarily equal to 1000, a lot of time to be less than 1000
Second. This variable is not included in the invariance conditions in conjunction with other state variables
Look at an example: There is a range of values is always less than or equal upper lower This is an invariant
public class NumberRange {
private volatile int lower, upper;
public int getLower () {
return lower;
}
public int getUpper () {
return upper;
}
public void setLower (int value) {
if (value> upper) throw new IllegalArgumentException (...);
lower = value;
}
public void setUpper (int value) {
if (value < lower) throw new IllegalArgumentException (...);
upper = value;
}
}
In this way limit the scope of the state variables, the lower and upper fields are defined as volatile types can not be fully realized thread-safe class; thus still need to use synchronization. Otherwise, if you happen to execute two threads setLower and setUpper inconsistent values at the same time, then the range will be in an inconsistent state. For example, if the initial state is (0,5), the same time, the thread A calls setLower(4) Because using a volatile variable, the upper reading is 5, and the thread B calls setUpper(3) Similarly, since the variable is volatile, lower reading is 0, it is clear that the value of the cross into the two operations are not eligible, then by two threads are used to protect the invariant checks, making the final range value is (4,3) - - an invalid value. As for the other operations on the field, we need to make setLower () and setUpper () atomic operation - and the field is defined as a volatile type is impossible to achieve this purpose.
Third.from the previous know - locking mechanism to ensure both visibility and can guarantee atomicity, while volatile variable visibility only guarantee.
So volatile variable does not guarantee atomic lock operations. |
|
|
|