Leitfaden zu den wichtigsten JVM-Parametern

1. Übersicht

In diesem kurzen Tutorial werden die bekanntesten Optionen erläutert, mit denen die Java Virtual Machine konfiguriert werden kann.

2. Expliziter Heapspeicher - Xms- und Xmx-Optionen

Eine der häufigsten leistungsbezogenen Methoden besteht darin, den Heapspeicher gemäß den Anwendungsanforderungen zu initialisieren.

Deshalb sollten wir die minimale und maximale Heap-Größe angeben. Die folgenden Parameter können verwendet werden, um dies zu erreichen:

-Xms[unit] -Xmx[unit]

Hier Einheit bezeichnet die Einheit , in der der Speicher (angezeigt durch Heap - Größe ) initialisiert werden. Einheiten können für GB als 'g' , für MB als ' m' und für KB als 'k' markiert werden .

Wenn wir beispielsweise JVM mindestens 2 GB und höchstens 5 GB zuweisen möchten, müssen wir Folgendes schreiben:

-Xms2G -Xmx5G

Ab Java 8 ist die Größe von Metaspace nicht definiert. Sobald das globale Limit erreicht ist, erhöht JVM es automatisch. Um jedoch unnötige Instabilitäten zu vermeiden , können Sie die Metaspace- Größe wie folgt festlegen :

-XX:MaxMetaspaceSize=[unit]

Hier bezeichnet die Metaspace-Größe die Speichermenge, die wir Metaspace zuweisen möchten .

Gemäß den Oracle-Richtlinien ist nach dem insgesamt verfügbaren Speicher der Anteil der Heap, der für die junge Generation reserviert ist, der zweitgrößte Faktor. Standardmäßig beträgt die minimale Größe des YG 1310 MB und die maximale Größe ist unbegrenzt .

Wir können sie explizit zuweisen:

-XX:NewSize=[unit] -XX:MaxNewSize=[unit]

3. Müllabfuhr

Für eine bessere Stabilität der Anwendung ist die Auswahl des richtigen Garbage Collection-Algorithmus von entscheidender Bedeutung.

JVM verfügt über vier Arten von GC- Implementierungen:

  • Serial Garbage Collector
  • Paralleler Garbage Collector
  • CMS Garbage Collector
  • G1 Müllsammler

Diese Implementierungen können mit den folgenden Parametern deklariert werden:

-XX:+UseSerialGC -XX:+UseParallelGC -XX:+USeParNewGC -XX:+UseG1GC

Weitere Details zu Garbage Collection- Implementierungen finden Sie hier.

4. GC-Protokollierung

Um den Anwendungszustand streng zu überwachen, sollten wir immer die Garbage Collection- Leistung der JVM überprüfen . Der einfachste Weg, dies zu tun, besteht darin, die GC- Aktivität in einem für Menschen lesbaren Format zu protokollieren .

Mit den folgenden Parametern können wir die GC- Aktivität protokollieren :

-XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles= -XX:GCLogFileSize=[ unit ] -Xloggc:/path/to/gc.log

UseGCLogFileRotation gibt die fortlaufende Richtlinie für Protokolldateien an, ähnlich wie log4j, s4lj usw. NumberOfGCLogFiles gibt die maximale Anzahl von Protokolldateien an, die für einen einzelnen Anwendungslebenszyklus geschrieben werden können. GCLogFileSize gibt die maximale Größe der Datei an. Schließlich bezeichnet loggc seinen Standort.

Hierbei ist zu beachten, dass zwei weitere JVM-Parameter verfügbar sind ( -XX: + PrintGCTimeStamps und -XX: + PrintGCDateStamps ), mit denen der datumsbezogene Zeitstempel im GC- Protokoll gedruckt werden kann .

Wenn Sie beispielsweise maximal 100 GC- Protokolldateien mit einer maximalen Größe von jeweils 50 MB zuweisen und diese am Speicherort ' / home / user / log /' speichern möchten , können Sie die folgende Syntax verwenden:

-XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=50M -Xloggc:/home/user/log/gc.log

Das Problem ist jedoch, dass immer ein zusätzlicher Daemon-Thread zur Überwachung der Systemzeit im Hintergrund verwendet wird. Dieses Verhalten kann zu einem Leistungsengpass führen. Deshalb ist es immer besser, in der Produktion nicht mit diesem Parameter zu spielen.

5. Umgang mit nicht genügend Speicher

Bei einer großen Anwendung tritt häufig ein Speicherfehler auf, der wiederum zum Absturz der Anwendung führt. Es ist ein sehr kritisches Szenario und sehr schwer zu replizieren, um das Problem zu beheben.

