Was garantiert volatile tatsächlich, und wann reicht es nicht?

volatile garantiert Sichtbarkeit und Ordnung: ein Write wird von jedem Thread gesehen, der das Feld danach liest, und es etabliert eine Happens-before-Kante, sodass auch die Writes davor sichtbar sind. Atomarität gibt es nicht, count plus plus bleibt also ein Race, weil es ein Read, ein Add und ein Write ist. Für zusammengesetzte Aktionen nimmst du synchronized, ein Lock oder eine Atomic-Klasse wie AtomicLong.

volatile bedeutet, dass ein Read immer den aktuellsten Write sieht statt eines Werts, der in einem Register oder im Cache eines Kerns liegt, und es verhindert, dass Compiler und Prozessor darüber hinweg umordnen. In der Sprache des Memory Models heißt das, es erzeugt eine Happens-before-Kante, alles, was der schreibende Thread davor getan hat, ist also für einen Thread sichtbar, der danach liest. Was es mir nicht gibt, ist Atomarität. Ein Counter-Increment sind drei Operationen, zwei Threads können also denselben Wert lesen und ein Update geht verloren, egal wie volatile das Feld ist. Mein üblicher valider Einsatz ist ein Boolean-Flag, das einer Hintergrundschleife sagt, dass sie stoppen soll, genau ein Write und ein Read, genau das Muster. Alles, was read-modify-write ist, geht an ein AtomicInteger, an einen LongAdder, wenn es heiß genug ist, dass Contention zählt, oder an ein Lock, wenn sich mehrere Felder zusammen ändern müssen. Die andere Stelle, an der ich mich auf das Memory Model verlasse, ist Safe Publication, denn finale Felder sind nach der Konstruktion garantiert sichtbar, was ein guter Grund ist, Dinge immutable zu machen.