Quel est l'usage de MetaSpace en Java 8?
je sais qu'ils ont remplacé PermGen par MetaSpace en Java 8. Mais j'ai quelques questions:
- Est MetaSpace par défaut est GC collectées?
- même le PermGen est GC collecté en ajoutant les args comme
-XX:+CMSClassUnloadingEnabled, alors qu'est-ce qui rend MetaSpace mieux que le PermGen? - MetaSpace est basé sur la mémoire native, donc il garde les objets java sur les disques plutôt que sur VM?
- même MetaSpace peut exécuter de mémoire? Si c'est encore le cas, j'obtiendrai
OutOfMemoryException. - par défaut le MetaSpace peut croître sur l'augmentation de la mémoire?
Merci d'avance
3 réponses
Est MetaSpace par défaut est GC collectées?
Oui, GC fonctionnera sur metaspace quand il se remplira, il serait également augmenter dynamiquement (compte tenu de son autorisé à) la mémoire allouée pour métadonnées.
même le PermGen est GC collecté en ajoutant les args comme-XX: + CMSClassUnloadingEnabled, alors qu'est-ce qui rend MetaSpace meilleur que PermGen?
L'amélioration est avec l'expansion dynamique du metaspace qui c'est quelque chose que permgen n'a pas pu faire.
MetaSpace est basé sur la mémoire native, donc il garde les objets java sur les disques plutôt que sur VM?
basé sur la description de metaspace, il utilise seulement la mémoire native (pas de pagination).
basé sur les recherches de Pierre-Hugues Charbonneau ( lien ici ) il est clair que le l'introduction de metaspace ne résout pas nécessairement le problème OOM, son un bandaid au problème au mieux, il tente de redimensionner dynamiquement la mémoire de metaspace pour accommoder le nombre croissant de classes qui se chargent avec un effet secondaire possible de se développer de manière incontrôlable (tant que la mémoire native le permet).
nous pouvons réaliser la fameuse erreur OOM en paramétrant l'argument MaxMetaspaceSize à JVM et en exécutant le programme d'échantillon fourni.
beaucoup de merci à Pierre-Hugues Charbonneau.
en réponse:
-
par défaut, la mémoire de Metaspace est collectée si elle atteint la MaxMetaspaceSize. Ce paramètre est initialement illimité. La limite est la mémoire dans votre machine. Mais la mémoire est automatiquement libérée lorsqu'un chargeur de classe et de classe n'est plus nécessaire. Vous n'avez besoin d'accorder ce paramètre que si vous soupçonnez que le ClassLoader a une fuite de mémoire.
-
La MetaSpece utilisation la mémoire native et l'organisation en mémoire avec des pointeurs fait que le GC sont plus rapides que la mémoire ancienne PermGen.
-
Non, cela signifie que la JVM utilise la mémoire comme le programme C commun et n'utilise pas l'espace mémoire virtuel pour les objets java. Qui semble que la mémoire n'est limitée que par la machine. Veillez à ce que la mémoire de la machine puisse être changée en disque si nécessaire.
-
Si vous définissez le paramètre MaxMetaspaceSize vous pouvez obtenir OutOfMemory et, si vous ne définissez pas ce paramètre, vous pouvez obtenir si le processus affecte toute la mémoire de la machine (y compris l'espace de swap).
-
Est MetaSpace par défaut est GC collectées?
le ramassage des ordures des classes mortes et classloaders est déclenché une fois que l'utilisation des métadonnées de classe atteint le "MaxMetaspaceSize" qui par défaut est
"unlimited"de sorte qu'une surveillance appropriée est nécessaire pour limiter le délai ou la fréquence de ce GC. -
même le PermGen est GC collecté en ajoutant le args comme - XX: + CMSClassUnloadingEnabled, alors qu'est-ce qui rend MetaSpace meilleur que PermGen?
l'objectif principal est de supprimer permgen était de sorte que les utilisateurs ne doivent pas penser à la taille correcte.
-
MetaSpace est basé sur la mémoire native, donc il garde les objets java sur les disques plutôt que sur VM?
disque N'est pas une mémoire native mais un périphérique de stockage. Natif de la mémoire, dans ce contexte est la zone, est la mémoire pour le processus laissé sur le tas de Java
-
même MetaSpace peut manquer de mémoire?
Oui, il est limité par la quantité de mémoire de votre machine.