Java Memory Model
What is Memory Model?
First, lets understand the some optimizations done for performance:
1. Code sometimes is not executed in the order it was written. It is reordered by compilers (e.g. JIT for Java), processor systems for better performance.
2. Processors may use their local caches for various operations. So, in between two operations, it may be out of sync with main memory (which is accessible to other threads).
The above reasons will NOT create any issue for a single thread running. But it may happen that other thread read a value from memory which is out of sync from what other processor has already been done.
Memory Model: defines how Threads interact through (main) memory. In other words, it defines the constraints to processors on making the writes visible to other threads.
Memory Barriers: are the special instructions in the code which tells the processor to make the data in sync with memory (either by reading from memory or writing back to memory).
How Reordering improves performance?
<TODO>
How local cache improves performance?
<TODO>
How re-ordering can create problem?
The following code:
final class SetCheck { private int a = 0; private long b = 0; void set() { a = 1; b = -1; } boolean check() { return ((b == 0) || (b == -1 && a == 1)); }}
The check() method above should never return false. But in case statement b = -1 is executed before, it can.
How local caching can creates problem?
Please look at DoubleCheckedLocking
What is JMM and how does it rescue?
JMM describes the Memory Barriers and the behavior to be following in that case. This in the absence of specific instructions (synchronized, volatile, final) the code can be optimized and cached to boost the performance. But in case of these special instructions, how should threads interact with main memory.
Synchronization? But is not it related to atomicity of Code. How does it related to JMM?
Yes, synchronization in primary sense is related to atomicity. But there is more to it which is not discussed often. It ensures that all writes before synchronization are visible before acquiring the lock (there is more to it...)
How does final effect JMM?
The values for an object's final fields are set in its constructor. Assuming the object is constructed "correctly", once an object is constructed, the values assigned to the final fields in the constructor will be visible to all other threads without synchronization. In addition, the visible values for any other object or array referenced by those final fields will be at least as up-to-date as the final fields.
What does it mean for an object to be properly constructed? It simply means that no reference to the object being constructed is allowed to "escape" during construction. (See Safe Construction Techniques for examples.) In other words, do not place a reference to the object being constructed anywhere where another thread might be able to see it; do not assign it to a static field, do not register it as a listener with any other object, and so on. These tasks should be done after the constructor completes, not in the constructor.
class FinalFieldExample { final int x; int y; static FinalFieldExample f; public FinalFieldExample() { x = 3; y = 4; } static void writer() { f = new FinalFieldExample(); } static void reader() { if (f != null) { int i = f.x; int j = f.y; } } }
The class above is an example of how final fields should be used. A thread executing reader is guaranteed to see the value 3 for f.x, because it is final. It is not guaranteed to see the value 4 for y, because it is not final. IfFinalFieldExample's constructor looked like this:
public FinalFieldExample() { // bad! x = 3; y = 4; // bad construction - allowing this to escape global.obj = this; }
then threads that read the reference to this from global.obj are not guaranteed to see 3 for x.
How does volatile help in JMM?
JMM is interesting. But how it worked before Java5?
Java memory model existed before also (before Javs 5) but has many serious problems e.g. it did not allow many reordering.
References:
1. http://java.dzone.com/articles/multithreading-and-java-memory
2. http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html