Ich führe eine Java-Anwendung mit einer maximalen Heap-Größe von 128 MB (-Xmx128M) aus. Es wird zum erfolgreichen Abschluss ohne OutOfMemoryError oder eine andere nicht behandelte Ausnahme ausgeführt. Daher nehme ich an, dass die tatsächliche Größe des Heapspeichers innerhalb des angegebenen Grenzwerts von 128 MB geblieben ist.
Wenn ich jedoch den Prozess für diese Java-Anwendung beobachte, sehe ich eine maximale Gesamtspeicherauslastung von 4.188.548 KB (~ 4 GB). Dies ist ein Wachstum von mehr als dem 30-fachen der kontrollierten maximalen Größe des Heapspeichers. Obwohl ich weiß, dass dieser Wert den zugewiesenen virtuellen Speicher enthält, der erheblich größer sein kann als der tatsächlich verwendete physische Speicher, wirkt er sich auf harte Grenzen aus, wie sie von Sun Grid Engine auferlegt werden, und ist daher sinnvoll.
Wie genau ist das möglich? Ich verstehe, dass der gesamte von der JVM belegte Speicher ziemlich viel mehr als die Größe des Heapspeichers umfasst, aber ich verstehe nicht, wie mehrere GB zusätzlichen Speicher benötigt werden, als die Anwendung tatsächlich benötigt, um ihre Objekte zu erstellen und ihre Berechnungen durchzuführen .
Ich verwende Sun Java 1.6.0.31 auf einer 64-Bit-RHEL-Linux-Distribution.
Es gibt mehrere Speichersenken neben dem Java-Heap, die von -Xmx gesteuert werden:
ByteBuffers und zugeordnet ByteBuffer
Ohne die Details deines Systems zu kennen, würde ich vermuten, dass etwas verwendetes zugeordnetes ByteBuffers verwendet.
Aber Sie könnten das Problem untersuchen, indem Sie die Ausgabe des Befehls pmap prüfen. Es listet alle Speicherbereiche des Prozesses zusammen mit den Dateinamen auf, denen eine Region zugeordnet ist (wenn die Regionen natürlich zugeordnet sind).