Warum benutzt die JVM giant int [] aller Nullen?
Ich weiß, dass es einen intrinsischen Overhead der JVM gibt, und ich wollte weitere Nachforschungen anstellen, um genau zu sehen, woraus der Overhead stammt.
Mit dem YourKit-Profiler konnte ich feststellen, dass es riesige int [] gibt, die mit scheinbar zufälligen Informationen gefüllt sind. Meine Vermutung war, dass diese einige Leistungsmetriken und andere Dinge speichern, die die JVM verwendet, um Anwendungen zu optimieren; aber zu meiner Überraschung sind alle Elemente Wert 0 .
Um meine Ergebnisse zu erhalten, habe ich das folgende "do nothing" Programm verwendet, so dass die Ergebnisse nur Dinge enthalten, die auf der JVM passieren.
%Vor%Dies ist ein Screenshot des Profilergebnisses, und ich kann bei Bedarf einen Speicher-Snapshot hochladen.
2 Antworten
Ich habe schon etwas mehr damit herumgespielt und es hat definitiv mit der Größe des Heaps zu tun. Zum Beispiel, wenn ich -Xmx5m -Xmx5m gesetzt habe, ist die int-Array-Zuweisung weg. Wenn ich -Xmx5g -Xms5g einstelle, erzeugt es viel größere Arrays.
Ich frage mich, wofür sie sie benutzen.
Habe Hilfe von / r / java.
"Dies sind wahrscheinlich Füllobjekte in lokalen Thread-Zuweisungs-Puffern, die bei der Parsability von Heap helfen: Ссылка Sie sollten nicht erreichbar sein und von Tools gefiltert werden, die Heap-Dumps analysieren. In Ihrem Screenshot zeigt der Profiler "Alle Objekte (erreichbar und nicht erreichbar)". "
Sie können die Antwort finden, indem Sie die eingehenden Links zu diesen Arrays untersuchen. Klicken Sie einfach mit der rechten Maustaste auf ein erreichbares Array, wählen Sie "Ausgewählte Objekte" und wechseln Sie dann zu "Eingehende Referenzen".
Ich habe festgestellt, dass es Tabellen in sun.util.calendar.ZoneInfo , sun.util.Calendar.BaseCalendar , java.util.Currency usw. gibt.
Es ist schwer zu sagen, aber diese großen nicht erreichbaren Arrays wurden wahrscheinlich von JVM verwendet, um Java-Byte-Code aus .class-Dateien zu laden. JVM benötigt sie nach der Kompilierung nicht, also wurden sie veröffentlicht, aber noch nicht gesammelt.