Movatterモバイル変換


[0]ホーム

URL:


Tech & Media Labs
Home
RSS
Java Concurrency
  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

CPU Cache Coherence in Java Concurrency

Jakob Jenkov
Last update: 2021-07-15

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

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.

CPU Cache Coherence in Java Concurrency
Next:False Sharing in Java

Jakob Jenkov

Featured Videos

Java ConcurrentMap + ConcurrentHashMap

Java Generics

Java ForkJoinPool

P2P Networks Introduction

















Copyright Jenkov Aps
Close TOC
All Tutorial Trails
All Trails
Table of contents (TOC) for this tutorial trail
Trail TOC
Table of contents (TOC) for this tutorial
Page TOC
Previous tutorial in this tutorial trail
Previous
Next tutorial in this tutorial trail
Next

[8]ページ先頭

©2009-2025 Movatter.jp