The synchronization mechanism guarantees atomic operations and memory visibility, but the access performance of the synchronization mechanism to variables is a problem that we have to consider, and the Java language provides a weak synchronization mechanism, volatile variables.
The principle is that when a variable is declared as a volatile type, the compiler and the runtime will notice that the variable is shared, so the action on the variable is not reordered with other memory operations. Volatile variables are not cached in registers or in places that are not visible to other processors, so variables that read volatile types always return the most recent write values. (Refer to "Java Concurrency Programming Practice")
Let's look at an example:
Package com.home.thread;/** * @author Gaoxu * */public class ThreadStart {private static class Readerthread extends T hread{public Void Run () { safethread.setnumber (1)} } private static class ReaderThread1 extends thread{< c4/>public void Run () {Long start = System.currenttimemillis (); System.out.println ("=" +safethread.getnumber ()); Long endTime = System.currenttimemillis ()-start; System.out.println ("Time used:" +endtime); } } public static void main (string[] para) { new Readerthread (). Start (); New ReaderThread1 (). Start (); }}
Package Com.home.thread;import java.util.concurrent.atomic.atomicinteger;/** * @author Gaoxu * */public class safethread {volatile static int number;public static int GetNumber () {return number;} Public static void Setnumber (int number) {safethread.number = number;}}
The result of this code is 1, which means that the getnumber is guaranteed to get the most recent memory value of the number variable, which is the credit for the volatile We can imagine access to volatile variables as synchronized set and get operations (although synchronization is far stronger than volatile memory visibility), volatile usage may seem convenient, but its use is limited.
The use of volatile variables can only guarantee the memory visibility of variables, cannot guarantee the atomicity of variables, so the use of volatile variables have the following conditions:
The write operation on a variable does not depend on the current value of the variable, or you can ensure that only a single thread updates the value of the variable.
The variable is not included in the invariant condition along with other state variables.
There is no need to lock when accessing variables.
We see examples of the above code that perfectly match these conditions, so this example is completely volatile.
In addition, we add the test time code to the code:
Run 10 times each way.
It is concluded that using volatile variables is 1 milliseconds faster than synchronization. (Not high accuracy)
Follow the example to learn Java multi-Threading 5-first knowledge of volatile variables