Gestion de la mémoire Java : explication détaillée des stratégies d'allocation et de recyclage

Tableau 3-4 Paramètres communs liés au garbage collection plus -XX : + UseSerialGC

Conceptuellement, l'allocation de mémoire des objets doit être sur le tas alloué sur la pile (en fait, il peut être désassemblé en un type scalaire après compilation juste à temps et alloué indirectement sur la pile[1]). Dans le cadre du modèle de génération classique, les nouveaux objets sont généralement attribués à la jeune génération. Dans de rares cas (par exemple, la taille de l'objet dépasse un certain seuil), ils peuvent également être attribués directement à l'ancienne génération. Les règles d'allocation des objets ne sont pas fixes. La "Spécification de la machine virtuelle Java" ne stipule pas les détails de création et de stockage de nouveaux objets. Cela dépend du garbage collector actuellement utilisé par la machine virtuelle et des fonctions liées à la mémoire dans la machine virtuelle. . Paramètres.

Les objets sont alloués en premier dans Eden

Dans la plupart des cas, les objets sont alloués dans la zone Eden nouvelle génération. Lorsque la zone Eden ne dispose pas de suffisamment d'espace pour l'allocation, la machine virtuelle lancera un GC mineur.

Les gros objets entrent directement dans la vieillesse

Les grands objets font référence aux objets Java qui nécessitent une grande quantité d'espace mémoire continu. Les gros objets les plus typiques sont de longues chaînes ou des tableaux avec un grand nombre d'éléments. Cette section L'octet. Le tableau [] dans l'exemple est un gros objet typique. Les objets volumineux sont une mauvaise nouvelle pour l'allocation de mémoire des machines virtuelles. La pire nouvelle que de rencontrer un objet volumineux est de rencontrer un groupe de « gros objets de courte durée » qui « vivent et meurent ». Nous écrivons des programmes avec précaution. ce.

La raison pour laquelle les objets volumineux doivent être évités dans la machine virtuelle Java est que lors de l'allocation d'espace, cela peut facilement provoquer le déclenchement anticipé du garbage collection lorsqu'il y a encore beaucoup d'espace dans la mémoire, afin d'obtenir suffisamment d'espace continu. espace pour les placer correctement.

Lors de la copie d'objets, les objets volumineux entraînent une surcharge de mémoire élevée. La machine virtuelle HotSpot fournit le paramètre -XX : PretenureSizeThreshold, qui précise que les objets plus grands que la valeur définie sont directement alloués dans l'ancienne génération. Le but de ceci est d'éviter les allers-retours entre la zone Eden et les deux zones Survivor, ce qui entraîne un grand nombre d’opérations de copie de mémoire.

-XX : Le paramètre PretenureSizeThreshold n'est valide que pour les deux collecteurs de nouvelle génération, Serial et ParNew. Les autres collecteurs de nouvelle génération de HotSpot, tels que Parallel Scavenge, ne prennent pas en charge ce paramètre. Si vous devez utiliser ce paramètre pour le réglage, envisagez la combinaison de collecteur de ParNew et CMS.

Les objets qui ont survécu longtemps entreront dans la vieillesse

La machine virtuelle définit un compteur d'âge d'objet (Age) pour chaque objet, qui est stocké dans l'en-tête de l'objet. Chaque fois qu'il survit à un GC mineur, l'âge augmente d'un an. Lorsque son âge augmente dans une certaine mesure (la valeur par défaut est 15), il sera promu à l'ancienne génération. Le seuil d'âge pour qu'un objet soit promu à l'ancienne génération peut être défini via le paramètre -XX : MaxTenuringThreshold.

Détermination dynamique de l'âge de l'objet

Afin de mieux s'adapter aux conditions de mémoire des différents programmes, la machine virtuelle HotSpot n'exige pas toujours que l'âge de l'objet atteigne -XX : MaxTenuringThreshold pour être promu à l'ancienne génération .Si l'âge est le même dans l'espace Survivant La somme des tailles de tous les objets est supérieure à la moitié de l'espace Survivant. Les objets dont l'âge est supérieur ou égal à cet âge peuvent entrer directement dans l'ancienne génération sans attendre l'âge. requis dans -XX : MaxTenuringThreshold.

Garantie d'allocation d'espace

Avant que le GC mineur ne se produise, la machine virtuelle doit d'abord vérifier si l'espace continu maximum disponible dans l'ancienne génération est supérieur à l'espace total de tous les objets de la nouvelle génération. alors cette fois, Minor GC peut assurer la sécurité de. S'il n'est pas établi, la machine virtuelle vérifiera d'abord si la valeur de réglage du paramètre -XX : HandlePromotionFailure autorise l'échec de la garantie (Handle Promotion Failure si elle est autorisée, elle continuera à vérifier si l'espace continu maximum disponible dans le fichier) ; l'ancienne génération est supérieure à la valeur moyenne des objets promus à l'ancienne génération. Si la taille est supérieure à la taille, un GC Mineur sera tenté, bien que ce GC Mineur soit risqué s'il est inférieur à la taille, ou au - ; XX : le paramètre HandlePromotionFailure n'autorise pas de risque, un GC complet sera alors effectué à la place.

Après la mise à jour 24 du JDK 6, les résultats des tests sont différents. Le paramètre -XX : HandlePromotionFailure n'affectera plus la stratégie de garantie d'allocation d'espace de la machine virtuelle. Observez les modifications du code source dans OpenJDK (voir liste de codes 3-12). Bien que le paramètre -XX : HandlePromotionFailure soit également défini dans le code source, il n'est plus utilisé dans la machine virtuelle réelle. Les règles après JDK 6 Update 24 stipulent que tant que l'espace continu de l'ancienne génération est supérieur à la taille totale des objets de la nouvelle génération ou à la taille moyenne des promotions précédentes, un GC mineur sera effectué, sinon un GC complet sera effectué. .

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!