Quelles sont les causes et les solutions au débordement de mémoire Java ?

Quelles sont les causes et les solutions du débordement de mémoire Java ?

Les différentes causes et solutions du débordement de mémoire Java sont :

Le premier type de débordement de mémoire est ce que tout le monde pense le plus, et la première réaction est qu'il s'agit d'un débordement de mémoire, c'est d'un débordement de pile :

Alors, quel genre de situation est un débordement de pile ? Lorsque vous voyez les mots-clés suivants, il s'agit d'un débordement de pile :

java.lang.OutOfMemoryError : ......java heap space....

C'est à ce moment-là que vous voyez quelque chose en rapport pour tas, il doit s'agir d'un débordement de pile. S'il n'y a pas de problème avec le code, cela peut être évité en ajustant -Xmx et -Xms de manière appropriée. Cependant, il faut partir du principe qu'il n'y a pas de problème avec le code. ça déborde ? , soit il y a un problème avec le code, soit il y a trop d'accès et chaque temps d'accès est trop long, soit il y a trop de données, ce qui empêche la libération des données, car le ramasse-miettes doit trouver quoi est une poubelle avant de pouvoir être recyclée, et il ne considérera pas ces choses ici. Ce sont des déchets, donc ils ne seront naturellement pas recyclés avant que l'idée ne déborde, le système peut signaler une erreur à l'avance avec les mots-clés :

java.lang.OutOfMemoryError : limite de dépassement de tête GC dépassée

Ceci La situation est que lorsque le système est dans un état GC haute fréquence et que l'effet de recyclage est encore faible, cette erreur commencera à être signalée . Cette situation entraîne généralement un grand nombre d'objets qui ne peuvent pas être libérés, ce qui peut être dû à une mauvaise utilisation des références ou à une demande d'objet volumineux, mais le dépassement de la mémoire de l'espace du tas Java peut ne pas signaler cette erreur à l'avance. , c'est-à-dire que cela peut être directement causé par une mémoire insuffisante, plutôt que par un GC haute fréquence

Le deuxième type de débordement de mémoire, lorsque PermGen déborde ou que PermGen est plein, vous verrez des mots-clés comme celui-ci :

Les informations clés sont :

java.lang.OutOfMemoryError : espace PermGen

Raison : le système contient beaucoup de code ou fait référence à de nombreux packages tiers, ou un grand nombre de constantes sont utilisées dans le code, ou des constantes sont injectées via interne, ou via un chargement dynamique de code, etc., ce qui conduit à l'expansion du pool de constantes, bien que JDK 1.5 et versions ultérieures puissent recycler la zone permanente via les paramètres , mais ce que nous espérons, c'est que cet endroit ne fera pas de GC, et cela suffira. Par conséquent, dans des circonstances normales, nous ferons moins d'opérations similaires cette année, donc la méthode couramment utilisée face à cette situation est : PermGen Le débordement et. la taille de -XX:MaxPermSize.

Le troisième type de débordement de mémoire : utilisé lors de l'utilisation d'allocateDirect() dans ByteBuffer. De nombreux frameworks javaNIO sont encapsulés comme d'autres méthodes

Mot-clé de débordement :

java.lang.OutOfMemoryError. : Mémoire tampon directe
Si vous utilisez directement ou indirectement la méthode allocateDirect dans ByteBuffer sans effacer, un problème similaire se produira. Sortie IO du programme de référence régulier Il existe un processus de conversion entre le mode noyau et le mode utilisateur, qui correspond à la mémoire directe et. mémoire indirecte. Si vous souhaitez envoyer le contenu d'un fichier au client dans une application standard, vous devez le copier dans la mémoire indirecte du programme via la conversion directe de la mémoire du système d'exploitation (c'est-à-dire dans le tas. ), puis sorti vers la mémoire directe et envoyé par le système d'exploitation. La mémoire directe est gérée conjointement par le système d'exploitation et l'application peut être directement contrôlée par l'application elle-même. La mémoire dans la mémoire directe. ne sera pas récupéré, alors soyez prudent.

Si des opérations similaires se produisent fréquemment, vous pouvez envisager de définir les paramètres : -XX:MaxDirectMemorySize

Erreur de dépassement de mémoire de type 4 :

Mot clé de débordement :

java .lang.StackOverflowError

Ce paramètre explique directement une chose, c'est-à-dire que -Xss est trop petit. Nous demandons que de nombreuses aiguilles de pile d'appels locales et autres contenus soient stockés dans le thread actuellement détenu par l'utilisateur. thread Avant jdk 1.4, la valeur par défaut était de 256 Ko, et après la version 1.5, elle était de 1 Mo. Si cette erreur est signalée, cela signifie uniquement que le paramètre -Xss est trop petit. Bien sûr, les JVM de certains fabricants n'ont pas ce paramètre. est uniquement pour Hotspot VM, cependant, si nécessaire, vous pouvez apporter quelques optimisations au système afin que la valeur de -Xss soit disponible.

Le cinquième type d'erreur de dépassement de mémoire :

Mot-clé de débordement :

java.lang.OutOfMemoryError : impossible de créer un nouveau thread natif

Le quatrième ci-dessus Ce type d'erreur de débordement a expliqué l'espace mémoire du thread. En fait, le thread n'occupe essentiellement que la zone mémoire autre que le tas. être alloué au thread. Cela est soit dû au fait que la mémoire elle-même n'est pas suffisante, soit que l'espace du tas est trop grand, ce qui entraîne peu de mémoire restante, et comme le thread lui-même occupe de la mémoire, ce n'est pas suffisant. est expliqué, et comment le modifier, je n'ai pas besoin d'en dire plus, vous comprenez.

Débordement de mémoire de catégorie 6 :

Mot clé de débordement

java.lang.OutOfMemoryError : demande de {} octets pour {}hors échange

Erreurs de cette classe sont généralement dus à un espace d'adressage insuffisant.

Les six grandes catégories de débordements courants représentent 99 % des situations de débordement dans la JVM. Il est très difficile d'échapper à ces situations de débordement, à moins que des défauts très étranges ne se produisent, comme une défaillance du cache de code due au matériel de mémoire physique. problèmes. Erreur (se produit lors du processus de conversion du code octet en code natif, mais la probabilité est extrêmement faible), dans ce cas, la mémoire sera directement écrasée, similaire à l'interaction fréquente du swap, dans certains systèmes, le système le fera. être directement planté. Si l'espace d'adressage du système d'exploitation n'est pas suffisant, le système ne peut pas démarrer du tout, haha ​​; l'abus de JNI entraînera également des problèmes de non-libération de la mémoire locale, alors essayez d'éviter d'ouvrir trop de sockets avec socket ; les données de connexion rapporteront également quelque chose comme : IOException : Trop de fichiers ouverts et autres messages d'erreur.

Tutoriel recommandé : "Tutoriel vidéo Java"

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!