Je ne suis pas d'accord avec l'opinion de @Founder. J'ai vu de nombreuses personnes commencer à modifier la taille de la mémoire du tas dès que le MOO se produit, et ajuster la mémoire du tas ne signifie peut-être pas que plus c'est mieux, plus c'est gros.
Tout d'abord, diffusez les connaissances :
La mémoire tas est divisée en nouvelle génération et ancienne génération La nouvelle génération est utilisée pour stocker des objets qui doivent souvent être GC. S'il n'a pas été GCed pendant plus d'un certain temps, il sera promu à l'ancienne génération pour le stockage.
L'ancienne génération disposera d'un espace plus grand que la nouvelle génération.
Lorsque le MOO se produit, la mémoire est insuffisante dans l'ancienne génération (car s'il n'y a pas suffisamment de mémoire dans la nouvelle génération, elle sera placée dans l'ancienne génération pour le stockage).
Il est recommandé d'analyser et de résoudre le problème de la manière suivante :
1. Vérifiez directement le code pour voir s'il y a des fuites de mémoire telles que des boucles infinies ou des références d'éléments non publiées dans la collection.
2. Définir les paramètres JVM -XX:+HeapDumpOutOfMemoryError et -XX:HeapDumpPath=<你的path>
3. Utilisez l'outil d'analyse d'image mémoire (http://www.eclipse.org/mat/) pour analyser s'il s'agit d'une fuite de mémoire ou d'un débordement de mémoire, et le situation de fuite de mémoire. Ensuite, découvrez comment l'objet divulgué est lié à GC ROOTS, puis trouvez l'emplacement du code divulgué.
4. S'il n'y a pas de fuite de mémoire, combinez la mémoire physique de la machine pour voir si vous pouvez continuer à augmenter la mémoire du tas (-Xms et -Xmx). Notez également ici que plus le paramètre de mémoire du tas est grand, plus la mémoire du tas est grande. mieux. Parce que lorsqu'un FULL GC se produit sur une grande mémoire, il enverra "stop the world" pendant longtemps, ce qui est inacceptable
La solution simple consiste à ajuster la taille du tas Modifiez les paramètres de démarrage dans Eclilpse et ajoutez -Xms384m -Xmx384m aux arguments de la VM ou Ajoutez -Xms384m au catalina.bat de Tomcat - Xmx384m
Cependant, il est recommandé de vérifier à nouveau le code
@letcheng est d'accord avec son point de vue. Vous n'êtes qu'un pur projet Java, pas un projet Web. Combien d'objets pouvez-vous créer et provoquer un MOO sur le tas ? Cela est donc dû en grande partie à votre code. Sous JDK, il existe l'outil JConsole.exe intégré. Vous pouvez observer le nombre d'objets dont vous disposez actuellement, la quantité de mémoire tas disponible et quand le MOO s'est produit ?
Pour ce genre de problème, il est recommandé d'utiliser des outils comme findbug ou sonar pour exécuter le programme afin de voir où il y a un risque de fuite de mémoire entraînant un débordement de mémoire
java.lang.OutOfMemoryError : l'espace du tas Java est l'état jeune et ancien de la mémoire du tas. Il sera lancé lorsque l'espace mémoire est épuisé. Donc, d'une manière générale, ce problème est principalement causé par la mémoire créée qui ne peut pas être créée. être recyclé, comme la classe IO la plus courante. Ne faites pas xx.close()
après utilisation.
Il ne suffit pas de configurer une grande mémoire dans TOMCAT. Vous devez trouver la source. S'il y a un problème de fuite de mémoire, quelle que soit la taille de la mémoire, cela ne servira à rien.
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Je ne suis pas d'accord avec l'opinion de @Founder. J'ai vu de nombreuses personnes commencer à modifier la taille de la mémoire du tas dès que le MOO se produit, et ajuster la mémoire du tas ne signifie peut-être pas que plus c'est mieux, plus c'est gros.
Tout d'abord, diffusez les connaissances :
La mémoire tas est divisée en nouvelle génération et ancienne génération La nouvelle génération est utilisée pour stocker des objets qui doivent souvent être GC. S'il n'a pas été GCed pendant plus d'un certain temps, il sera promu à l'ancienne génération pour le stockage.
L'ancienne génération disposera d'un espace plus grand que la nouvelle génération.
Lorsque le MOO se produit, la mémoire est insuffisante dans l'ancienne génération (car s'il n'y a pas suffisamment de mémoire dans la nouvelle génération, elle sera placée dans l'ancienne génération pour le stockage).
Il est recommandé d'analyser et de résoudre le problème de la manière suivante :
1. Vérifiez directement le code pour voir s'il y a des fuites de mémoire telles que des boucles infinies ou des références d'éléments non publiées dans la collection.
2. Définir les paramètres JVM
-XX:+HeapDumpOutOfMemoryErroret-XX:HeapDumpPath=<你的path>3. Utilisez l'outil d'analyse d'image mémoire (http://www.eclipse.org/mat/) pour analyser s'il s'agit d'une fuite de mémoire ou d'un débordement de mémoire, et le situation de fuite de mémoire. Ensuite, découvrez comment l'objet divulgué est lié à GC ROOTS, puis trouvez l'emplacement du code divulgué.
4. S'il n'y a pas de fuite de mémoire, combinez la mémoire physique de la machine pour voir si vous pouvez continuer à augmenter la mémoire du tas (-Xms et -Xmx). Notez également ici que plus le paramètre de mémoire du tas est grand, plus la mémoire du tas est grande. mieux. Parce que lorsqu'un FULL GC se produit sur une grande mémoire, il enverra "stop the world" pendant longtemps, ce qui est inacceptable
La solution simple consiste à ajuster la taille du tas
Modifiez les paramètres de démarrage dans Eclilpse et ajoutez -Xms384m -Xmx384m aux arguments de la VM
ou
Ajoutez -Xms384m au catalina.bat de Tomcat - Xmx384m
Cependant, il est recommandé de vérifier à nouveau le code
@letcheng est d'accord avec son point de vue. Vous n'êtes qu'un pur projet Java, pas un projet Web. Combien d'objets pouvez-vous créer et provoquer un MOO sur le tas ? Cela est donc dû en grande partie à votre code.
Sous JDK, il existe l'outil JConsole.exe intégré. Vous pouvez observer le nombre d'objets dont vous disposez actuellement, la quantité de mémoire tas disponible et quand le MOO s'est produit ?
Pour ce genre de problème, il est recommandé d'utiliser des outils comme findbug ou sonar pour exécuter le programme afin de voir où il y a un risque de fuite de mémoire entraînant un débordement de mémoire
java.lang.OutOfMemoryError : l'espace du tas Java est l'état jeune et ancien de la mémoire du tas. Il sera lancé lorsque l'espace mémoire est épuisé. Donc, d'une manière générale, ce problème est principalement causé par la mémoire créée qui ne peut pas être créée. être recyclé, comme la classe IO la plus courante. Ne faites pas xx.close()
après utilisation.Il ne suffit pas de configurer une grande mémoire dans TOMCAT. Vous devez trouver la source. S'il y a un problème de fuite de mémoire, quelle que soit la taille de la mémoire, cela ne servira à rien.