The Java Memory Model

What's the worst thing that can happen when you fail to synchronize in a concurrent Java program? Its probably worse than you think – modern shared-memory processors can do some pretty weird things when left to their own devices.

Java was the first mainstream programming language to incorporate a formal, cross-platform memory model, which is what enabled the development of write-once, run-anywhere concurrent classes. It is the Java Memory model that defines the semantics of synchronized, volatile, and final.

However, because the most commonly used processors (Intel and Sparc) offer stronger memory models than is required by the JMM, many developers frequently use synchronization and volatile incorrectly, but have been insulated from failure by the stronger memory guarantees offered by the processor architecture they happen to be deploying on. (The infamous “double checked locking” idiom is an example of this sort of error.)

Understanding the Java Memory model is key to using the core concurrency primitives (synchronized and volatile) to develop thread-safe, efficient concurrent classes. We?ll cover what a memory model is (and why we should care), what synchronization really means, and what can really go wrong when we fail to synchronized correctly.

About Brian Goetz

Brian Goetz has been a professional software developer for 20 years. He is the author of over 75 articles on software development, and his book, Java Concurrency In Practice, was published in May 2006 by Addison-Wesley. He serves on the JCP Expert Groups for JSRs 166 (concurrency utilities), 107 (caching), and 305 (annotations for safety analysis). He is a frequent presenter at JavaOne, OOPSLA, JavaPolis, SDWest, and the No Fluff Just Stuff Software Symposium Tour. Brian is a Sr. Staff Engineer at Sun Microsystems.

More About Brian »