Der in diesem Artikel referenzierte Code stammt aus Beispielcode, der im Oracle-Blog zu Epsilon GC verfügbar ist.
In diesem Artikel untersuchen wir eine besonders interessante Option in der Java Garbage Collection (GC), bekannt als Epsilon GC. Dieser Garbage-Collection-Algorithmus zeichnet sich durch seine Besonderheit aus: Er führt keine Garbage Collection durch. Der Epsilon Garbage Collector (GC) war in JDK 11 enthalten.
Aber was nützt ein Garbage Collector, wenn er nicht sammelt? (Trittbrettfahrer huh!!)
Nein, es ist tatsächlich ziemlich nützlich, ein solcher Anwendungsfall, wie er vom Oracle-Blog bereitgestellt wird, den ich leicht verbessert habe, um hilfreicher zu sein.
Weitere Details finden Sie im Original-Blogbeitrag:
https://blogs.oracle.com/javamagazine/post/epsilon-the-jdks-do-nothing-garbage-collector
Der Anwendungsfall: Epsilon GC ist von Vorteil für Entwickler, die die Speicherzuteilung für ein bestimmtes Codesegment ohne die Hilfe eines Profiling-Tools bewerten müssen.
Primäre Herausforderung Herkömmliche Garbage Collectors können durch kontinuierliches Löschen von Objekten genaue Speichernutzungsmetriken verschleiern. Diese Störung macht es schwierig, den tatsächlichen Speicherverbrauch Ihres Codes zu ermitteln.
Epsilon GC geht dieses Problem an, indem es als Nicht-Kollektor fungiert. Obwohl er per se kein Garbage-Collection-Algorithmus ist, dient er als Werkzeug zum Verständnis der Speicherzuordnung, indem er auf die Durchführung jeglicher Garbage-Collection verzichtet und so ein klares Bild der Speichernutzung liefert.
Hinweis: Es ist wichtig zu beachten, dass eine übermäßige Zuweisung zu einem OutOfMemoryError (OOM) in der JVM führen kann, da Epsilon GC keinen Speicher zurückfordert.
Unten finden Sie den Beispielcode, der verwendet wird, um die Wirksamkeit von Epsilon GC zu demonstrieren:
public class EpsilonDemo { public static String formatSize(long v) { if (v < 1024) return v + " B"; int z = (63 - Long.numberOfLeadingZeros(v)) / 10; return String.format("%.1f %sB", (double)v / (1L << (z*10)), " KMGTPE".charAt(z)); } public static void printmem(){ System.out.println("*** Free MEM = "+formatSize(Runtime.getRuntime().freeMemory())); } public static void main(String[] args) { final int MEGAABYTE = 1024 * 1024; final int ITERATIONS = 80; System.out.println("Starting allocations..."); printmem(); // allocate memory 1MB at a time for (int i = 0; i < ITERATIONS; i++) { var array = new byte[MEGAABYTE]; } System.out.println("Completed successfully"); printmem(); } }
Erwartung:
Der Code weist 80 MB Byte-Objekte zu. Dasselbe sollten wir auch bei den print-Anweisungen beobachten können, wenn wir den Code ausführen.
Jetzt die kompilierte Version mit/ohne EpsilonGC ausführen:
java -Xms100m -Xmx100m -XX:+UseG1GC EpsilonDemo Starting allocations... *** Free MEM = 102.2 MB Completed successfully *** Free MEM = 74.2 MB
Bei G1GC sehen wir also ein falsches Zuordnungsbild der 28-MB-Auslastung
java -Xms100m -Xmx100m -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC EpsilonDemo [0.004s][warning][gc,init] Consider enabling -XX:+AlwaysPreTouch to avoid memory commit hiccups Starting allocations... *** Free MEM = 99.4 MB Completed successfully *** Free MEM = 18.7 MB
Hier sieht man deutlich die Auslastung von 80,7 MB
Ich hoffe, dies hilft Ihnen zu verstehen, wie EpsilonGC sehr praktisch sein kann, um Speichernutzungsmuster in Ihrem Code zu erkennen. Prost! ?
Das obige ist der detaillierte Inhalt vonVerwenden von Java EpsilonGC zur Betrachtung der Speicherzuordnung.. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!