Ce qui se passe lorsque la JVM est à court de mémoire à allouer au cours de l'exécution?

Après avoir réfléchi pendant un long moment, d'une façon générique pour poser cette question (et à défaut de trouver un), je vais juste à la poser comme un exemple concret:

Supposons que j'ai une machine Linux qui dispose de 1 Go de mémoire que l'on peut attribuer à des processus (physiques et swap totaux 1 Go).

J'ai un Oracle standard de la JVM Hotspot version 7 est installé sur la machine. Si à un moment donné, il y a suffisamment de programmes en cours d'exécution tels que seulement 400 Mo de 1 Go sont libres, et je commence un programme Java en ce moment avec la JVM ci indicateurs:

java -Xms256m -Xmx512m -jar myJar.jar

ce qui se fait? :

A. est-ce que la JVM ne pas démarrer tout de suite, car il va essayer d'attribuer toutes les 512 Mo de mémoire et un échec (en raison du fait qu'il n'y a pas assez de mémoire disponible pour le moment)?

si la JVM commence:

si à un certain moment de l'exécution de Java processus aura besoin de plus de 400 Mo de mémoire (et il y a encore seulement 400 Mo de mémoire libre, autre que ce que l'actuel processus Java, a déjà utilisé), ce qui va arriver:

B. est le processus Java échouer avec un OutOfMemroyError?

C. il va échouer avec quelques autres (standard) erreur?

D. est-il un comportement indéfini?

Je crois que l'option (B), mais si seulement 200 Mo (moins de Xms) était disponible, alors l'option A.

OriginalL'auteur Shivan Dragon | 2012-11-07

9

-Xmx juste définit la taille maximale du tas. Il ne fait aucune garantie sur qu'il y a autant de mémoire ou pas. Il garantit que le tas ne sera jamais supérieure à la valeur donnée. Cela dit, l'Option B.) qui va se passer, une outOfMemoryError sera levée.

Merci. Mais alors, puis-je suppose que si je passe d'une valeur pour la Xms qui est plus grande que la taille mémoire libre (c'est à dire dans mon exampple, que si j'ai changé le Xms à 500m) puis la JVM ne pourront pas démarrer?
Jetez un oeil ici: stackoverflow.com/questions/3648454/...
merci pour le lien, cette question s'éclaircit certaines de mes questions, mais il se réfère uniquement à la Xmx depassing réel total de la mémoire sur le système. Je me demandais ce qui se fait lors de la Xmx valeur depasses les currentlly disponibles (gratuits) de la mémoire (physique et swap) disponible (mais ne depass le total des personnes à mobilité installé de la mémoire du système, ni ne violent-elles le 32 bits limite de mémoire )

OriginalL'auteur Polygnome
6

Supposons que j'ai une machine Linux qui dispose de 1 Go de mémoire que l'on peut attribuer à des processus (physiques et swap totaux 1 Go).

Ma première réponse serait, à moins que vous parlez d'un téléphone, je voudrais obtenir plus de mémoire. Vous pouvez acheter de 16 GO (b = bit, B = byte) pour moins de 100$.

la JVM ne pas démarrer tout de suite, car il va essayer d'attribuer toutes les 512 Mo de mémoire et un échec (en raison du fait qu'il n'y a pas assez de mémoire disponible pour le moment)?

Cela peut se produire si votre système ne dispose pas de 512 MO (ainsi que certains frais généraux) comme elle alloue le continu de la mémoire virtuelle utilisée pour le segment de mémoire au démarrage.

Même si vous avez 550 MO d'espace libre, le programme pourrait ne pas démarrer car il faut le charger plus que juste le tas.

sera le processus Java échouer avec un OutOfMemoryError?

Cela peut se produire si votre programme utilise 512 MO lors de l'exécution, quelle que soit la quantité de mémoire de votre machine. Cette erreur se produit uniquement après votre JVM a commencé. Vous n'obtiendrez pas cette erreur si il ne peut pas démarrer.

il va échouer avec quelques autres (standard) erreur?

C'est possible si vous manquez d'espace de swap après que le programme a commencé. Il est rare et ne se produit que sur une forte surcharge de la machine. Ce que j'ai vu, c'est la JVM se bloque à cause d'un faible niveau de l'OS de l'échec d'allocation de mémoire.

Java 6 Update 25 VM crash: mémoire insuffisante

