En Java, les autres variables de base sont atomiques, à l’exception des variables de 8 octets et 64 bits de Long et Double.
Le modèle de stockage Java exige que les opérations get et store soient atomiques, mais pour les variables longues et doubles non volatiles, la JVM permet de diviser une lecture ou une écriture de 64 bits en deux opérations de 32 bits.
Si la lecture et l’écriture se produisent sur des threads différents, lire un long type non volatil peut entraîner un taux élevé de 32 bits pour une valeur et un faible 32 bits pour l’autre.
Donc, même si vous ne vous souciez pas des données expirées, il n’est peut-être pas sûr d’utiliser des variables partagées, mutables longues et doubles dans un programme multithread, sauf si elles sont déclarées volatiles ou protégées par un verrouillage.
En parlant d’opérations atomiques, cela signifie que la lecture et l’écriture sont atomiques, comme i = 5 ; C’est une opération atomique.
Cependant, si le fonctionnement de deux atomes est réalisé ensemble, il n’est pas nécessairement atomique, comme lire d’abord puis écrire, alors il est possible que la variable ait été modifiée après lecture.
i++ est une telle opération, on lit d’abord puis on écrit, donc la variable entière est atomique, et non i++ est une opération atomique.
Lorsque vous utilisez for(int i=0 ; i<10000 ; i++){System.out.print(i)}
Vous verrez que je n’imprimerai pas 10 000 exemplaires au final, et que j’en imprimerai environ 8 à 9 000.
Mais dans le cas du multithreading, même si la variable entière est atomique, il peut y avoir des problèmes de sécurité des threads, ce qui est un problème de visibilité des threads, donc il faut ajouter une instruction volatile.
Ce modificateur est une variable forcée qui est lue de mémoire à chaque fois et qui n’est pas stockée dans les registres. |
Publié sur 05/04/2015 22:17:45
|
|
|
