Récemment, je lisais un livre Java très classique : "Compréhension approfondie de la machine virtuelle Java, deuxième édition". Je l'ai lu il y a quelques années, mais à cette époque, je ne le connaissais pas, alors je l'ai lu. J'étais confus et confus, alors j'ai arrêté de le lire. Avec le recul, je trouve qu'il est effectivement bien écrit, et je peux comprendre de nombreux points de connaissances. Il est également très approfondi et a beaucoup gagné. Plus tard, je prévois d'écrire une série d'articles basés sur le contenu de ce livre pour apprendre et revoir en profondeur les connaissances liées à la machine virtuelle Java.
Après avoir déménagé le week-end dernier, le haut débit à la maison n'a pas été réparé. Je l'ai signalé N fois au service client télécom et j'ai finalement pris rendez-vous avec un technicien pour migrer le haut débit demain matin. Cela peut mettre fin au douloureux. jours sans Internet pendant plus d'une semaine. J'ai été occupé avec diverses choses pendant cette période. Je n'ai pas mis à jour mon blog depuis une semaine. L'état et la passion avant d'arrêter d'écrire vont progressivement disparaître. Je me sens toujours paniqué. ! Profitez du week-end de demain pour enregistrer une partie du contenu d'apprentissage de cette semaine sur l'ordinateur de l'entreprise.
Le modèle de mémoire JVM est en fait assez simple Voici deux points de connaissances :
1. tas Java, pile Java (c'est-à-dire pile de machines virtuelles), pile de méthodes locales, zone de méthodes et compteur de programme.
2. Partager : La zone de méthode et la zone de tas sont partagées par les threads, et la pile de machine virtuelle, la pile de méthodes locale et le compteur de programme sont privés de thread, également appelés thread-. isolé. Chaque zone stocke un contenu différent. Ces deux points de connaissances doivent être gardés à l’esprit car ils constituent la base de la maîtrise du modèle de mémoire JVM.
1. Contenu de stockage : Pour les méthodes Java ordinaires (c'est-à-dire les méthodes non modifiées avec le mot-clé natif), l'adresse de l'instruction en cours lors de l'exécution est stockée. . Pour la méthode native, il est vide (non défini). Pourquoi ? Car lors de l'appel de la méthode locale, l'adresse mémoire de la machine virtuelle JVM peut avoir été dépassée.
2. Discussion privée : Pourquoi le compteur du programme est-il privé pour la discussion ? C'est facile à comprendre en fonction du contenu du stockage. S'il est partagé par les threads, lorsque plusieurs threads sont en cours d'exécution, ils ne sauront pas quelle adresse le thread actuel exécute. Certains threads sont rapides et d'autres sont lents. entrez après l'avoir exécuté. Ensuite, lorsque le thread lent revient de l'exécution et constate que son adresse a changé, ne serait-ce pas compliqué ?
3. C'est la seule zone de la JVM qui ne signale pas de débordement de mémoire (OutOfMemoryError).
3. Pile de machines virtuelles La pile de machines virtuelles stocke principalement les cadres de pile. Chaque cadre de pile stocke les tables de variables locales, les piles d'opérandes et les liens dynamiques et les informations d'exportation de méthodes, etc. . La table des variables locales stocke certaines variables locales définies dans la méthode, les références d'objet, les paramètres et les adresses de retour de méthode, etc. L'espace occupé par la table des variables locales peut être déterminé au moment de la compilation. Lorsque la méthode est en cours d'exécution, la taille de l'espace de la table des variables locales ne sera pas modifiée. Ceci est facile à comprendre lorsqu'il est combiné avec le contenu stocké dans la table des variables locales. . La pile d'opérandes peut être comprise comme le chargement et le déchargement des données de l'opération en cours. Pour les types longs et doubles de 64 bits, chaque opérande occupe 2 mots de large (emplacement), et les autres types d'opérandes occupent un mot de large (emplacement). Un cadre de pile est créé lorsque chaque méthode est appelée, et le processus d'exécution correspond au processus par lequel un cadre de pile est poussé dans la pile de la machine virtuelle et retiré de la pile. Concernant le contenu des stack frames, vous pouvez vous référer à un blog écrit par un internaute : https://blog.csdn.net/xtayfjp..., qui est très bon et détaillé. Voici une photo du cadre de la pile pour que ce soit clair en un coup d'œil.
La zone méthode est une zone relativement importante. La spécification de la machine virtuelle Java décrit la zone méthode comme une partie logique du tas, mais afin de correspondre au Heap (zone du tas). ), on l'appelle également Non-Heap (zone non-heap). Les variables statiques, les constantes (y compris les constantes d'exécution), les informations de chargement de classe et le code compilé Java sont principalement stockés. Cette partie de l'espace n'a pas besoin d'être continue. Vous pouvez choisir une taille fixe ou extensible. Habituellement, il n'y a pas de GC dans cette partie car GC ne recycle que les variables statiques, les constantes et les informations de chargement de classe. L'effet de recyclage de ces objets est généralement insatisfaisant. . Vous pouvez donc choisir de ne pas implémenter le garbage collection. Cette zone est aussi appelée génération persistante. Lorsque cette zone de mémoire est insuffisante, une exception OutOfMemoryError sera également signalée.
La zone de tas Java est la zone la plus volumineuse de la mémoire JVM, car toutes les instances d'objets et les objets de tableau sont stockés ici. Cette zone est partagée par les threads et sera créée au démarrage de la JVM. Pensez-y, si un espace aussi grand est privé aux threads, la mémoire ne devrait-elle pas exploser ? Selon la spécification de la machine virtuelle Java, le contenu de la zone de tas peut être physiquement discontinu, tant qu'il est logiquement continu, une fois implémenté, il peut être de taille fixe ou extensible, et il est généralement extensible. -Xms et -Xmx sont utilisés pour ajuster la taille du tas. La zone du tas Java est divisée en nouvelle génération et ancienne génération selon différents cycles de vie. La nouvelle génération peut être subdivisée en zones Eden et Survivor, et Survivor peut être subdivisé en Survivor1 et Survivor2. Ces deux-là n'utilisent généralement que l'une d'elles, et l'autre est utilisée pour conserver les objets survivants pendant le GC. La plupart des nouveaux objets sont stockés dans la zone Eden. S'il s'agit d'un objet volumineux, tel qu'un grand tableau ou un objet List, vous pouvez utiliser le paramètre JVM -XX:PretenureSizeThreshold pour stocker directement les objets dépassant la taille spécifiée dans l'ancienne génération. Il convient de noter que lors de l'écriture d'un programme, vous devez essayer d'éviter que les gros objets qui vivent et meurent n'entrent dans l'ancienne génération, car le coût du GC dans l'ancienne génération est supérieur à celui de la jeune génération. Le rapport de taille par défaut d'Eden et Survivor est de 8:1:1, et l'algorithme GC par défaut pour la nouvelle génération est l'algorithme de réplication. L'algorithme GC par défaut pour l'ancienne génération est le classement par marquage. Ces deux algorithmes GC seront expliqués dans le prochain blog.
Lorsqu'il n'y a pas assez de mémoire dans le tas, une exception OutOfMemoryError sera levée. Concernant le modèle de mémoire de la zone de tas, vous pouvez vous référer aux images suivantes :
Articles associés :
Présentation détaillée de la machine virtuelle Java
Explication détaillée du principe de fonctionnement de la machine virtuelle Java (images et textes)
Vidéos associées :
Black Horse Tutoriel vidéo de compréhension approfondie de Python de 8 jours dans Cloud Classroom
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!
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
