What does volatile actually guarantee, and when is it not enough?

volatile guarantees visibility and ordering: a write is seen by any thread that subsequently reads that field, and it establishes a happens before edge so writes made before it are visible too. It does not give atomicity, so count plus plus is still a race because it is a read, an add and a write. For compound actions use synchronized, a lock, or an atomic class such as AtomicLong.

volatile means a read always sees the most recent write rather than a value cached in a register or a core's cache, and it stops the compiler and processor reordering around it. The memory model way to say that is it creates a happens before edge, so everything the writing thread did before the volatile write is visible to a thread that reads it afterwards. What it does not give me is atomicity. A counter increment is three operations, so two threads can both read the same value and one update is lost no matter how volatile the field is. My usual valid use is a boolean flag that tells a background loop to stop, where a single write and a single read is exactly the pattern. Anything read modify write goes to an AtomicInteger, a LongAdder if it is hot enough that contention matters, or a lock if several fields have to change together. The other place I rely on the memory model is safe publication, since final fields are guaranteed visible after construction, which is a good reason to make things immutable.