Je travaille récemment sur un programme pour Java. À l’origine, j’ai toujours aimé la gestion de la mémoire de Java, pas besoin de s’inquiéter d’allouer la mémoire, il suffit d’alloquer, le collecteur d’ordures récupère la mémoire pour vous. Le programme est maintenant développé avec une grande quantité de données, et pour plus de rapidité, je vais charger toutes les informations en mémoire, ce qui garantira une réponse rapide. Je compte encore la mémoire à répétition, en pensant à ma propre quantité de données, ce qui devrait suffire au début (ma machine a de la mémoire 4G, bien que Windows reconnaisse le 3,5G, mais ça devrait aller comparé à mon volume de données actuel).
De manière inattendue, le programme de la première expérience a duré quelques heures et a rencontré une exception de mémoire. En regardant mes propres paramètres de VM, j’ai mis -Xms512M -Xmx1024M. Sans y réfléchir, je l’ai directement changé en -Xms512M -Xmx2048M, et le résultat a été que je n’ai pas pu réserver assez d’espace pour le tas d’objets. Le programme ne peut pas se lever. Ce n’est qu’à ce moment-là que j’ai réalisé qu’il y avait encore une limite à la mémoire maximale initiale. J’ai cherché sur Internet et trouvé de nombreux articles abordant ce sujet. Enfin, j’ai trouvé l’article le plus utile sur le forum DEV2DEV de BEA
Ici, le modérateur YuLimin a passé le test et est arrivé à la conclusion suivante :
Version JVM de l’entreprise Client à mémoire maximale (méga) Serveur à mémoire maximale (méga)
DIM 1.5.x 1492 1520
SUN. 1.5.5 (Linux) 2634 2660
DIM 1.4.2 1564 1564
SOL 1.4.2 (Linux) 1900 1260
IBM 1.4.2(Linux) 2047 N/A
BEA JRockit 1.5 (U3) 1909 1902
Je l’utilise JDK1.6.0_05 maintenant, je l’ai testé. Le plus gros problème dans l’état client, c’est que mon JDK ne reconnaît pas le paramètre -Server et ne peut pas tester l’état du serveur. Les estimations sont à peu près les mêmes.
DIM 1.6.0 1442 N/d
Il semble qu’il soit impossible d’utiliser une grande mémoire en Java. Et le dicton général est que si la mémoire est trop grande, le temps de collecte des déchets sera long. C’est aussi compréhensible, généralement collecté lorsque la mémoire n’est pas suffisante, que la mémoire 2G est bien sûr beaucoup plus lente que la 1G, et qu’il y a plus d’objets mémoire, la relation estimée augmente exponentiellement.
Vous trouverez ci-dessous les méthodes de test et les dossiers de test de YuLimin.
Méthode de test : Utilisez la commande java -XmxXXXXM -version pour tester en ligne de commande, puis augmentez progressivement la valeur de XXXX ; si cela s’exécute normalement, cela signifie que la taille de mémoire spécifiée est disponible, sinon un message d’erreur sera imprimé. |
Publié sur 24/07/2017 10:43:36
|
|
|
|
Propriétaire