¿Qué garantiza realmente volatile, y cuándo no basta?

volatile garantiza visibilidad y ordenación: cualquier hilo que lea ese campo después ve la escritura, y establece una relación happens before, así que también son visibles las escrituras hechas antes. No da atomicidad, así que un incremento de contador sigue siendo una condición de carrera porque son una lectura, una suma y una escritura. Para acciones compuestas usa synchronized, un lock, o una clase atómica como AtomicLong.

volatile significa que una lectura siempre ve la escritura más reciente y no un valor cacheado en un registro o en la caché de un núcleo, y evita que el compilador y el procesador reordenen alrededor. La forma de decirlo en el modelo de memoria es que crea una relación happens before, así que todo lo que hizo el hilo escritor antes de la escritura volatile es visible para el hilo que la lee después. Lo que no me da es atomicidad. Incrementar un contador son tres operaciones, así que dos hilos pueden leer el mismo valor y perderse una actualización por muy volatile que sea el campo. Mi uso válido habitual es un booleano que le dice a un bucle en segundo plano que pare, donde una sola escritura y una sola lectura es exactamente el patrón. Cualquier lectura, modificación y escritura se va a un AtomicInteger, a un LongAdder si está tan caliente que la contención importa, o a un lock si hay que cambiar varios campos a la vez. El otro sitio donde me apoyo en el modelo de memoria es la publicación segura, ya que los campos final están garantizados como visibles tras la construcción, que es una buena razón para hacer las cosas inmutables.