Machine virtuelle Java - Zones de données d'exécution

La spécification JVM définit certaines zones de données d'exécution qui sont nécessaires pendant l'exécution du programme. Certains d'entre eux sont créés lors du démarrage de la JVM. D'autres sont locaux aux threads et ne sont créés que lorsqu'un thread est créé (et détruit lorsque le thread est détruit). Ceux-ci sont énumérés ci-dessous -

Registre PC (compteur de programmes)

Il est local pour chaque thread et contient l'adresse de l'instruction JVM que le thread est en cours d'exécution.

Empiler

Il est local pour chaque thread et stocke les paramètres, les variables locales et les adresses de retour lors des appels de méthode. Une erreur StackOverflow peut se produire si un thread demande plus d'espace de pile que ce qui est autorisé. Si la pile est extensible dynamiquement, elle peut toujours lancer OutOfMemoryError.

Tas

Il est partagé entre tous les threads et contient des objets, des métadonnées de classes, des tableaux, etc., qui sont créés lors de l'exécution. Il est créé au démarrage de la JVM et détruit lors de l'arrêt de la JVM. Vous pouvez contrôler la quantité de tas que votre JVM demande au système d'exploitation à l'aide de certains indicateurs (nous en parlerons plus tard). Il faut veiller à ne pas exiger trop ou trop peu de mémoire, car cela a des implications importantes sur les performances. De plus, le GC gère cet espace et supprime continuellement les objets morts pour libérer l'espace.

Zone de méthode

Cette zone d'exécution est commune à tous les threads et est créée au démarrage de la machine virtuelle Java. Il stocke des structures par classe telles que le pool de constantes (plus à ce sujet plus tard), le code pour les constructeurs et les méthodes, les données de méthode, etc. JVM peut choisir d'ignorer GC. En outre, cela peut ou non augmenter selon les besoins de l'application. Le JLS n'impose rien à ce sujet.

Pool de constantes d'exécution

La JVM gère une structure de données par classe / par type qui agit comme la table de symboles (l'un de ses nombreux rôles) tout en liant les classes chargées.

Piles de méthodes natives

Lorsqu'un thread invoque une méthode native, il entre dans un nouveau monde dans lequel les structures et les restrictions de sécurité de la machine virtuelle Java n'entravent plus sa liberté. Une méthode native peut probablement accéder aux zones de données d'exécution de la machine virtuelle (cela dépend de l'interface de la méthode native), mais peut également faire tout ce qu'elle veut.

Collecte des ordures

La JVM gère l'ensemble du cycle de vie des objets en Java. Une fois qu'un objet est créé, le développeur n'a plus à s'en soucier. Au cas où l'objet deviendrait mort (c'est-à-dire qu'il n'y a plus de référence), il est éjecté du tas par le GC en utilisant l'un des nombreux algorithmes - GC série, CMS, G1, etc.

Pendant le processus GC, les objets sont déplacés en mémoire. Par conséquent, ces objets ne sont pas utilisables pendant le processus. L'application entière doit être arrêtée pendant toute la durée du processus. De telles pauses sont appelées pauses «stop-the-world» et représentent une surcharge énorme. Les algorithmes GC visent principalement à réduire ce temps. Nous en discuterons en détail dans les chapitres suivants.

Grâce au GC, les fuites de mémoire sont très rares en Java, mais elles peuvent arriver. Nous verrons dans les chapitres suivants comment créer une fuite mémoire en Java.