+1 surtout pour la dernière remarque sur le comportement indéfini.
Je ne suis pas entièrement sûr, mais je crois que dans le cas où le système a moins de mémoire que spécifié avec -xmx, la JVM va simplement être réglé au maximum disponible, et ne va pas planter immédiatement. --- Je ne sais pas si la même chose s'applique à -xms. Probablement pas. --- Je pense aussi que la réponse devrait être plus généralisée, et moins axée autour de la 512 MB exemple, pour être plus clair pour les autres membres de la communauté qui pourraient trouver cette question dans l'avenir. --- +1 pour l'excellente réponse. Spécialement la dernière section.
L'-xms paramètre ne fait aucune différence à savoir si il va commencer. Il raconte la GC à votre croissance de cette taille. Remarque: un programme "Hello World" de ne pas utiliser la taille minimale juste parce que vous le définissez comme un minimum.
J'ai voulu ajouter l'exacte commentaire que vous venez d'ajouter. Mon problème ici est: comment puis-je savoir au début de JVM si une certaine quantité de mémoire sera disponible en cas de besoin plus tard? Aussi, je ne pense pas que le Xmx valeur peut être digne de confiance, comme si il n'y a pas assez de mémoire, il sera mis à l'échelle vers le bas et d'allouer ce que c'est gratuit. Mais qui est le vrai même pour les Xms valeur? Ou la JVM échouer immédiatement si le Xms valeur spécifiée n'est pas disponible quand il commence?
Le Xmx doit être supérieure ou égale à la Xms réglage et la JVM sera un échec si elle ne peut pas allouer la plus grande Xmx, de sorte que vous définissez la Xms ne fait aucune différence, car il sera toujours plus petit (ou le même)

OriginalL'auteur Peter Lawrey
2

OutOfMemroyError sera "Levée lorsque la Machine Virtuelle Java ne peut pas allouer un objet, car c'est de mémoire, et pas plus de mémoire pourrait être mis à disposition par le garbage collector."

Donc, en substance, "B. Le processus Java échouer avec un OutOfMemroyError".

Merci pour la réponse. Puis-je supposer que c'est vrai pour TOUS les Hotspot implémentations (c'est à dire sur tous les systèmes d'exploitation pour lesquels la JVM Hotspot est disponible)?

OriginalL'auteur XenoRo
2

Si vous avez beaucoup occupé de la mémoire que l'espace libre ne peut même soutenir l'arrêt de la JVM, vous recevoir un message d'erreur indiquant que le programme n'a pas assez de mémoire, ou de la JVM crash.

Si vous pouvez exécuter la JVM, vous pouvez spécifier la limite de la mémoire avec -Xmx. Cela ne veut pas dire que tout le tas sera alloué par la JVM sur démarrer - c'est seulement une limite interne. Si la JVM vous voulez augmenter l'espace de tas, mais il n'y a pas assez de mémoire, ou vous avez besoin de plus de tas que spécifié par-Xmx, vous obtiendrez OutOfMemoryError actuellement dans l'exécution des programmes Java.

Dans un très extreme condition, vous pouvez exécuter de mémoire libre, tandis que la JVM est en cours d'exécution, et dans le même temps, la JVM utilise plus de mémoire, pour son fonctionnement interne (pas sur le tas (de l'espace) - puis la JVM vous dit-il besoin de plus de mémoire, mais ne pouvait pas obtenir de toute, et met fin, ou il va se planter carrément.

J'ai un processus qui xms et xmx est le même, alors que mon processus se bloque parfois dans mon test env depuis la mémoire n'est pas en reste beaucoup, je suppose que peu de mémoire tue ma progression, mais je ne peux pas trouver un oom erreur ou oom tas de fichier de vidage(j'ai activer l'option). Dois-je supposer droit ou pas, si je suis rignt pourquoi il n'est pas OOM fichier?

OriginalL'auteur Jakub Zaverka
1

La JVM processus sera exécuté dans la mémoire virtuelle, de sorte que la question de l'attribution des autres processus en cours d'exécution est pertinente, mais pas complètement determinitive.

Lorsque la JVM ne peut pas allouer plus de mémoire (pour quelque raison que ce soit), le processus lui-même n'est pas arrêter, mais plutôt commence à jeter OutOfMemoryError dans la JVM, mais pas externe à la JVM. En d'autres termes, la machine continue de fonctionner, mais les programmes en cours d'exécution à l'intérieur de la JVM va généralement à l'échec, parce que la plupart ne le manipulez pas les conditions de mémoire faible de manière adéquate. Dans ce cas habituel, lorsque le programme ne fait rien pour gérer l'erreur, la JVM va mettre fin au programme et à la sortie. En fin de compte, c'est de l'allocation de mémoire, mais pas directement. Il est possible pour un morceau de code à l'échelle elle-même de retour en vertu de la condition de mémoire insuffisante et continuer à exécuter.

Et d'autres l'ont souligné, il arrive parfois que la JVM elle-même ne gère pas la mémoire faible, mais c'est un joli condition extrême.

OriginalL'auteur eh9

Vous devez vous connecter pour publier un commentaire.