Aus diesem Grund enthält JVM einige Parameter, die den Heapspeicher in eine physische Datei speichern, die später zum Auffinden von Lecks verwendet werden kann:

-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./java_pid.hprof -XX:OnOutOfMemoryError=";" -XX:+UseGCOverheadLimit

Ein paar Punkte, die hier zu beachten sind:

  • HeapDumpOnOutOfMemoryError weist die JVM an, im Falle von OutOfMemoryError den Heap in eine physische Datei zu kopieren
  • HeapDumpPath gibt den Pfad an, in den die Datei geschrieben werden soll. Jeder Dateiname kann angegeben werden. Wenn JVM jedoch a findetTag im Namen, die Prozess-ID des aktuellen Prozesses, der den Speicherfehler verursacht, wird an den Dateinamen im Format .hprof angehängt
  • OnOutOfMemoryError wird verwendet, um Notfallbefehle auszugeben , die bei einem Speicherfehler ausgeführt werden sollen. Der richtige Befehl sollte im Bereich von cmd args verwendet werden. Wenn wir beispielsweise den Server neu starten möchten, sobald nicht genügend Arbeitsspeicher vorhanden ist, können wir den folgenden Parameter festlegen:
-XX:OnOutOfMemoryError="shutdown -r"
  • UseGCOverheadLimit ist eine Richtlinie, die den Anteil der Zeit der VM begrenzt, die in GC verbracht wird, bevor ein OutOfMemory- Fehler ausgelöst wird

6. 32/64 Bit

In der Betriebssystemumgebung, in der sowohl 32- als auch 64-Bit-Pakete installiert sind, wählt die JVM automatisch 32-Bit-Umgebungspakete aus.

Wenn Sie die Umgebung manuell auf 64-Bit einstellen möchten, können Sie dies mit dem folgenden Parameter tun:

-d

Das Betriebssystembit kann entweder 32 oder 64 sein . Weitere Informationen hierzu finden Sie hier.

7. Sonstiges

  • -server : aktiviert "Server Hotspot VM"; Dieser Parameter wird standardmäßig in 64-Bit-JVM verwendet
  • -XX: + UseStringDeduplication : Java 8u20 hat diesen JVM-Parameter eingeführt, um die unnötige Speichernutzung zu reduzieren, indem zu viele Instanzen derselben Zeichenfolge erstellt werden. Dadurch wird der Heapspeicher optimiert, indem doppelte String- Werte auf ein einziges globales char [] -Arrayreduziert werden
  • -XX: + UseLWPSynchronization : Legt die LWP -basierte Synchronisierungsrichtlinie( Light Weight Process ) anstelle der threadbasierten Synchronisierung fest
  • -XX: LargePageSizeInBytes : setzt die große Seitengröße für den Heap Java verwendet; es nimmt das Argument in GB / MB / KB; Bei größeren Seiten können wir die Hardwareressourcen des virtuellen Speichers besser nutzen. Dies kann jedoch zu größeren Speicherplatzgrößen für das PermGen führen , was wiederum dazu führen kann, dass der Java- Heapspeicherplatz verkleinert wird
  • -XX: MaxHeapFreeRatio: Legt den maximalen Prozentsatz an freiem Heap nach GC fest , um ein Schrumpfen zu vermeiden.
  • -XX: MinHeapFreeRatio: Legt den Mindestprozentsatz an freiem Heap nach GC fest , um eine Erweiterung zu vermeiden. Zur Überwachung der Heap-Nutzung können Sie VisualVM verwenden, das mit JDK geliefert wird.
  • -XX: SurvivorRatio : Verhältnis von Eden / Survivor Space-Größe - Beispiel: -XX: SurvivorRatio = 6 legt das Verhältnis zwischen jedem Survivor Space und Eden Space auf 1: 6 fest.
  • -XX: + UseLargePages : Verwenden Sie einen großen Seitenspeicher, wenn dieser vom System unterstützt wird. Bitte beachten Sie, dass OpenJDK 7 bei Verwendung dieses JVM-Parameters zum Absturz neigt

  • -XX: + UseStringCache : ermöglichtCaching von häufig zugeordneten Strings in dem String - Pool

  • -XX: + UseCompressedStrings : Verwenden Sie einen Byte- Typ [] für String- Objekte, die im reinen ASCII-Format dargestellt werden können
  • -XX: + OptimizeStringConcat : es optimiert String Verkettung Operationendenen möglich

8. Fazit

In diesem kurzen Artikel haben wir einige wichtige JVM-Parameter kennengelernt, mit denen die allgemeine Anwendungsleistung optimiert und verbessert werden kann.

Einige davon können auch zum Debuggen verwendet werden.

Wenn Sie die Referenzparameter genauer untersuchen möchten, können Sie hier beginnen.