DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Related

  • Memory Optimization and Utilization in Java 25 LTS: Practical Best Practices
  • Optimizing Java Applications for Arm64 in the Cloud
  • Memory Leak Due To Mutable Keys in Java Collections
  • Advanced Java Garbage Collection Concepts: Weak References, Finalization, and Memory Leaks

Trending

  • LLM-Powered Deep Parsing for Industrial Inventory Search
  • Jakarta EE 12: Entering the Data Age of Enterprise Java
  • Kafka and Spark Structured Streaming in Enterprise: The Patterns That Hold Up Under Pressure
  • Introduction to Retrieval Augmented Generation (RAG)
  1. DZone
  2. Coding
  3. Java
  4. Roach Motel and the Java Memory Model

Roach Motel and the Java Memory Model

This demo of the JMM's roach motel in action explains how it works and why it's worthwhile to know about reordering with synchronized blocks.

By 
Artem Rukavytsia user avatar
Artem Rukavytsia
·
May. 21, 17 · Tutorial
Likes (4)
Comment
Save
Tweet
Share
13.1K Views

Join the DZone community and get the full member experience.

Join For Free

First, let's determine the meaning of roach motel reordering. The roach motel is an approach that lets the compiler move lines of code into synchronized blocks while moving out is disabled. Also, with statements inside a synchronized block, as long as the modification is sequentially consistent, it means that the specific statement is not visible from another place in the code that shares the happens-before relationship with the block.

The roach motel in the Java Memory Model is very similar to a trap for roaches — blocks of code can be moved into synchronized blocks, but they can't be moved out.

Let's consider this code snippet:

a = 1;
synchronized(objMonitor) {
    b = b + someMethod();
}
c = 1;


The compiler can move assigning to the variable a:

synchronized(objMonitor) {
    a = 1;
    b = b + someMethod();
}
c = 1;


It's also a possible version of reordering to the situation above:

synchronized(objMonitor) {
    b = b + someMethod();
    a = 1;
}
c = 1;


The same rule is applicable to variable c:

a = 1;
synchronized(objMonitor) {
    c = 1;
    b = b + someMethod();
}


a = 1;
synchronized(objMonitor) {
    b = b + someMethod();
    c = 1;
}


Access to variables that were moved into the synchronized block can happen in any order, and if the variable was moved into the synchronized block, it can't be moved out.

This leads to a thought: There are two types of programmers — the first naively think that the order of lines of code will be respected in a written order, and the second know what reordering is.

Java memory model Memory model (programming) Java (programming language) Memory (storage engine)

Opinions expressed by DZone contributors are their own.

Related

  • Memory Optimization and Utilization in Java 25 LTS: Practical Best Practices
  • Optimizing Java Applications for Arm64 in the Cloud
  • Memory Leak Due To Mutable Keys in Java Collections
  • Advanced Java Garbage Collection Concepts: Weak References, Finalization, and Memory Leaks

Partner Resources

×

Comments

The likes didn't load as expected. Please refresh the page and try again.

  • RSS
  • X
  • Facebook

ABOUT US

  • About DZone
  • Support and feedback
  • Community research

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 215
  • Nashville, TN 37211
  • [email protected]

Let's be friends:

  • RSS
  • X
  • Facebook