Java tas/taille du pool

Question

Lorsque je démarre JVM, il réserve au moins {{xms}} mémoire, non? Cela signifie que cette mémoire est privée pour le processus JVM (il est malloced), oui? Lorsque JVM doit augmenter le tas dans les réserves (mallocs) plus de mémoire. Mais combien? Je ne crois pas qu'il se réserve exactement autant qu'il a besoin, il y a probablement une certaine taille de pas (piscine?).

Comment cette "taille de pas" a-t-elle pu être configurée?

Et tout ce qui arrive jusqu'à {{xmx}} est atteint et OOM est lancé, non?

Lorsque JVM démarre le GC? Pas quand il s'agit de xmx, mais quand il s'agit de la taille de tas réservée (haut de ce pool)?

Si tel est le cas, il est préférable de régler xms à proximité de xmx pour éviter de nombreux GC inutiles. Je vais avoir un GC énorme au lieu de nombreux petits, bug chaque GC gèle ma JVM, donc il vaut mieux en avoir un, non?

Answer 1

Vous avez raison concernant la signification des commutateurs.

La façon dont je me souviens des commutateurs est

* s xm * = Se termine par "s" comme "* s * epuis mémoire".

xm * x * = se termine par « x » comme « ma * x * Mémoire mum »

Il est à une machine virtuelle Java donnée pour décider comment passer de la mémoire à partir au maximum Mémoire. En supposant que les deux ne sont pas trivialement proches les uns des autres, l'allocation se fera par étapes sur toutes les JVM dont je suis au courant.

Je ne connais aucune option permettant de contrôler la taille des étapes d'une machine virtuelle Java. Il n'y a certainement pas d'option standard.

Différentes machines virtuelles Java ont des stratégies GC différentes. Certaines machines virtuelles Java vous permettent d'utiliser l'une des stratégies GC multiples, contrôlée par un commutateur de ligne de commande.

Answer 2

Lorsque JVM doit augmenter le tas dans les réserves (mallocs) plus de mémoire. Mais combien?

Vous ne devriez pas vraiment s'en soucier. C'est juste fonctionne. Beaucoup de conseils en utilisant Xmx et Xms de sorte que JVM alloue toute la mémoire au démarrage. C'est raisonnable, lisez plus loin.

Comment cette "taille de pas" a-t-elle pu être configurée?

Il ne peut pas, il est complètement implémentation et probablement OS-dépendante.

Lorsque JVM démarre le GC? Pas quand il s'agit de xmx, mais quand il s'agit de la taille de tas réservée (haut de ce pool)?

GC est un peu plus compliqué que vous ne le pensez. GC mineur est exécuté lorsque jeune génération est rempli.Major GC est appelé il n'y a plus d'espace laissé dans ancienne génération.

Et tout ce qui arrive jusqu'à {{xmx}} est atteint et OOM est lancé, non?

Non, quand Xmx est atteint, JVM se stabilise et rien ne se passe mal. OutOfMemoryError est levée lorsque, immédiatement après GC, JVM est incapable de trouver suffisamment d'espace pour le nouvel objet (il s'agit d'une simplification majeure).

Si tel est le cas, il est préférable de régler xms à proximité de xmx pour éviter de nombreux GC inutiles.

Encore une fois, vous devez apprendre comment GC fonctionne. En utilisant Xmx égale à Xms est un bon choix, car il évite les allocations inutiles lorsque exécute l'application (tout se passe au démarrage, aucun autre frais généraux). GC n'a rien à voir avec ça.

Au lieu de nombreux petits, bug chaque GC gèle ma JVM, donc il vaut mieux en avoir un, non?

Nope. Le GC mineur prend habituellement des dizaines de millisecondes et est presque invisible, sauf si vous travaillez sur un système en temps réel. Le GC principal (stop-the-world) peut prendre quelques secondes et est certainement perceptible pour les utilisateurs finaux. Dans une JVM majeure correctement réglée, la GC devrait se produire très rarement.