Java memory model - can someone explain it?

Question

For years and years, I\'ve tried to understand the part of Java specification that deals with memory model and concurrency. I have to admit that I\'ve failed miserably. Yes\

Answer 1

I wont try to explain these issues here but instead refer you to Brian Goetz excellent book on the subject.

The book is "Java Concurrency in Practice", can be found at Amazon or any other well sorted store for computer literature.

Answer 2

One notion might be helpful: data (datum) and copies.

If you declare a variable, let's say a byte, it resides somewhere in the memory, in a data segment (roughly speaking). There are 8 bits somewhere in the memory devoted to store that piece of information.

However, there can be several copies of that data, moving around in your machine. For various technical reasons, e.g. thread's local storage, compiler optimizations. And if we have several copies, they might be out of sync.

So you should always keep this notion in mind. It's true not only for java class fields, but for cpp variables, database records (the record state data gets copied into several sessions etc.). Variables, their hidden/visible copies and the subtle syncing issues will be around forever.

Answer 3

• non-volatile variables can be cached thread-locally, so different threads may see different values at the same time; volatile prevents this (source)
• writes to variables of 32 bits or smaller are guaranteed to be atomic (implied here); not so for long and double, though 64bit JVMs probably implement them as atomic operations

Answer 4

I recently found an excellent article that explain volatile as:

First, you have to understand a little something about the Java memory model. I've struggled a bit over the years to explain it briefly and well. As of today, the best way I can think of to describe it is if you imagine it this way:

• Each thread in Java takes place in a separate memory space (this is clearly untrue, so bear with me on this one).

• You need to use special mechanisms to guarantee that communication happens between these threads, as you would on a message passing system.

• Memory writes that happen in one thread can "leak through" and be seen by another thread, but this is by no means guaranteed. Without explicit communication, you can't guarantee which writes get seen by other threads, or even the order in which they get seen.

The Java volatile modifier is an example of a special mechanism to guarantee that communication happens between threads. When one thread writes to a volatile variable, and another thread sees that write, the first thread is telling the second about all of the contents of memory up until it performed the write to that volatile variable.

Additional links: http://jeremymanson.blogspot.com/2008/11/what-volatile-means-in-java.html http://www.javaperformancetuning.com/news/qotm030.shtml

Answer 5

Another attempt to provide a summary of things I understood from the answers here and from other sources (the first attempt was pretty far off base. I hope this one is better).

Java memory model is about propagating values written to memory in one thread to other threads so that other threads can see them as they read from memory.

In short, if you obtain a lock on a mutex, anything written by any thread that released that mutex before will be visible to your thread.

If you read a volatile variable, anything written to that volatile variable before you read it is visible to the reading thread. Also, any write to volatile variable done by the thread that write to your variable before the write to your variable is visible. Moreover, in Java 1.5 any write at all, volatile or not, that happened on any thread that wrote to your volatile variable before the write to your volatile variable will be visible to you.

After an object is constructed, you can pass it to another thread, and all final members will be visible and fully constructed in the new thread. There are no similar guarantees about non-final members. That makes me think that assignment to a final member acts as a write to volatile variable (memory fence).

Anything that a thread wrote before its Runnable exited is visible to the thread that executes join(). Anything that a thread wrote before executing start() will be visible to the spawned thread.

Another thing to mention: volatile variables and synchronization have a function that's rarely mentioned: besides flushing the thread cache and providing one-thread-at-a-time access they also prevent compiler and CPU from reordering reads and writes across sync boundary.

None of it is new and the other answers have stated it better. I just wanted to write this up to clear my head.

Answer 6

This explains it using cities (threads) and planets (main memory).

http://mollypages.org/tutorials/javamemorymodel.mp

There are no direct flights from city to city.

You have to first go to another planet (Mars in this case) and then to another city on your home planet. So, from NYC to Tokyo, you have to go:

NYC -> Mars -> Tokyo

Now replace NYC and Tokyo with 2 threads, Mars with Main memory and the flights as acquiring/releasing locks and you have the JMM.