« Salut Amigo ! »

« Il y a un énorme sujet, le modèle de mémoire Java. Fondamentalement, vous n'avez pas encore besoin de le savoir, mais il sera utile d'en entendre parler. »

"Pour éliminer tous les problèmes potentiels, Java a changé son mécanisme de gestion de la mémoire. Désormais, la mémoire n'est plus simplement divisée en cache local et mémoire globale d'un thread - le mécanisme est encore meilleur."

« Et plus compliqué !

"Oui, mieux et plus compliqué. C'est comme un avion. Voler en avion c'est mieux que marcher, mais plus compliqué. Je vais essayer d'expliquer la nouvelle situation très simplement."

"Voici ce qu'ils ont trouvé. Un mécanisme de synchronisation de la mémoire de thread locale, appelé 'happens-before', a été ajouté au code. Plusieurs règles/conditions ont été inventées. Lorsque ces conditions sont satisfaites, la mémoire est synchronisée ou mise à jour avec le courant. État.

"Voici un exemple :"

Commande Sujet 1 Fil 2
1
2

101
102
103
104
105

201
202
203
204
205
public int y = 1;
public int x = 1;

x = 2;
synchronized(mutex)
{
 y = 2;
}
Le thread attend que le mutex soit libéré

synchronized(mutex)
{
 if (y == x)
 System.out.println("YES");
}

"L'une de ces conditions est l'acquisition du mutex libéré. ​​Si un mutex est libéré et réacquis, alors la mémoire sera synchronisée avant l'acquisition. Le thread 2 verra les 'dernières' valeurs des variables x et y, même si vous ne les déclarez pas volatils."

« Comme c'est intéressant ! Et y a-t-il beaucoup de ces conditions ?

"Assez, voici quelques conditions pour synchroniser la mémoire :"

  • "Dans un seul thread, toute commande se produit avant toute opération qui la suit dans le code source."
  • "La libération d'un verrou se produit avant que le même verrou ne soit acquis."
  • "Une sortie d'un bloc/méthode  synchronisé se produit avant que le bloc/méthode synchronisé ne soit entré sur le même moniteur."
  • "L'écriture d'un champ volatil dans la mémoire se produit avant que le même champ volatil ne soit lu depuis la mémoire."
  • "La fin de la méthode d'exécution d'un objet Thread se produit avant que la méthode join() ne se termine ou que la méthode isAlive() ne renvoie false sur l'objet dans le même thread."
  • "Un appel à la méthode start() d'un objet Thread se produit avant que la méthode run() ne démarre sur l'objet dans le même thread."
  • "La fin du constructeur se produit avant le début de la méthode finalize() de cette classe."
  • "Un appel à la méthode interrupt() se produit avant que le thread ne détermine que cette méthode a été appelée, soit parce qu'une InterruptedException est levée, soit en utilisant les méthodes isInterrupted() ou interrupted()."

« Alors, tout est un peu plus compliqué que je ne le pensais ?

« Oui, un peu plus compliqué… »

"Merci, Rishi. Je vais y réfléchir."

"Ne vous préoccupez pas trop de ce sujet. Le temps viendra où vous comprendrez tout par vous-même. Pour l'instant, il vaudrait mieux que vous compreniez les bases, plutôt que de vous plonger dans la forêt dense qu'est le fonctionnement interne de la machine Java. Java 9 sortira et ensuite tout changera à nouveau."

"O_o. Ouais... Certaines choses qu'il vaut mieux ne pas savoir."