Existe-t-il un moyen de définir la taille du tas à partir d'un programme Java en cours d'exécution ?
Non.
Ce que vous pouvez faire avec une application dont les besoins en matière de tas sont très variables, c'est définir la taille maximale du tas de manière très élevée à l'aide de la commande -Xmx et régler -XX:MaxHeapFreeRatio y -XX:MinHeapFreeRatio afin que l'application ne s'accroche pas à beaucoup de mémoire lorsque le tas se réduit (c'est ce qu'elle fait avec les paramètres par défaut).
Mais notez que cela peut causer des problèmes de performance lorsque la mémoire réellement utilisée par l'application varie fortement et rapidement - dans ce cas, il vaut mieux que l'application garde toute la mémoire plutôt que de la rendre au système d'exploitation pour la réclamer à nouveau une seconde plus tard. Vous pouvez également jouer avec le paramètre Options GC pour s'assurer que le GC ne laisse pas trop d'objets non réclamés traîner, ce qu'il a tendance à faire lorsqu'il y a beaucoup de place pour que le tas s'agrandisse, et qui irait à l'encontre de l'objectif de vouloir que la taille du tas s'adapte aux besoins de l'application.
-XX:MaxHeapFreeRatio La valeur par défaut de ce paramètre est 70. Le ratio libre est la quantité d'espace non alloué sur le tas par rapport à la taille totale du tas. Si le pourcentage d'espace libre dépasse la valeur par défaut de 70 %, le jvm réduira la taille du tas pour permettre au système d'exploitation d'utiliser la mémoire.
C'est possible (et je l'ai souvent fait), mais le problème est que l'utilisation de la mémoire peut varier considérablement. Ce n'est pas proportionnel à l'ensemble des objets vivants, le simple fait de créer beaucoup d'objets à la suite peut faire exploser le tas. Elle ne diminue que si vous provoquez manuellement une GC. Vous devez donc réserver la quantité maximale de RAM réelle. Nous avons vraiment besoin d'une option permettant de modifier la taille maximale du tas de manière dynamique.
Selon http://www.dreamincode.net/forums/showtopic96263.htm Vous ne pouvez pas le faire au moment de l'exécution, mais vous pouvez créer un autre processus avec une taille de tas différente.
Aussi connu comme une douleur monumentale dans le dos. Si vous utilisez beaucoup de mémoire, la dernière chose que vous voulez est de la libérer entièrement, puis de la recharger dans un autre processus. Bien sûr, vous ne pouvez pas garder l'ancien processus ouvert assez longtemps pour transférer les données, car vous monopolisez encore plus de mémoire avec deux processus juste pour effectuer le transfert. J'espère que vous avez deviné juste este temps ou vous devez tout recommencer.
Vous pouvez modifier ces paramètres lorsque vous démarrez votre application, mais une fois la JVM lancée, ces valeurs ne peuvent plus être modifiées. Quelque chose comme ça :
java -Xms32m -Xmx512m FooBar
définira la taille minimale du tas à 32 Mo et la taille maximale du tas à 512 Mo. Une fois ces valeurs définies, vous ne pouvez pas les modifier dans le programme en cours d'exécution.
Le consensus peut effectivement être que ce n'est pas possible, mais nous devrions examiner la source de la JVM pour voir comment elle peut être contrôlée de manière ergonomique. Il serait très agréable de pouvoir faire en sorte qu'un agent JVMTI puisse ajuster la taille du tas/perm/tenu/nouveau/&c en ligne/au moment de l'exécution.
Cela permettrait aux agents de déduire les ajustements de taille en fonction des objectifs de performance ou d'encombrement, ce qui sera important lors du déplacement des JVM dans le nuage.
Vous pouvez utiliser le -mx au démarrage (également connu sous le nom de -Xmx ) Il s'agit de la taille maximale dont vous aurez jamais besoin, c'est pourquoi vous ne devriez pas avoir besoin de la régler sur une valeur supérieure à la taille maximale dont vous aurez jamais besoin.
Cependant, une solution consiste à faire en sorte que la fonction main() vérifie la taille maximale et redémarre le programme Java si la taille maximale n'est pas celle souhaitée, c'est-à-dire lancer un autre programme Java et mourir.
Cela suppose que vous connaissiez à l'avance la quantité de mémoire dont vous aurez besoin. C'est bien pour les serveurs web/autres choses qui diffusent en continu, mais si vous analysez des données (par exemple, pour construire un index ou rechercher des tendances), vous devez savoir à l'avance ce que seront vos données, ce qui est assez limité.
@Basic Vous n'avez pas besoin de connaître la quantité de mémoire dont vous aurez besoin. Le -Xmx est le maximum que la JVM peut avoir, c'est-à-dire que le programme devrait se planter avec une OutOfMemoryError plutôt que d'utiliser plus de mémoire. Ce maximum est généralement basé sur la quantité de mémoire dont vous disposez et la valeur par défaut est 1/4 de la mémoire principale. La JVM n'utilisera pas beaucoup de mémoire pour un programme "hello world", quel que soit le maximum fixé.
Supposons que vous avez un processus et que vous lui donnez 50 gigas de mémoire à l'avance et que pendant l'exécution vous remarquez que beaucoup de GC se passe et que probablement 56 GiB serait mieux et vous ne pouvez pas facilement redémarrer le programme sans faire beaucoup de recalcul...
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
1 votes
Pour référence, voici le RFE pour hotspot : bugs.sun.com/bugdatabase/view_bug.do?bug_id=4408373