What does volatile guarantee and what does it not?

A volatile write happens-before a later volatile read of the same field. That means the reading thread sees the written value and any writes that happened before it. The compiler and CPU may not reorder around the volatile access in ways that break this guarantee.

public class Publisher {
    private int value;
    private volatile boolean ready;

    public void publish(int next) {
        value = next;
        ready = true;
    }

    public void consume() {
        if (ready) {
            System.out.println(value);
        }
    }
}

Where volatile is the right tool

• A shutdown or cancellation flag read by a worker loop
• Safe publication of an immutable object through a volatile reference
• Double-checked locking for a lazily initialised singleton
• A single writer and multiple readers of one field

volatile does not make count++ atomic. The operation still reads, adds and writes, so two threads can lose updates. Use AtomicInteger, LongAdder or a lock for compound actions. volatile is also not a substitute for protecting a group of related fields unless every read and write follows the same discipline.