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 im Oracle-Blog bereitgestellt wird und den ich leicht verbessert habe, um hilfreicher zu sein.
Weitere Informationen 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 Interferenz 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 (vErwartung:
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:
- Laufen mit G1GC:
java -Xms100m -Xmx100m -XX: UseG1GC EpsilonDemo Starting allocations... *** Free MEM = 102.2 MB Completed successfully *** Free MEM = 74.2 MBBei G1GC sehen wir also ein falsches Zuordnungsbild der 28-MB-Auslastung
- Laufen mit EpsilonGC:
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 MBHier 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! ?
Haftungsausschluss: Alle bereitgestellten Ressourcen stammen teilweise aus dem Internet. Wenn eine Verletzung Ihres Urheberrechts oder anderer Rechte und Interessen vorliegt, erläutern Sie bitte die detaillierten Gründe und legen Sie einen Nachweis des Urheberrechts oder Ihrer Rechte und Interessen vor und senden Sie ihn dann an die E-Mail-Adresse: [email protected] Wir werden die Angelegenheit so schnell wie möglich für Sie erledigen.
Copyright© 2022 湘ICP备2022001581号-3