In Java, the volatile keyword is used to ensure the visibility of variables in a multi-threaded environment. Its core purpose is to ensure that the latest write value can be obtained during reading. When a variable is declared as volatile, the JVM will prohibit the variable from being cached locally in each thread, forcing all read and write operations to occur in the main memory, thereby avoiding inter-thread communication problems caused by cache inconsistency. It is suitable for the following scenarios: 1. Variables are accessed by multiple threads; 2. The update of variables does not depend on the current value (such as no composite operations such as self-increment are involved); 3. Atomic guarantee is not required. Typical use cases include status flags, one-time safe releases, and weak state synchronization. Unlike synchronized, volatile only provides visibility and orderliness guarantees, and does not provide atomicity and mutually exclusive access capabilities. It should be noted that volatile cannot ensure the atomicity of composite operations like count, nor can it replace a comprehensive synchronization mechanism. Therefore, when multiple threads are involved in simultaneously modifying shared variables, more advanced concurrency control methods such as synchronized or AtomicInteger should be considered.

In Java, the volatile keyword is used to indicate that a variable's value may be modified by different threads. When a variable is declared as volatile , it ensures that any read of that variable will see the most recent write to it, even if those reads and writes occur on different threads.

Visibility Across Threads

One of the main reasons to use volatile is to ensure visibility of changes across threads. Without volatile , each thread might keep its own copy of a variable in local memory (like CPU cache), which can lead to stale data being read.

For example, imagine one thread updating a boolean flag while another thread checks it in a loop. If the flag isn't volatile, the second thread might never see the updated value because it keeps reading from its cached version.

Declaring the flag like this:

 private volatile boolean running = true;

tells the JVM not to cache the value locally and always read it from main memory, ensuring up-to-date visibility.

When to Use Volatile

You should consider using volatile when:

• The variable is accessed by multiple threads.
• The variable does not depend on its current value for updates (ie, no compound actions like incrementing).
• You don't need atomicity for operations like i , since volatile doesn't provide that.

Some typical use cases include:

• Status flags (eg, shutdownRequested )
• One-time safe publication (eg, initializing an object reference)
• Weak state synchronization where full locking is unnecessary

If your usage involves more complex operations or dependencies between variables, you're better off using synchronized blocks or classes from java.util.concurrent .

How It Differs From Synchronized

While both synchronized and volatile are used for thread safety, they work differently:

• synchronized provides both mutual exclusion (only one thread can execute a block at a time) and visibility guarantees.
• volatile only provides visibility and ordering guarantees but not atomicity.

So, if you just need to make sure threads see the latest value and there's no critical section or locking needed, volatile can be lighter weight than synchronized .

Also, entering and exiting a synchronized block establishes a happens-before relationship, similar to how a write to a volatile variable happens before a subsequent read.

Limitations to Be Aware Of

It's important to understand what volatile cannot do:

• It won't make compound operations like count atomic — those still require synchronization.
• It doesn't lock the variable; other threads can still modify it concurrently.
• It's not a replacement for proper synchronization in all scenarios.

For instance, if two threads both try to update a volatile int counter , you can still end up with race conditions. In such cases, using AtomicInteger or synchronized methods would be better.

So, think carefully about whether your shared variable truly fits into the simple pattern that volatile supports.

Basically that's it.

The above is the detailed content of What is the `volatile` keyword in Java?. For more information, please follow other related articles on the PHP Chinese website!