1. Java Concurrency and Multithreading Tutorial
2. Multithreading Benefits
3. Multithreading Costs
4. Concurrency Models
5. Same-threading
6. Single-threaded Concurrency
7. Concurrency vs. Parallelism
8. Creating and Starting Java Threads
9. Java Virtual Threads
10. Race Conditions and Critical Sections
11. Thread Safety and Shared Resources
12. Thread Safety and Immutability
13. Java Memory Model
14. Java Happens Before Guarantee
15. Java Synchronized Blocks
16. Java Volatile Keyword
17. CPU Cache Coherence in Java Concurrency
18. False Sharing in Java
19. Java ThreadLocal
20. Thread Signaling in Java
21. Deadlock
22. Deadlock Prevention
23. Starvation and Fairness
24. Nested Monitor Lockout
25. Slipped Conditions
26. Locks in Java
27. Read / Write Locks in Java
28. Reentrance Lockout
29. Semaphores
30. Blocking Queues
31. The Producer Consumer Pattern
32. Thread Pools
33. Thread Congestion in Java
34. Compare and Swap
35. Anatomy of a Synchronizer
36. Non-blocking Algorithms
37. Amdahl's Law
38. Java Concurrency References

In some of the other tutorials in this Java Concurrency tutorial series you might have read, or heard me saying in a video, that when a Java thread writes to a volatile variable, or exits a synchronized block - that this flushes all variables visible to the thread from the CPU cache to main memory.

This is not actually what happens. In this short tutorial I will explain what really happens. I have made a video version of this tutorial too, if you prefer video:
Java Concurrency + CPU Cache Coherence

What actually happens is, that all variables visible to the thread which are stored in CPU registers will be flushed to main RAM (main memory). On the way to main RAM the variables may be stored in the CPU cache. The CPU / motherboard then uses its cache coherence methods to make sure that all other CPUs caches can see the variables in the first CPUs cache.

The hardware may even choose not to flush the variables all the way to main memory but only keep it in the CPU cache - until the CPU cache storing the variables is needed for other data. At that time the CPU cache can then be flushed to main memory. However, for the code running on the CPU this is not visible. As long as it gets the data it requests from any given memory address, it doesn't matter if the returned data only exists in the CPU cache, or whether it is also exists in main RAM.

You don't have to worry about how CPU cache coherence works. There is of course a little performance hit for this CPU cache coherence, but it's better than writing the variables all the way down to main RAM and back up the other CPU caches.

Below is a diagram illustrating what I said above. The red, dashed arrow on the left represents my false statement from other tutorials - that variables were flushed from CPU cache to main RAM. The arrow on the right represents what actually happens - that variables are flushed from CPU registers to the CPU cache.