Eine kurze Diskussion über die richtige Haltung der Tomcat-Speicherkonfiguration

1. Hintergrund

Obwohl ich viele Blogs und Artikel gelesen habe, konnte ich keine umfassenden Artikel zu JVM-Speicherzuweisungsmethoden finden. Viele davon sind einfach nur Kopieren und Einfügen.

Der Genauigkeit halber wird in diesem Artikel ausdrücklich darauf hingewiesen, dass er nur die Speicherzuweisung basierend auf der virtuellen Maschine HotSpot VM und JDK1.7 einführt. Die Diskussion über GC basiert auch auf der gleichzeitigen CMS-Sammlung (nicht G1), um zu verhindern, dass Experten sie kritisieren.

Die derzeit gängigste JVM ist HotSpot VM (gefolgt von J9 VM und Zing VM), und die meisten Blogbeiträge basieren auf Versionen vor JDK 1.7.

(Hinweis: Da unterschiedliche Implementierungen virtueller Maschinen und unterschiedliche JDKs unterschiedliche Speicherverteilungen haben, handelt es sich bei den im folgenden Artikel erwähnten Speicherstrukturen nur um logische Strukturen und nicht um die physischen Strukturen des Speichers.)

In diesem Artikel wird nur die Methode der Speicherzuweisung vorgestellt. Der spezifische Speicherbereinigungsmechanismus und das Prinzip der Speicherstruktur stehen nicht im Mittelpunkt dieses Artikels. Ich hoffe auch, dass durch diesen Artikel jeder ein wenig Verständnis für JVM bekommt. Der Herausgeber hat kein umfassendes Verständnis für JVM und möchte andere nicht in die Irre führen.

2. Allgemeine Speicherstruktur

Wenn Sie nur das Problem lösen und die Gründe nicht verstehen möchten, überspringen Sie bitte diesen Abschnitt

Dieser Artikel stellt die Struktur des Speicherbereichs mit Garbage Collection (GC-Heap, ausgenommen Programmzähler, Stapel und lokaler Methodenstapel) vor und zitiert dabei ein großartiges Sprichwort: „Das Leben eines Java-Objekts“.

Ich bin ein gewöhnliches Java-Objekt. Ich wurde im Eden-Gebiet geboren. Im Eden-Gebiet sah ich auch kleine Brüder (andere Java-Objekte), die mir sehr ähnlich sahen. Wir spielten ziemlich lange im Eden-Gebiet. Eines Tages waren zu viele Leute im Eden-Gebiet (was Young GC auslösen würde, und jedes GC würde das Alter um ein Jahr erhöhen), also war ich gezwungen, in das „Von“-Gebiet des Survivor-Gebiets zu gehen. Da ich in das Survivor-Gebiet ging, begann ich zu treiben, manchmal im „Von“-Gebiet des Survivor, manchmal im „Nach“-Gebiet des Survivor, ohne festen Wohnort (jedes Young GC erforderte, dass das „Von“-Gebiet und das „Nach“-Gebiet im Survivor-Gebiet „vertauscht“ wurden). Erst als ich 18 Jahre alt war (ich hatte 18 junge GCs), sagte mir mein Vater, dass ich erwachsen sei und es für mich an der Zeit sei, in die Gesellschaft hinauszugehen. Ich bin also zur älteren Generation gegangen. Es waren viele Leute da und sie waren alle ziemlich alt. Ich habe hier auch viele Leute kennengelernt. In der alten Generation habe ich 20 Jahre gelebt und wurde dann recycelt (Old GC).

Zur Erklärung wird zunächst der Gesamtspeicher in junge Generation (jung), alte Generation (alt) und permanente Generation (permanent) unterteilt, wie unten gezeigt

Junge Generation: (die Garbage Collection für die junge Generation wird als Young GC bezeichnet)

Die junge Generation ist in Eden-Bereich und Überlebens-Bereich unterteilt

1. Im Eden-Bereich entsteht ein neues Objekt ()

2. Der Überlebensbereich ist der Speicherbereich für Objekte, die die Garbage Collection überleben. Der Überlebensbereich ist in den Von-Bereich und den Bis-Bereich unterteilt.

2.1.from-Bereich: Nach der GC-Wiederherstellung werden Objekte, die im Eden-Bereich und im To-Bereich noch aktiv sind, im From-Bereich gespeichert.

2.2.to-Bereich: Nach der GC-Wiederherstellung werden die noch aktiven Objekte im Eden-Bereich und im From-Bereich in den To-Bereich übertragen.

2.3. Aufgrund der Operationen in 2.1 und 2.2 werden die verbleibenden Objekte im Von-Bereich und im Nach-Bereich hin und her übertragen, und ein Bereich ist immer leer.

Alte Generation: (Die Garbage Collection für die alte Generation wird als Old GC bezeichnet)

Nach 18 Young GCs werden Objekte, die in der jungen Generation noch aktiv sind, von der jungen Generation auf die alte Generation übertragen.

Wenn die alte Generation voll ist, wird die alte GC ausgelöst und die überlebenden Objekte verbleiben weiterhin in der alten Generation, bis sie nach 20 alten GCs recycelt werden.

Permanente Generation: (Vollständige GC zur Wiederherstellung der jungen Generation + alten Generation + permanenten Generation)

