The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →In Java, volatile gives a field specific visibility and ordering guarantees under the Java Memory Model (JMM). A write to a volatile field happens-before every subsequent read of that same field. This makes it useful for certain signaling and publication protocols, but it does not provide mutual exclusion or make compound operations such as count++ atomic.
What does volatile guarantee?
volatile is a field modifier. The Java Language Specification (JLS) defines its concurrency behavior through happens-before: “A write to a volatile field happens-before every subsequent read of that field.” In this relation, “subsequent” means later in the JMM’s ordering, and the read must be of the same volatile field.
The JLS also states, “If one action happens-before another, then the first is visible to and ordered before the second.” A thread that performs the later volatile read therefore gets the visibility and ordering guarantees attached to that relationship. The specification does not promise that every thread instantly sees every write, nor does the guarantee depend on a literal cache flush to main memory. See Oracle’s Java Language Specification, Java SE 26, Chapter 17.
How can a volatile flag communicate between threads?
A common use is a flag that one thread sets and another checks. If the reader observes the writer’s update by reading the same volatile field, the volatile relationship can communicate the state transition and its ordering guarantees.
Recommended Free Tools
#1 Best Overall
class Worker {
private volatile boolean stopRequested;
void requestStop() {
stopRequested = true;
}
void runTask() {
while (!stopRequested) {
doWork();
}
}
private void doWork() {
// Perform one unit of work.
}
}Here, the flag is suitable as a simple signal: one thread writes it, and another repeatedly reads it. The important guarantee is tied to a read of stopRequested; declaring this one field volatile does not automatically make unrelated shared state safe. If the protocol involves several fields, a multi-step invariant, or concurrent updates, choose a mechanism that protects the entire operation.
Why doesn’t volatile make count++ safe?
A volatile read or write has special memory semantics, but it does not lock out other threads. Incrementing a shared counter is a read-modify-write sequence: a thread reads the current value, calculates a new one, then writes it. Two threads can read the same old value before either writes, so one increment can overwrite the other.
private volatile int count;
void increment() {
count++; // Not an atomic increment
}Declaring count volatile does not turn that sequence into one indivisible operation. Use an atomic utility for a supported single-variable update, or protect the relevant critical section with a common monitor or lock. For an invariant spanning multiple values or steps, ensure the chosen mechanism covers the whole invariant—not just an individual field.
Which concurrency mechanism should you choose?
Choose according to the operation and invariant that must be protected, rather than treating these mechanisms as interchangeable performance levels.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware match| Need | Candidate | What it provides |
|---|---|---|
| Communicate a field’s state under a correctly designed protocol | volatile |
Visibility and ordering through a volatile write and a subsequent read of that same field; no mutual exclusion. |
| Protect a critical section or multi-field invariant | synchronized or a lock |
Mutual exclusion when threads use the same monitor or lock, along with memory-consistency effects. |
| Perform supported atomic updates on one variable | A class from java.util.concurrent.atomic |
Atomic operations for the supported value and update pattern. |
| Coordinate task submission, completion, or shared collections | A suitable higher-level java.util.concurrent utility |
Documented memory-consistency guarantees for the API’s operations. |
Oracle’s Java SE 26 concurrency package documentation explains that volatile accesses have memory-consistency effects similar to entering and exiting monitors, “but do not entail mutual exclusion locking.” It also documents guarantees for higher-level concurrency utilities, including executors, futures, and synchronizers. See java.util.concurrent (Java SE 26 & JDK 26).
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.When should a field be declared volatile?
Use volatile when the program’s protocol needs a field’s writes and subsequent reads to participate in the JMM’s visibility and ordering guarantees, and when mutual exclusion or an atomic compound update is not required. If correctness depends on a group of operations happening together, use a shared monitor, lock, or a suitable higher-level concurrency utility instead. For the language rule governing volatile fields, see the JLS section on volatile fields in Chapter 8, §8.3.1.4.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
