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 (v 



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:

Laufen mit G1GC:

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

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 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! ?