Java optimieren

Kapitel 7. Erweiterte Speicherbereinigung

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Im letzten Kapitel haben wir die grundlegende Theorie der Java Speicherbereinigung vorgestellt. Von aus werden wir nun die Theorie der modernen Java Speicherbereinigungen vorstellen. In diesem Bereich gibt es unvermeidliche Kompromisse, die den Ingenieur bei der Wahl des Kollektors leiten.

Zunächst stellen wir die anderen Collectors vor, die die HotSpot JVM zur Verfügung stellt, wie z.B. den ultra low-pause, mostly concurrent collector (CMS) und den modernen general-purpose collector (G1).

Wir werden auch einige eher seltene Sammler betrachten. Diese sind:

• Shenandoah

• C4

• Ausgewogene

• Ältere HotSpot-Kollektoren

Nicht alle diese Kollektoren werden in der virtuellen Maschine HotSpot verwendet - wir werden auch die Kollektoren von zwei anderen virtuellen Maschinen besprechen: IBM J9 (eine ehemals Closed-Source-JVM, die IBM gerade öffnet) und Azul Zing (eine proprietäre JVM). Wir haben diese beiden VMs bereits in "Meet the JVMs" vorgestellt .

Kompromisse und steckbare Kollektoren

Ein Aspekt der Java-Plattform, der Anfängern nicht immer sofort auffällt, ist, dass Java zwar über einen Garbage Collector verfügt, die Sprach- und VM-Spezifikationen aber nicht vorschreiben, wie der GC implementiert werden soll.Es gab sogar schon Java-Implementierungen (z.B. Lego Mindstorms), die überhaupt keinen GC implementiert ...