Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Declaring a volatile Java variable means:</p> <ul> <li>The value of this variable will never be cached thread-locally: all reads and writes will go straight to "main memory".</li> <li>Access to the variable acts as though it is enclosed in a synchronized block, synchronized on itself. </li> </ul> <p>Just for your reference, When is volatile needed ? </p> <blockquote> <p>When multiple threads using the same variable, each thread will have its own copy of the local cache for that variable. So, when it's updating the value, it is actually updated in the local cache not in the main variable memory. The other thread which is using the same variable doesn't know anything about the values changed by the another thread. To avoid this problem, if you declare a variable as volatile, then it will not be stored in the local cache. Whenever thread are updating the values, it is updated to the main memory. So, other threads can access the updated value. </p> </blockquote> <p>From <strong><a href="http://docs.oracle.com/javase/specs/jls/se5.0/html/memory.html">JLS §17.4.7</a></strong> <em>Well-Formed Executions</em></p> <blockquote> <p>We only consider well-formed executions. An execution E = &lt; P, A, po, so, W, V, sw, hb > is well formed if the following conditions are true: </p> <ol> <li><p>Each read sees a write to the same variable in the execution. All reads and writes of volatile variables are volatile actions. For all reads r in A, we have W(r) in A and W(r).v = r.v. The variable r.v is volatile if and only if r is a volatile read, and the variable w.v is volatile if and only if w is a volatile write. </p></li> <li><p>Happens-before order is a partial order. Happens-before order is given by the transitive closure of synchronizes-with edges and program order. It must be a valid partial order: reflexive, transitive and antisymmetric. </p></li> <li><p>The execution obeys intra-thread consistency. For each thread t, the actions performed by t in A are the same as would be generated by that thread in program-order in isolation, with each write wwriting the value V(w), given that each read r sees the value V(W(r)). Values seen by each read are determined by the memory model. The program order given must reflect the program order in which the actions would be performed according to the intra-thread semantics of P. </p></li> <li><p>The execution is happens-before consistent (§17.4.6). </p></li> <li><p>The execution obeys synchronization-order consistency. For all volatile reads r in A, it is not the case that either so(r, W(r)) or that there exists a write win A such that w.v = r.v and so(W(r), w) and so(w, r). </p></li> </ol> </blockquote> <p>Useful Link : <a href="http://dow.ngra.de/2008/10/28/what-do-we-really-know-about-non-blocking-concurrency-in-java/">What do we really know about non-blocking concurrency in Java?</a></p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload