Que garantit réellement volatile, et quand cela ne suffit-il pas ?

volatile garantit la visibilité et l'ordonnancement : une écriture est vue par tout thread qui lit ensuite ce champ, et elle établit une relation happens-before, donc les écritures faites avant sont visibles aussi. Il ne donne pas l'atomicité, donc un incrément de compteur reste une situation de compétition parce que c'est une lecture, une addition et une écriture. Pour des actions composées, utilisez synchronized, un verrou, ou une classe atomique comme AtomicLong.

volatile veut dire qu'une lecture voit toujours l'écriture la plus récente plutôt qu'une valeur en cache dans un registre ou dans le cache d'un cœur, et cela empêche le compilateur et le processeur de réordonner autour. Dans les termes du modèle mémoire, cela crée une relation happens-before, donc tout ce que le thread écrivain a fait avant l'écriture volatile est visible par un thread qui la lit ensuite. Ce que ça ne me donne pas, c'est l'atomicité. Un incrément de compteur, ce sont trois opérations, donc deux threads peuvent lire la même valeur et une mise à jour est perdue, peu importe que le champ soit volatile. Mon usage valable habituel, c'est un booléen qui dit à une boucle de fond de s'arrêter, où une seule écriture et une seule lecture correspondent exactement au motif. Tout ce qui est lecture-modification-écriture passe à un AtomicInteger, à un LongAdder si c'est assez sollicité pour que la contention compte, ou à un verrou si plusieurs champs doivent changer ensemble. L'autre endroit où je m'appuie sur le modèle mémoire, c'est la publication sûre, puisque les champs final sont garantis visibles après construction, ce qui est une bonne raison de rendre les choses immuables.