Einen ausführlichen Artikel findest du hier: http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html und hier: http://java.sun.com/performance/reference/whitepapers/tuning.html . Siehe auch das Beispiel für Eclipse in Eclipse Crash Problem . Ein geeignetes Profiling-Tool ist GCViewer.

  • Der Speicher für die JVM wird regelmäßig durch einen Garbage Collector gereinigt, um nicht benötigte Objekte zu entsorgen und Speicher wieder frei zu geben. (Das Ganze lässt sich vielleicht mit der Bettenverwaltung auf der Intensivstation einer Klinik vergleichen.)
  • Es existieren mehrer GCen, die auf den jeweiligen Einsatzzweck hin optimiert sind.
  • Die Arbeit des GC kostet Rechenzeit und ist deshalb mit Hilfe von Parametern einstellbar; kann sich als plötzliches “Hängen” der Anwendung bemerkbar machen.
  • Der verwaltete Speicher wird eingeteilt in tatsächlich allozierten (also tatsächlich reservierten) und virtuellen Speicher (potentiell zur Nutzung vorgesehenen).
  • Im Speicher der VM unterscheidet man 3 Haupt-Bereiche: Young Generation (kürzlich erzeugte Objekte, werden öfter eingesammelt vom GC, da die Erfahrung zeigt, dass diese auch schneller sterben), Tenured Generation und Permanent Generation (“Meta”-Bereich für Klassentemplates, Classloader, alles was die VM selbst benötigt um Aufgaben zu erfüllen, also Betten für die Nachtschwestern). Young und Tenure Generation gehören zum sogenannten Heap-Speicher, der der Anwendung selbst zur Verfügung steht.
  • GC findet getrennt in YoungGen und TenureGen statt (Minor- bzw. Major-Collections), je größer diese Bereiche sind, desto seltener muss der GC nach toten Objekten suchen, um Speicherplatz frei zu geben.
  • Die JVM kann beim Start mit Hilfe von Parametern “getuned” werden: http://java.sun.com/docs/hotspot/VMOptions.html
    • Aufruf: java -parameter anwendungs-class
    • -Xmx maximale Heapgröße (Virtuell+Reserviert), bsp. -Xmx1024m auf 1024 MB
    • Achtung! Diese Werte haben keinen Einfluss auf PermGen!
    • -Xms Mindest-Heapgröße (immer fest Reserviert)
    • -XX:MaxNewSize=64M max. Größe von YoungGen
    • -XX:NewSize=64M mind. Größe von YoungGen
    • -XX:MaxPermSize=128M max. Größe des PermGen Speichers, oft können auftretende Probleme hiermit gelöst werden, da dieser per default nur 64 M groß ist
  • Für große Anwendungen reichen die default Einstellungen nicht aus.
  • Für große Server:
    • Die default Einstellung (64M) ist oft viel zu klein. Besser soviel wie möglich Speicher zur Verfügung stellen.
    • Wenn man -Xms und -Xmx gleich setzt, erreicht man bessere Performance, da der Aufwand zur Allokation von zusätzlichem Speicher entfällt. Wenn dieser Wert aber unpassend gesetzt ist, kann die VM den Fehler nicht abfangen.
    • Speicher raufsetzten, wenn mehrere Prozessoren beteiligt sind, denn Speicherallokation kann parallelisiert werden.
    • Evntl. auch -XX:MaxNewSize und -XX:NewSize gleich setzen, aber nicht zu klein, bspw. wenn in einem Serveraufruf eine komplexe XML Datei verarbeitet wird oder, wie in Confluence möglich, eine große Excel-Datei geparst und importiert werden muss.
    • Da im Serverbetrieb viele Objekte nur einen Aufruf oder eine Session lang leben und der Lauf des GC im Unterschied zu einer GUI Anwendung von der Latenzzeit des Netwerks verdeckt wird, ist es evntl. sinnvoll (habe es nicht probiert) den YoungGen Bereich kleiner zu setzen (siehe -XX:NewRatio), wenn bekannt ist, dass die einzelnen Threads klein bleiben.
    • Für mehrer Prozessoren probiere den Throughput Collector (-XX:+UseParallelGC)

Weitere Tips (aus der oben genannten Quelle):

  • For most applications the permanent generation is not relevant to garbage collector performance. However, some applications dynamically generate and load many classes. For instance, some implementations of JSPTM pages do this. If necessary, the maximum permanent generation size can be increased with MaxPermSize.
  • Some applications interact with garbage collection by using finalization and weak/soft/phantom references. These features can create performance artifacts at the Java programming language level. An example of this is relying on finalization to close file descriptors, which makes an external resource (descriptors) dependent on garbage collection promptness. Relying on garbage collection to manage resources other than memory is almost always a bad idea.

Beachte auch (siehe http://java.sun.com/performance/reference/whitepapers/tuning.html)
:

Before you start to tune the command line arguments for Java be aware that Sun’s HotSpot™ Java Virtual Machine has incorporated technology to begin to tune itself. This smart tuning is referred to as Ergonomics. Most computers that have at least 2 CPU’s and at least 2 GB of physical memory are considered server-class machines which means that by default the settings are:

  • The -server compiler
  • The -XX:+UseParallelGC parallel (throughput) garbage collector
  • The -Xms initial heap size is 1/64th of the machine’s physical memory
  • The -Xmx maximum heap size is 1/4th of the machine’s physical memory (up to 1 GB max).