Viele JVMs geben niemals Speicher an das Betriebssystem zurück. Ob dies der Fall ist oder nicht, ist implementierungsspezifisch. Für diejenigen, die dies nicht tun, sind die Speichergrenzen, die beim Start angegeben werden, normalerweise durch das Flag -Xmx, die primären Mittel, um Speicher für andere Anwendungen zu reservieren.
Ich habe Schwierigkeiten, eine Dokumentation zu diesem Thema zu finden, aber die Garbage-Collector-Dokumentation für Sun Java 5 adressiert dies und schlägt vor, dass unter den richtigen Bedingungen der Heap verkleinert wird, wenn der richtige Collector verwendet wird. Wenn mehr als 70% des Heaps frei sind, wird er standardmäßig verkleinert, so dass nur 40% ist gratis. Die Befehlszeilenoptionen, um diese zu steuern, sind -XX:MinHeapFreeRatio und -XX:MaxHeapFreeRatio .
Es gibt mehrere Befehlszeilenoptionen für die JVM, mit denen Sie die Größe des Heapspeichers anpassen können, der von Java verwendet wird. Jeder weiß (oder sollte wissen) über -Xms und -Xmx, die die minimale und die maximale Größe des Heaps festlegen.
Aber es gibt auch -XX: MinHeapFreeRatio und -XX: MaxHeapFreeRatio, welche die jeweiligen Grenzen sind, zwischen denen die JVM freien Speicherplatz verwaltet. Dadurch wird der verwendete Heap verkleinert und der Speicherverbrauch des Programms kann verringert werden.
Weitere Informationen finden Sie hier:
Sie müssen einen JVM-spezifischen Profiler verwenden, um den tatsächlichen Heap-Speicher zu überwachen, der von dem Programm verwendet wird, im Gegensatz zu dem Speicher, der der JVM zugewiesen ist.
Die JVM ist nicht nur bereit, freigegebenen Heap-Speicher freizugeben, sondern neigt dazu, zu verschlingen Platz für verschiedene Gründe, einschließlich Just-in-Time-Kompilierung.
Zeigt das Betriebssystem vielleicht den Speicher an, der dem Programm aktuell zugewiesen ist - Obwohl 150 MB zugewiesen sind, bedeutet das nicht, dass 150 MB verwendet wird.
Tags und Links java memory-leaks garbage-collection memory-management