Warum bekomme ich OutOfMemory, wenn 20% des Heaps noch frei sind?

Question

Ich habe den Max-Heap auf 8 GB gesetzt. Wenn mein Programm etwa 6,4 GB verwendet (wie in VisualVM gemeldet), fängt der Garbage Collector an, den größten Teil der CPU zu verbrauchen, und das Programm stürzt mit OutOfMemory ab, wenn eine Zuweisung von ~ 100 MB vorgenommen wird. Ich verwende Oracle Java 1.7.0_21 unter Windows.

Meine Frage ist, ob es GC-Optionen gibt, die dabei helfen würden. Ich übergebe nichts außer -Xmx8g.

Meine Vermutung ist der Heap wird fragmentiert, aber sollte der GC nicht komprimieren?

Answer 1

Sammeln Stücke von Informationen (die überraschend schwierig ist, da die official documentation ziemlich schlecht ist), habe ich festgestellt habe ...

Generell gibt es zwei Gründe dies passieren kann, im Zusammenhang sowohl zu einer Fragmentierung des freien Raum (dh freier Platz, der in kleinen Teilen existiert, so dass ein großes Objekt nicht zugewiesen werden kann). Erstens führt der Garbage Collector möglicherweise keine Komprimierung durch, was bedeutet, dass der Speicher nicht defragmentiert wird. Selbst ein Sammler, der Kompaktierung macht, mag das nicht ganz gut. Zweitens teilt der Müllsammler typischerweise den Speicherbereich in Regionen auf, die er für verschiedene Arten von Objekten reserviert, und er denkt möglicherweise nicht daran, freien Speicher von der Region zu nehmen, die er der Region geben muss, die ihn benötigt.

Der CMS-Garbage Collector führt keine Komprimierung durch, während die anderen (seriell, parallel, parallelalt und G1) dies tun. Der Standardkollektor in Java 8 ist ParallelOld.

Alle Garbage Collectors teilen Speicher in Regionen, und, AFAIK, alle von ihnen sind zu faul, um sehr schwer zu versuchen, einen OOM-Fehler zu verhindern. Die Befehlszeilenoption -XX:+PrintGCDetails ist für einige Sammler sehr hilfreich, um die Größe der Regionen und den freien Speicherplatz zu zeigen.

Es ist möglich, mit verschiedenen Garbage Collectors und Optimierungsoptionen zu experimentieren. Bezüglich meiner Frage löste der Collector G1 (aktiviert mit dem JVM-Flag -XX:+UseG1GC) das Problem, das ich hatte. Dies war jedoch hauptsächlich auf den Zufall zurückzuführen (in anderen Situationen ist es schneller möglich). Einige der Kollektoren (die Serien, cms und G1) haben umfangreiche Optimierungsoptionen für die Auswahl der Größen der verschiedenen Regionen, damit Sie Zeit damit verschwenden, vergeblich zu versuchen, das Problem zu lösen.

Letztendlich sind die echten Lösungen eher unangenehm. Erstens, installieren Sie mehr RAM. Zweitens, verwenden Sie kleinere Arrays. Drittens ist zu verwenden ByteBuffer.allocateDirect. Direkte Bytepuffer (und ihre int/float/double Wrapper) sind arrayähnliche Objekte mit arrayähnlicher Leistung, die auf dem systemeigenen Heap des Betriebssystems zugewiesen sind. Der Betriebssystem-Heap verwendet die virtuelle Speicherhardware der CPU und ist frei von Fragmentierungsproblemen und kann sogar den Swap-Space der Festplatte effektiv nutzen (wodurch Sie mehr Speicher als verfügbares RAM zuweisen können). Ein großer Nachteil ist jedoch, dass die JVM nicht wirklich weiß, wann direkte Puffer aufgehoben werden sollten, was diese Option für langlebige Objekte wünschenswerter macht. Die letzte, möglicherweise beste und sicherlich unangenehmste Option ist es, zu reservieren und Speicher nativ mit JNI-Aufrufen freizugeben, und es in Java zu verwenden, indem Sie es in eine ByteBuffer umhüllen.

Answer 2

Wahrscheinlich versuchen Sie, eine große Menge zusammenhängender Speicher zuzuordnen, aber der gesamte freie Speicher ist überall in kleinen Teilen. Wenn der Garbage Collector die gesamte Verarbeitungszeit beansprucht, bedeutet das, dass er gerade versucht, die vielleicht 1 oder 2 Objekte in Ihrem gesamten Objektsatz zu finden, die freigegeben werden können. In diesem Fall denke ich, dass Sie daran arbeiten können, Ihre Objekte zu zerlegen, so dass sie nicht so viel kontinuierlichen Speicher benötigen (zumindest nicht alle gleichzeitig).

Edit: So weit ich weiß, gibt es keine Möglichkeit, dass Java den Speicher packen kann, so dass Sie die vollen 8 GB nutzen können, da der Garbage Collector alle anderen Threads pausieren müsste Sie verschieben ihre Objekte, aktualisieren alle Verweise auf diese Objekte, aktualisieren dann veraltete Cache-Einträge und so weiter ... eine sehr, sehr teure Operation.

diese über Memory Fragmentation

Answer 3

Welche Garbage Collector Siehe verwenden Sie? CMS macht keine Verdichtung. Versuchen Sie es mit der neuen G1 garbage collector - das macht etwas Verdichtung.

Für ein bisschen Kontext: die G1 garbage collector oder `Garbage First‘ Kollektor teilt den Haufen in Stücke und nach (Markierung) alle den Müll identifiziert wird ein chunk evakuieren durch Kopieren aller Live-Bits in ein anderer Brocken - so wird Verdichtung erreicht.

beinhalten die Option nutzen zu können, -XX:+UseG1GC

This eine große Erklärung von G1 und Garbage Collection in Java im Allgemeinen gibt.

Answer 4

Immer wenn dieses Problem in der Vergangenheit auftrat, war der tatsächliche freie Speicher viel niedriger als es schien. Sie können die Menge an freiem Speicher drucken, wenn ein OutOfMemoryError auftritt.

Answer 5

-Xmx stellt nur sicher, dass der Heap nicht größer als 8GB ist, gibt aber keine Garantie, dass so viel Speicher tatsächlich zugewiesen wird. Hat Ihr Computer nur 8 GB Arbeitsspeicher?