Es handelt sich um eine Implementierung des Java-Methodenbereichs der HotSpot-VM, in dem normalerweise Klasseninformationen, Konstantenpools, statische Variablen, JIT-kompilierter Code und andere Daten gespeichert werden (vereinfacht verstanden als der Speicherbereich für kompilierten Code, d. h. es kann so verstanden werden: Wenn unser Java-Projekt ausgeführt wird, ist umso mehr permanenter Generierungsspeicherplatz erforderlich, je mehr Klassendateien geladen werden).

(Hinweis: Es wird gesagt, dass die permanente Generierung ein Konzept ist, das nur der Hotspot-virtuellen Maschine vorbehalten ist. Andere JVMs verfügen nicht über dieses Konzept. In Java 8 wurde die permanente Generierung vollständig entfernt und durch einen anderen lokalen Speicher ersetzt, der nicht mit dem Heap verbunden ist – den Metaspace.)

3. Erklärung häufiger Speicherprobleme

Häufiges Problem 1 java.lang.OutOfMemoryError: Java-Heapspeicher ---- JVM-Heap (Heap)-Überlauf

Ursache: Während der Projektlaufzeit gibt es zu viele neue Objekte, die den konfigurierten maximalen Speicher füllen und so zu diesem Fehler führen.

Lösung: Stellen Sie die Größe von Xms und Xmx manuell ein.

Allgemeines Problem 2 java.lang.OutOfMemoryError: PermGen-Speicherplatz ---- Überlauf des PermGen-Speicherplatzes (permanente Generierung)

Ursache: Dieser Fehler tritt auf, wenn das entwickelte Projekt viele Java-Dateien enthält (d. h. das Projekt ist groß und die JVM lädt viele Dateien).

Lösung: Legen Sie die MaxPermSize-Größe manuell fest.

Häufiges Problem 3 java.lang.StackOverflowError ---- Stapelüberlauf

Grund: Normalerweise liegt dies an zu vielen Rekursionsebenen in einer Codelogik.

Lösung: Ändern Sie den rekursiven Code und steuern Sie die Anzahl der rekursiven Ebenen

4. Methode zur Speicherzuweisung (Vorschlag, kein Allheilmittel)

In diesem Artikel werden nur einige häufig verwendete Konfigurationsparameter vorgestellt. Normalerweise zählt die permanente Generation nicht als Heap-Speicher (sie belegt separat einen anderen Speicherbereich), und die neue Generation belegt die Hälfte der alten Generation, also 1/3 des gesamten Heap-Speichers. Nach diesem Prinzip geben wir ein Konfigurationsbeispiel.

Beispielsweise kann der Server 1 GB Speicher für die Projektnutzung bereitstellen. Basierend auf der obigen Abbildung geben wir die folgende Konfiguration an.

Betriebsart:

-Server-Modus, bessere Leistung bei Verwendung mehrerer CPUs

Neue Generation und alte Generation: (normalerweise werden die neue Generation und die alte Generation nicht separat konfiguriert, konfigurieren Sie daher einfach die gesamte Speicherheapgröße.)

-Xms384m Anfänglicher Speicherplatz des Speicherheaps

-Xmx768m Maximaler Speicherplatz für den Speicherheap

Permanente Generation: (neue Generation, der verbleibende Speicher der Konfiguration der alten Generation ist für die permanente Generation reserviert) --- Beachten Sie, dass jdk1.8 entfernt wurde

-XX:PermSize=128m Initialisierungsgröße der permanenten Generation

-XX:MaxPermSize=256m Maximaler Speicherplatz für permanente Generierung (Standard ist 64m)

4. Tomcat-Speicherkonfigurationsmethoden in verschiedenen Umgebungen

Wir haben verschiedene Speicherprobleme ausführlich erläutert und Konfigurationsparameter kurz vorgestellt. Nun stellen wir die spezifischen Konfigurationsmethoden in verschiedenen Umgebungen vor.

1. Starten Sie Tomcat über die Befehlszeile:

Ändern Sie TOMCAT_HOME/bin/catalina.sh (catalina.bat in Windows) und fügen Sie oben in der Datei die folgende Anweisung hinzu

JAVA_OPTS="-server -Xms384m -Xmx768m -XX:PermSize=128m -XX:MaxPermSize=256m"

2. Wenn Tomcat als Windows-Dienst registriert ist, können Sie es mit /bin/tomcat8w.exe im Tomcat-Verzeichnis ändern. Wie unten gezeigt

3. Wenn Sie MyEclipse zum Entwickeln und Starten von Tomcat verwenden, funktionieren die oben genannten Änderungen nicht. Sie können sie wie folgt festlegen:

Fügen Sie in Myeclipse->Einstellungen->Myeclipse->Server->Tomcat->Tomcat×.×->Optionale Java VM-Argumente im JDK-Bedienfeld Folgendes hinzu:

-server -Xms384m -Xmx768m -XX:PermSize=128m -XX:MaxPermSize=256m

Zum Schluss noch zwei Worte:

Unabhängig von der Konfiguration und den Parameterwerten müssen Sie kontinuierlich entsprechend dem tatsächlichen Projekt debuggen und dürfen nicht so schnell aufgeben.

Beispielsweise gilt bei der Speicherkonfiguration von Tomcat nicht: je größer, desto besser. Die beste Konfiguration ist die, die zum Projekt/Server passt.

Dies ist das Ende dieses Artikels über die korrekte Konfiguration des Tomcat-Speichers. Weitere Informationen zur Tomcat-Speicherkonfiguration finden Sie in früheren Artikeln auf 123WORDPRESS.COM oder in den folgenden verwandten Artikeln. Ich hoffe, Sie werden 123WORDPRESS.COM auch in Zukunft unterstützen!