En Java, le mot-clé volatil est utilisé pour assurer la visibilité des variables dans un environnement multithread. Son objectif principal est de s'assurer que la dernière valeur d'écriture peut être obtenue pendant la lecture. Lorsqu'une variable est déclarée volatile, le JVM interdit à la variable d'être mise en cache localement dans chaque thread, for?ant toutes les opérations de lecture et d'écriture à se produire dans la mémoire principale, évitant ainsi les problèmes de communication inter-thread provoqués par l'incohérence du cache. Il convient aux scénarios suivants: 1. Les variables sont accessibles par plusieurs threads; 2. La mise à jour des variables ne dépend pas de la valeur actuelle (comme aucune opération composite telle que l'auto-incrément n'est impliquée); 3. La garantie atomique n'est pas requise. Les cas d'utilisation typiques incluent les drapeaux d'état, les versions de sécurité ponctuelles et la faible synchronisation de l'état. Contrairement à Synchronisé, Volatile ne fournit que des garanties de visibilité et d'ordre et ne fournit pas d'atomicité et de capacités d'accès mutuellement exclusives. Il convient de noter que le volatile ne peut pas garantir l'atomicité des opérations composites comme le nombre, et elle ne peut pas remplacer un mécanisme de synchronisation complet. Par conséquent, lorsque plusieurs threads sont impliqués dans la modification simultanée des variables partagées, des méthodes de contr?le de concurrence plus avancées telles que synchronisées ou atomicInteger doivent être prises en compte.

En Java, le mot clé volatile est utilisé pour indiquer que la valeur d'une variable peut être modifiée par différents threads. Lorsqu'une variable est déclarée volatile , elle garantit que toute lecture de cette variable verra l'écriture la plus récente, même si ces lectures et écrit se produisent sur différents fils.

Visibilité entre les fils

L'une des principales raisons d'utiliser volatile est d'assurer la visibilité des changements entre les fils. Sans volatile , chaque thread peut conserver sa propre copie d'une variable dans la mémoire locale (comme le cache CPU), ce qui peut entra?ner la lecture des données périmées.

Par exemple, imaginez un thread mettant à jour un drapeau booléen tandis qu'un autre thread le vérifie dans une boucle. Si le drapeau n'est pas volatil, le deuxième thread peut ne jamais voir la valeur mise à jour car elle continue de lire sa version en cache.

Déclarer le drapeau comme ceci:

 Running booléen volatile privé = true;

dit au JVM de ne pas mettre la valeur localement en cache et de le lire toujours à partir de la mémoire principale, garantissant une visibilité à jour.

Quand utiliser volatile

Vous devriez envisager d'utiliser volatile lorsque:

• La variable est accessible par plusieurs threads.
• La variable ne dépend pas de sa valeur actuelle pour les mises à jour (c'est-à-dire aucune action composée comme l'incrémentation).
• Vous n'avez pas besoin d'atomicité pour des opérations comme i , car volatile ne le fournit pas.

Certains cas d'utilisation typiques comprennent:

• Facteurs de statut (par exemple, shutdownRequested )
• Publication unique (par exemple, initialisation d'une référence d'objet)
• Synchronisation de l'état faible où le verrouillage complet n'est pas nécessaire

Si votre utilisation implique des opérations ou des dépendances plus complexes entre les variables, vous feriez mieux d'utiliser des blocs ou des classes synchronisés de java.util.concurrent .

Comment il diffère de synchronisé

Bien que les deux synchronized et volatile soient utilisés pour la sécurité des fils, ils fonctionnent différemment:

• synchronized fournit à la fois une exclusion mutuelle (un seul thread peut exécuter un bloc à la fois) et des garanties de visibilité.
• volatile ne fournit que la visibilité et les garanties de commande mais pas l'atomicité.

Donc, si vous avez juste besoin de vous assurer que les fils voient la dernière valeur et qu'il n'y a pas de section critique ou de verrouillage nécessaire, volatile peut être un poids plus léger que synchronized .

De plus, la saisie et la sortie d'un bloc synchronisé établit une relation provenant avant, similaire à la fa?on dont une écriture à une variable volatile se produit avant une lecture ultérieure.

Limitations à conscience

Il est important de comprendre ce que volatile ne peut pas faire:

• Il ne fera pas d'opérations composées comme count atomic - celles-ci nécessitent toujours une synchronisation.
• Il ne verrouille pas la variable; D'autres fils peuvent toujours le modifier simultanément.
• Ce n'est pas un remplacement pour une bonne synchronisation dans tous les scénarios.

Par exemple, si deux threads essaient tous deux de mettre à jour un volatile int counter , vous pouvez toujours vous retrouver avec des conditions de course. Dans de tels cas, l'utilisation de méthodes AtomicInteger ou synchronized serait meilleure.

Alors, réfléchissez soigneusement à savoir si votre variable partagée s'intègre vraiment dans le modèle simple que volatile prend en charge.

Fondamentalement, c'est tout.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!