0% found this document useful (0 votes)
0 views

Java_Memory_Model_Interview_Problems

The Java Memory Model (JMM) outlines how threads interact with memory, ensuring visibility and ordering of shared variables in multithreaded programming. It distinguishes between visibility, which ensures changes are seen by other threads, and atomicity, which guarantees operations are indivisible. Key concepts include the 'happens-before' relationship, the importance of volatile for visibility, and the treatment of final fields for safe publication in the JMM.

Uploaded by

pbecic
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
0 views

Java_Memory_Model_Interview_Problems

The Java Memory Model (JMM) outlines how threads interact with memory, ensuring visibility and ordering of shared variables in multithreaded programming. It distinguishes between visibility, which ensures changes are seen by other threads, and atomicity, which guarantees operations are indivisible. Key concepts include the 'happens-before' relationship, the importance of volatile for visibility, and the treatment of final fields for safe publication in the JMM.

Uploaded by

pbecic
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 2

Java Memory Model (JMM) for Strong Senior Developers

What is the Java Memory Model (JMM) and why is it important in


multithreaded programming?
 The JMM defines how threads interact through memory and what behaviors are allowed
in concurrent execution.
 It specifies visibility and ordering guarantees for shared variables.
 Importance:
 Without JMM rules, threads might see stale or inconsistent data.
 Enables safe reasoning about synchronization, volatile, and atomic operations.
 JMM allows compilers and CPUs to reorder instructions unless explicitly prevented by
synchronization constructs.

What is the difference between visibility and atomicity in the JMM?


 Visibility:
 Ensures that changes made by one thread to a shared variable are seen by other
threads.
 Guaranteed by volatile, synchronized, or final (for constructors).
 Atomicity:
 Guarantees that an operation is executed as a single, indivisible step.
 Examples: reads/writes to 32-bit or 64-bit primitives may not be atomic without
volatile (e.g., long, double).
 volatile ensures visibility, not atomicity.
 Use synchronized or atomic classes for compound atomic operations.

How does 'happens-before' work in the JMM and what does it guarantee?
 The 'happens-before' relationship defines when one action's effects are visible to
another.
 If A happens-before B, then:
 All memory writes in A are guaranteed visible to B.
 B cannot be reordered before A.
 Examples of happens-before relationships:
 Thread.start() happens-before any actions in the started thread.
 Thread.join() happens-after the thread has terminated.
 Locking via synchronized ensures happens-before between unlock and subsequent lock.
 Writing to a volatile variable happens-before reading the same variable.

Why is double-checked locking without volatile broken in Java before Java 5?


 Double-checked locking (DCL) is used to lazily initialize singletons in a thread-safe
manner.
 In Java versions before 1.5, without volatile:
 The JVM might reorder instructions — reference to a partially constructed object may
be visible to other threads.
 This breaks the singleton guarantee.
 Proper implementation:
 Declare the singleton instance as volatile to prevent reordering and ensure visibility.
 Java 5+ fixed these issues by enhancing the JMM to support safe DCL with volatile.

What are the semantics of final fields in the Java Memory Model?
 Final fields get special treatment in the JMM for immutability and safe publication.
 Once a final field is set in the constructor and the constructor completes normally:
 Other threads will see the correctly constructed object, even without synchronization.
 Conditions:
 The object must not be published (escaped) during construction.
 All final fields must be initialized in the constructor.
 This guarantees safe publication without explicit synchronization.

You might also like