Der Kern der Java-Müllkollektionsabstimmung in Szenarien mit niedriger Latenz besteht darin, die GC-Pausezeit zu verkürzen und h?ufige vollst?ndige GC zu vermeiden. 1. W?hlen Sie einen geeigneten Müllsammler wie ZGC (JDK 11) oder Shenandoah (JDK 8U255 /JDK 15), geeignet für Szenarien mit niedriger Latenz; G1 ist für mittelgro?e Systeme geeignet; ?ltere Versionen von JDK eignen sich nicht für reaktionsempfindliche Dienste. 2. Setzen Sie das Verh?ltnis des Heap -Speichers und der neuen Generation vernünftigerweise, halten Sie den anf?nglichen Haufen mit dem gr??ten Haufen überein und erh?hen Sie den Raum der neuen Generation angemessen. Der Anteil der alten Generation wird empfohlen, 3: 7 zu sein, wie -xms4g -xmx4g -xmn1g. 3. Steuern Sie den Lebenszyklus des Objekts, reduzieren Sie die Erstellung der tempor?ren Objekte und optimieren Sie den Code durch Objektpooling, ThreadLocal und vermeiden Sie das Erstellen von Objekten in Schleifen. 4. überwachen und analysieren Sie GC -Protokolle, aktivieren Sie Parameter wie -xx: printgCDetails und verwenden Sie Tools wie JStat, GCViewer, Prometheus Grafana, um bei der Analyse und Stimmung zu helfen.

Der Kern der Java-Müllkollektionsabstimmung in Szenarien mit niedriger Latenz besteht darin, die GC-Pausezeit zu verkürzen und eine h?ufige Ausl?sen von vollem GC zu vermeiden. Die wichtigsten Punkte sind die Auswahl des richtigen Müllkollektors, die Einstellung der Heap -Speichergr??e und die Steuerung des Objektlebenszyklus.

W?hlen Sie einen Müllsammler, der für niedrige Latenz geeignet ist

Verschiedene Versionen von Java unterstützen verschiedene GC -Strategien. Wenn Sie jedoch eine geringe Latenz verfolgen, ist ZGC oder Shenandoah die erste Wahl. Sie sind alle gleichzeitige Algorithmen zur Kennzeichnung, die die meisten GC -Arbeiten in Millisekunden abschlie?en k?nnen, ohne offensichtliche Pausen zu verursachen.

• ZGC (JDK 11) : Geeignet für Anwendungen mit Heap -Speicher von mehreren hundert MB bis TB, mit einer Pausezeit in der Regel innerhalb von 10 ms.
• Shenandoah (JDK 8U255, JDK 15) : Es konzentriert sich auch auf niedrige Latenz und eignet sich für mittel- und gro?e Heap -Speicheranwendungen.
• G1 (Müll zuerst) : Obwohl es nicht so niedriger Latenz wie die beiden vorherigen ist, führt er stabil und hat eine reiferere Konfiguration in den meisten mittelgro?en Systemen.

Wenn Sie eine alte Version von JDK wie JDK 8 verwenden, ist die Standardeinstellung die parallele serielle alte Kombination. Diese Kombination hat einen hohen Durchsatz, aber eine hohe Latenz und ist nicht für Dienstleistungen geeignet, die für die Reaktionszeit empfindlich sind.

Setzen Sie den Heap -Speicher und das neue Generationsverh?ltnis vernünftigerweise fest

Je gr??er der Heap-Speicher ist, desto besser, insbesondere in Szenarien mit niedriger Latenz. Zu gro? wird der GC l?nger sein, insbesondere wenn der volle GC auftritt, wo die Pausezeit steigen kann.

Empfohlene Praktiken:

• Stellen Sie den anf?nglichen Heap (-xms) und den maximalen Heap (-xmx) auf denselben Wert ein, um die durch dynamischen Kapazit?tserweiterung w?hrend der Laufzeit verursachten Leistungsschwankungen zu vermeiden.
• Erh?hen Sie das Ceponymous (-xmn) angemessen, damit kurzlebige Objekte im Eden-Bereich recycelt werden k?nnen, was die Anzahl der an ?lteren Menschen bef?rderten Objekte verringert.
• Der Anteil ?lterer Menschen wird empfohlen, bei 3: 7 zu bleiben , was bedeutet, dass die neue Generation etwa 30% des gesamten Haufens ausmacht, was entsprechend dem tats?chlichen Objektlebenszyklus angepasst werden kann.

Zum Beispiel: Wenn Ihr JVM -Gesamthaufen auf 4G eingestellt ist, k?nnen Sie -Xms4g -Xmx4g -Xmn1g in Betracht ziehen, damit der Eden -Bereich etwa 600 MB ~ 800 MB haben kann, was ausreicht, um mit den meisten kurzfristigen Objekten umzugehen.

Steuert die H?ufigkeit und den Lebenszyklus der Objekterstellung

Viele Probleme mit geringer Latenz sind eigentlich kein Problem mit GC selbst, sondern dass Programme h?ufig tempor?re Objekte erzeugen, was zu einer h?ufigen Ausl?sen von GC führt. Dieses Problem muss von der Codeebene optimiert werden.

Zu den allgemeinen Praktiken geh?ren:

• Versuchen Sie, Objekte wiederzuverwenden, z. B. Objektpools oder ThreadLocal -Caches.
• Reduzieren Sie unn?tige Verpackungs- und Unboxing -Vorg?nge, um tempor?re Objekte zu vermeiden, die durch automatische Verpackung generiert werden.
• Verwenden Sie WeaPhashMap, um zwischengespeicherte Daten zu verwalten, um die Belegung des Langzeitged?chtnisses zu vermeiden.
• Vermeiden Sie die h?ufige Erstellung von Objekten im Schleifenk?rper.

Das Splei?en des String log.info("user=" user) in der Protokollausgabe generiert beispielsweise jedes Mal ein neues String -Objekt und ersetzt es durch log.info("user={}", user) kann den GC -Druck effektiv reduzieren.

Die überwachung und Analyse von GC -Protokollen sind die Grundlage für das Tuning

Blindes Tuning ohne das Lesen des GC -Protokolls entspricht im Grunde genommen gleichbedeutend mit dem blindigen Raten. Es wird empfohlen, die folgenden Parameter einzuschalten, um GC aufzuzeichnen:

 -Xx: printgcdetails -xx: printgcDatestamps -xloggc: /path/to/gc.log

Einige Tools k?nnen auch verwendet werden, um bei der Analyse zu helfen, z. B.:

• JSTAT : GC -Statistik in Echtzeit anzeigen.
• GCViewer oder GCeasy : Visualisieren Sie die Analyse von Protokolldateien.
• Prometheus Grafana : Wird mit dem JVM -Exporteur zur Implementierung von überwachungsalarmen verwendet.

Mit diesen Methoden k?nnen Sie die Zeit-, Frequenz- und Objektzuweisungsrate jedes GC deutlich sehen, wodurch die Parameter gezielt angepasst werden.

Grunds?tzlich alles ist es. Tuning mit geringer Latenz kann nicht über Nacht erreicht werden. Es erfordert ein umfassendes Urteilsverm?gen, das auf Gesch?ftsmerkmalen, GC -Verhalten und Codeverhalten beruht.

Das obige ist der detaillierte Inhalt vonJava Garbage Collection Tuning für niedrige Latenz. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!