The Java memory model
What the Java memory model guarantees when threads share data: why reordering and CPU caches break naive code, the happens-before relationship, volatile, synchronized, final fields and safe publication, atomic classes, the double-checked locking trap, and practical rules for correct concurrent code.
CodexBash, , 6 min read
Most Java developers learn that two threads changing the same variable need a lock to avoid lost updates. Fewer know the second, stranger problem: without the right synchronisation, one thread may never see another thread's write at all, or may see writes in a different order than they were made. The rules that decide what one thread is guaranteed to see of another's actions are the Java memory model (JMM), defined in the Java Language Specification. This article explains why such rules are needed and how volatile, synchronized, final and the concurrency library give you the guarantees you need.
Sign in to read the rest
The whole 6 minute article is free with an account, along with every problem, lesson and tutorial. No card.