JVM verwaltet zwei Arten von Speicher: Heap und Nicht-Heap. Der Heap steht Entwicklern zur Verfügung, wie oben erwähnt, er wird beim Start der JVM erstellt; der Nicht-Heap ist für die JVM selbst zum Speichern von Klasseninformationen reserviert. Es unterscheidet sich vom Heap. GC gibt zur Laufzeit keinen Speicherplatz frei.
1. Speicherüberlauftyp
1. java.lang.OutOfMemoryError: PermGen-Speicherplatz
JVM verwaltet zwei Arten von Speicher: Heap und Nicht-Heap. Der Heap steht Entwicklern zur Verfügung, wie oben erwähnt, er wird beim Start der JVM erstellt; der Nicht-Heap ist für die JVM selbst zum Speichern von Klasseninformationen reserviert. Es unterscheidet sich vom Heap. GC gibt zur Laufzeit keinen Speicherplatz frei. Wenn die Web-App eine große Anzahl von Jars von Drittanbietern verwendet oder die Anwendung zu viele Klassendateien hat und die MaxPermSize-Einstellung zufällig klein ist, führt das Überschreiten des Grenzwerts auch dazu, dass der Speicher zu viel belegt und einen Überlauf verursacht, oder der Tomcat wird dies tun Bereinigen Sie die Vorderseite während der Hot-Bereitstellung nicht. Die geladene Umgebung ändert nur den Kontext in die neu bereitgestellte Umgebung und es wird immer mehr nicht stapelbare Inhalte geben.
Der vollständige Name des PermGen-Speicherplatzes ist „Permanent Generation Space“ und bezieht sich auf den permanenten Speicherbereich, der von der JVM hauptsächlich zum Speichern von Klassen- und Metainformationen verwendet wird Wird vom Loader geladen und speichert Klasseninstanzen (Instanz). Der Heap-Bereich ist unterschiedlich. GC (Garbage Collection) bereinigt den PermGen-Speicherplatz während der Ausführung des Hauptprogramms nicht. Wenn Ihre Anwendung also viele CLASS-, PermGen- wird wahrscheinlich erscheinen. Space-Fehler. Dieser Fehler tritt häufig auf, wenn der Webserver JSP vorkompiliert. Wenn Ihre WEB-APP eine große Anzahl von Jars von Drittanbietern verwendet und deren Größe die Standardgröße des JVM (4 MB) überschreitet, wird diese Fehlermeldung generiert.
Ein bestes Konfigurationsbeispiel: (Nach meiner Überprüfung ist Tomcat seit der Verwendung dieser Konfiguration nie wieder gestorben.)
set JAVA_OPTS=-Xms800m -Xmx800m -XX:PermSize=128M -XX:MaxNewSize=256m -XX:MaxPermSize=256m
Fügen Sie unter Linux eine Codezeile hinzu, wie in rot in tomcathome/conf/catalina.sh dargestellt: Sie können den Speicher von Tomcat JVM erhöhen, sodass ein Speicherüberlauf weniger wahrscheinlich ist!
# ----- Den angeforderten Befehl ausführen --------------------------- -
JAVA_OPTS="-server -Xms512m -Xmx2048m -XX:PermSize=128m -XX:MaxNewSize=256m -XX:MaxPermSize=256m"
# Bugzilla 37848: Dies wird nur ausgegeben, wenn wir ein TTY haben
2. java.lang.OutOfMemoryError: Javaheap-Speicherplatz
Die erste Situation ist eine Ergänzung, und das Hauptproblem tritt in dieser Situation auf. Sein Standardspeicherplatz (d. h. -Xms) beträgt 1/64 des physischen Speichers und der maximale Speicherplatz (-Xmx) beträgt 1/4 des physischen Speichers. Wenn weniger als 40 % des Speichers übrig bleiben, erhöht die JVM den Heap auf den durch Xmx festgelegten Wert. Wenn der verbleibende Speicher 70 % überschreitet, verringert die JVM den Heap auf den durch Xms festgelegten Wert. Daher sollten die Xmx- und Xms-Einstellungen des Servers im Allgemeinen gleich eingestellt sein, um zu vermeiden, dass die Größe des Heaps der virtuellen Maschine nach jedem GC angepasst wird. Unter der Annahme, dass der physische Speicher unendlich ist, hängt der maximale JVM-Speicher vom Betriebssystem ab. Im Allgemeinen liegt die 32-Bit-Maschine zwischen 1,5 g und 3 g, während die 64-Bit-Maschine keine Begrenzung hat.
Hinweis: Wenn Xms den Xmx-Wert überschreitet oder die Summe aus dem maximalen Heap-Wert und dem maximalen Nicht-Heap-Wert die maximale Grenze des physischen Speichers oder des Betriebssystems überschreitet, wird der Server nicht gestartet.
Die Rolle der Garbage Collection GC
Die Häufigkeit von JVM-Aufrufen von GC ist immer noch sehr hoch, und die Speicherbereinigung wird hauptsächlich in zwei Situationen durchgeführt:
Wenn der Anwendungsthread nicht ausreicht, wird der GC kontinuierlich aufgerufen. Wenn das Problem des unzureichenden Speicherheaps nicht gelöst werden kann, wird ein Fehler wegen unzureichendem Speicher gemeldet. Da diese Ausnahme von der Betriebsumgebung des Systems abhängt, ist es unmöglich vorherzusagen, wann sie auftritt.
Gemäß dem GC-Mechanismus führt die Ausführung des Programms zu Änderungen in der Systembetriebsumgebung, wodurch die Wahrscheinlichkeit einer GC-Auslösung erhöht wird.
Um diese Probleme zu vermeiden, sollten beim Entwerfen und Schreiben von Programmen die Speicherbelegung durch Müllobjekte und der Overhead von GC vermieden werden. Der explizite Aufruf von System.GC() kann nur darauf hinweisen, dass die JVM Müllobjekte im Speicher recyceln muss, dies muss jedoch nicht sofort erfolgen.
Zum einen kann es das Problem der knappen Speicherressourcen nicht lösen und erhöht auch den GC-Verbrauch.
2. Zusammensetzung des JVM-Speicherbereichs <BR>Sprechen Sie einfach über den Heap und den Stack in Java
Java unterteilt den Speicher in zwei Typen: einen Stapelspeicher und einen Heapspeicher.
1. In der Funktion definierte Basistypvariablen und Objektreferenzvariablen werden im Stapelspeicher der Funktion zugewiesen.
2. Der Heapspeicher wird zum Speichern von neu erstellten Objekten und Arrays verwendet. Wenn eine Variable in einer Funktion (Codeblock) definiert wird, weist Java der Variablen Speicherplatz zu Geben Sie den für die Variable zugewiesenen Speicherplatz automatisch frei. Der im Heap zugewiesene Speicher wird vom automatischen Garbage Collector der Java Virtual Machine verwaltet. Der Vorteil des Heaps besteht darin, dass die Speichergröße dynamisch zugewiesen werden kann muss dem Compiler nicht im Voraus mitgeteilt werden, da es sich im Speicher befindet und zur Laufzeit dynamisch zugewiesen wird. Der Nachteil besteht darin, dass der Speicher zur Laufzeit dynamisch zugewiesen werden muss und die Zugriffsgeschwindigkeit langsam ist.
Der Vorteil des Stapels besteht darin, dass die Zugriffsgeschwindigkeit schneller ist als die des Heaps. Der Nachteil besteht darin, dass die Größe und Lebensdauer der im Stapel gespeicherten Daten deterministisch und unflexibel sein muss.
Der Java-Heap ist in drei Bereiche unterteilt: Neu, Alt und Permanent
GC hat zwei Threads:
Neu erstellte Objekte werden dem neuen Bereich zugewiesen. Wenn der Bereich gefüllt ist, wird er vom GC-Hilfsthread in den alten Bereich verschoben. Wenn der alte Bereich ebenfalls gefüllt ist, wird der GC-Hauptthread dazu veranlasst, alle darin enthaltenen Objekte zu durchlaufen der Heap-Speicher. Die Größe des alten Bereichs ist gleich Xmx minus -Xmn
Anpassung des Java-Stack-Speicherstapels: Die Parameter lauten +UseDefaultStackSize -Xss256K, was bedeutet, dass jeder Thread 256 KB Stapelspeicherplatz beantragen kann.
3. So legen Sie den virtuellen Speicher in JVM fest <BR>Tipp: Wenn in JVM 98 % der Zeit für GC verwendet werden und die verfügbare Heap-Größe weniger als 2 % beträgt, wird diese Ausnahmemeldung ausgegeben.
Tipp: Die maximale Heap-Größe sollte 80 % des verfügbaren physischen Speichers nicht überschreiten. Im Allgemeinen sollten die Optionen -Xms und -Xmx auf den gleichen Wert gesetzt werden und -Xmn sollte 1/4 des -Xmx-Werts betragen.
Tipp: Der von der JVM zugewiesene Anfangsspeicher wird durch -Xms angegeben, und der Standardwert beträgt 1/64 des physischen Speichers. Der von der JVM zugewiesene maximale Speicher wird durch -Xmx angegeben, und der Standardwert beträgt 1/4 des physischen Speichers Erinnerung.
Wenn der freie Heap-Speicher weniger als 40 % beträgt, erhöht die JVM den Heap standardmäßig bis zur Höchstgrenze von -Xmx. Wenn der freie Heap-Speicher größer als 70 % ist, reduziert die JVM den Heap bis zur Mindestgrenze von -Xms. Daher setzt der Server im Allgemeinen -Xms und -Xmx auf den gleichen Wert, um eine Anpassung der Heap-Größe nach jedem GC zu vermeiden.
Tipp: Unter der Annahme, dass der physische Speicher unendlich ist, hängt der maximale Wert des JVM-Speichers stark vom Betriebssystem ab.
Um es einfach auszudrücken: Obwohl ein 32-Bit-Prozessor über einen steuerbaren Speicherplatz von 4 GB verfügt, wird das spezifische Betriebssystem eine Grenze setzen.
Diese Grenze beträgt im Allgemeinen 2 GB bis 3 GB (im Allgemeinen sind es 1,5 GB bis 2 GB unter Windows-Systemen und 2 GB bis 3 GB unter Linux-Systemen). Für Prozessoren über 64 Bit gibt es keine Begrenzung.
Hinweis: Wenn Xms den Xmx-Wert überschreitet oder die Summe aus dem maximalen Heap-Wert und dem maximalen Nicht-Heap-Wert die maximale Grenze des physischen Speichers oder des Betriebssystems überschreitet, wird der Server nicht gestartet.
Tipp: Stellen Sie NewSize und MaxNewSize gleich ein und die Größe von „neu“ sollte nicht größer als die Hälfte von „alt“ sein. Der Grund dafür ist, dass der „Haupt“-GC häufig ausgelöst wird, wenn der alte Bereich nicht groß genug ist , was die Leistung stark reduziert.
JVM verwendet -XX:PermSize, um den Anfangswert des Nicht-Heap-Speichers festzulegen. Der Standardwert ist 1/64 des physischen Speichers.
Die maximale Nicht-Heap-Speichergröße wird durch XX:MaxPermSize festgelegt. Der Standardwert beträgt 1/4 des physischen Speichers.
Lösung: Legen Sie die Heap-Größe manuell fest
Ändern Sie TOMCAT_HOME/bin/catalina.bat
Fügen Sie die folgenden Zeilen über „echo „Using CATALINA_BASE: $CATALINA_BASE““ hinzu:
JAVA_OPTS="-server -Xms800m -Xmx800m -XX:MaxNewSize=256m"
4. Verwenden Sie Tools zur Leistungsprüfung , um Speicherlecks zu lokalisieren:
Das JProfiler-Tool wird hauptsächlich zur Überprüfung und Verfolgung der Leistung von Systemen verwendet (beschränkt auf die Java-Entwicklung). JProfiler kann den JVM-Betrieb und die Leistung überwachen, indem es jederzeit die Speichernutzung, die Speicherbereinigung, den Thread-Laufstatus und andere Maßnahmen des Systems ständig überwacht.
1. Der Speicher des Anwendungsservers ist über einen längeren Zeitraum unangemessen belegt. Der Speicher ist häufig auf einem hohen Niveau belegt und lässt sich nur schwer auf ein niedriges Niveau wiederherstellen.