Exemple d'analyse du problème de visibilité des variables Java

Question : La synchronisation et la mise en veille peuvent-elles également atteindre l'objectif de visibilité volatile des threads ? La description générale du problème est la suivante :

package com.test;

importer java.util.concurrent.TimeUnit;

test de classe publique1 {

le booléen statique privé est = vrai ;

public static void main (String[] args) {

nouveau fil de discussion (nouveau Runnable() {

@Override

public void run() {

int je = 0;

while(test1.is){

je++;

1 //synchronisé (ceci) { } actualisera de force la valeur variable de la mémoire principale dans la pile de threads ?

2 //System.out.println("1"); println est synchronisé et actualisera de force la valeur variable de la mémoire principale dans la pile de threads ?

3 //le sommeil rechargera la valeur de la mémoire principale ?

// essaye {

// TimeUnit.MICROSECONDS.sleep(1);

// }catch (InterruptedException e) {

// e.printStackTrace();

// }

}

}

}).start();

essayez {

TimeUnit.SECONDS.sleep(1);

} catch (InterruptedException e) {

e.printStackTrace();

}

nouveau fil de discussion (nouveau Runnable() {

@Override

public void run() {

is = false; //Set est sur false pour que le fil ci-dessus termine la boucle while

}

}).start();

}

}

Q : Pourquoi le programme dans son intégralité ne se termine-t-il pas ? Pourquoi le programme se termine-t-il lorsque vous décommentez l'un des blocs de code (1, 2, 3) ? La synchronisation actualisera-t-elle de force les valeurs des variables de mémoire dans la pile de threads ? Que fera sleep ?

Implique une explication des connaissances

volatile : Ce mot-clé garantit la visibilité des variables dans les threads. Tous les threads qui accèdent aux variables modifiées par volatile doivent les lire dans la mémoire principale avant de les utiliser, et les réécrire dans la mémoire principale immédiatement après la modification de la mémoire de travail, garantissant que les autres threads Visibilité, le mot-clé avec le même effet est définitif.

synchronisé : toutes les opérations de synchronisation doivent garantir 1. Atomicité 2. Visibilité, de sorte que les modifications qui se produisent dans le bloc synchronisé seront immédiatement réécrites dans la mémoire principale

sleep : Cette méthode n'abandonnera que le temps d'exécution du processeur et ne libérera pas le verrou.

Analyse du problème

Q1 : Pourquoi le programme ne se termine-t-il pas après avoir commenté le code ?

A1 : étant donné que la valeur variable de boolean is=true est chargée dans sa propre mémoire de travail par le thread précédent (appelé thread A), une fois que le thread suivant (appelé thread B) a modifié boolean is=false, il se peut qu'il ne le soit pas. être écrit immédiatement dans la mémoire principale (mais dans cette question, il doit être écrit immédiatement dans la mémoire principale, car le thread se fermera après l'exécution de is=false). Même s'il est écrit immédiatement dans la mémoire principale, le thread A ne peut pas le faire. sera immédiatement chargé dans la mémoire de travail, afin que le programme continue. Ne se terminera-t-il pas ? C'est ce à quoi la plupart d'entre nous pensent, mais en fait, la JVM a été optimisée dans une large mesure pour le niveau matériel actuel, assurant essentiellement la synchronisation en temps opportun de la mémoire de travail et de la mémoire principale dans une large mesure, ce qui équivaut à l'utilisation de données volatiles. par défaut. Mais seulement au maximum ! Lorsque les ressources CPU sont toujours occupées, la synchronisation entre la mémoire de travail et la mémoire principale, c'est-à-dire la visibilité des variables, ne sera pas aussi ponctuelle ! La conclusion sera vérifiée plus tard.

Q2 : Pourquoi le programme se termine-t-il uniquement lorsqu'un bloc de code (1, 2, 3) dans le commentaire n'est pas commenté ?

A2 : Les codes avec les numéros de ligne 1 et 2 ont une caractéristique commune, c'est-à-dire qu'ils impliquent tous des verrous de synchronisation synchronisés. Ainsi, comme l'auteur de la question l'a deviné, la synchronisation forcera l'actualisation des valeurs des variables dans la mémoire principale. pile de threads ? , et la méthode sleep actualisera également les valeurs des variables dans la mémoire principale dans la pile de threads ? En fait, nous avons dit plus tôt que synchronisé assurera uniquement la visibilité des variables dans le bloc synchronisé, et la variable is n'est pas dans le bloc synchronisé, donc ce n'est évidemment pas dû à cela. Ensuite, nous ajoutons le code suivant après le code i++; :

pour(int k=0;k<100000;k++){

nouvel objet ();

}

Si vous l'exécutez à nouveau, le programme se terminera immédiatement ! Pourquoi? Dans A1 ci-dessus, nous avons dit que même avec l'optimisation JVM, lorsque le CPU est toujours occupé, la visibilité des données ne peut pas être bien garantie, tout comme le programme ci-dessus continue de boucler pour faire des opérations i++ et pourquoi le programme. arrêter après avoir ajouté le code ci-dessus ? Parce que pour un grand nombre de nouvelles opérations Object(), le CPU n'est plus la principale opération chronophage. Le vrai temps devrait résider dans l'allocation de mémoire (car la vitesse de traitement du CPU est évidemment plus rapide que la mémoire). , sinon il n'y aurait pas de registres CPU. ), donc une fois le CPU inactif, il suivra le benchmark d'optimisation JVM pour assurer la visibilité des données le plus rapidement possible, synchronisant ainsi la variable is de la mémoire principale vers la mémoire de travail, conduisant finalement à la fin du programme. C'est pourquoi la méthode sleep() n'implique pas d'opérations de synchronisation, mais le programme peut toujours être terminé, car la méthode sleep() libérera le CPU mais pas le verrou !

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!