What is the problem with double-checked locking for singletons before Java 5, and how did Java 5 fix it?

Explanation

In double-checked locking before Java 5, without volatile, the JVM or CPU could reorder writes inside the constructor, leading to a partially constructed object being seen by another thread. Java 5's volatile with happens-before semantics prevents this issue.

Key points

Java 5 introduced volatile to prevent reordering of writes in double-checked locking
This ensures that a fully constructed object is visible to all threads
The volatile keyword establishes a happens-before relationship, ensuring correct object initialization

Ready to go further?

Start full exam Practice more questions