Warum wächst PermGen?

Ich habe ein paar Artikel, und ich Verstand Folgendes (bitte korrigieren Sie mich und/oder Bearbeiten Sie die Frage, wenn ich falsch Liege):

Den java-heap aufgeteilt ist wie diese:

  • Junge Generation: die Objekte, die erstellt werden, gehen Sie hier, dieses Teil ist Häufig und kostengünstig Müll gesammelt
  • Alten Generation: Objekte, die das überleben der garbage Collection der Jungen generation gehen hier, diesem Bereich ist die garbage Collection weniger Häufig und mit mehr CPU-anspruchsvollen Verfahren/Algorithmus (ich glaube er heißt mark-sweep)

Edit: wie bereits von einem anderen Benutzer, der PermGen ist nicht ein Teil der region genannt heap

  • PermGen: dieser Bereich gefüllt ist der app-Klassen, Metadaten und viele andere Dinge, die nicht abhängig von der Anwendung.

So, dies zu wissen... warum tut mein PermGen space wächst, wenn die app ist unter der schweren Last? Für das, was ich sagte, bevor dieser Raum sollte nicht inkrementell zu füllen, trotz der app laden, aber wie ich am Anfang gesagt habe bin ich wahrscheinlich falsch über einige Annahmen.

In der Tat, wenn die PermGen space wächst, gibt es eine Möglichkeit, Müll zu sammeln oder es zurücksetzen?

InformationsquelleAutor der Frage Pablo Fernandez | 2010-01-12

  1. 19

    Tatsächlich, in der Sun JVM Permanent Generation (PermGen) ist völlig getrennt vom heap. Sind Sie sicher, dass Sie sind nicht auf der Suche an der Pragmatisierte Generation? Es wäre in der Tat verdächtig, wenn Sie Ihren Ständigen Generation sind gewachsen.

    Wenn Ihr perm gen wächst ständig, es ist ein schwieriges Gebiet zu Graben, in. In der Regel sollte es wachsen, wenn neue Klassen geladen werden, die für die erste Zeit (und potenziell bestimmte Verwendungen der Reflexion kann auch dazu führen, diese). Interniert strings werden ebenfalls gespeichert, in perm gen.

    Wenn Sie zufällig auf Solaris, könnten Sie jmap -permstat dump aus perm gen Statistiken, aber diese option scheint nicht verfügbar zu sein, die auf Windows (und möglicherweise andere Plattformen). Hier ist die Dokumentation auf jmap für Java 6

    Aus Sonne Handbuch auf JConsole (mit denen Sie die Größe dieser pools):

    Für die HotSpot-Java-VM der Speicher
    pools für die serielle garbage collection
    sind die folgenden.

    • Eden Raum (heap): Der pool, aus dem Speicher wird zunächst zugeordnet
      für die meisten Objekte.
    • Survivor Space (heap): Der pool enthält Objekte, die überlebt haben
      die garbage collection von Eden
      Raum.
    • Pragmatisierte Generation (heap): Der pool enthält Objekte, die Bestand haben
      für einige Zeit in den survivor space.
    • Permanent Generation (non-heap): Der pool enthält alle reflektierenden
      Daten von der virtuellen Maschine selbst,
      wie class und method-Objekte. Mit
      Java-VMs, die Klasse data sharing,
      diese generation ist unterteilt in
      read-only und read-write Bereiche.
    • - Code-Cache (non-heap): Der HotSpot Java VM enthält auch einen code cache,
      mit Speicher für
      Erhebung und Speicherung von native
      code.

    InformationsquelleAutor der Antwort Joshua McKinnon

  2. 6

    Den häufigsten Ursachen, die ich gesehen habe sind:

    • Benutzerdefinierte classloadern, die nicht gezielt frei älteren Klassen nach dem laden der neuen.
    • Klassen noch in der PermGen nach der Versetzung von einer Anwendung mehrere Male (häufiger in Dev als Prod)
    • Die starke Nutzung von Proxy-Klassen, die synthetisch erstellt während der Laufzeit. Es ist ganz einfach erstellen Sie neue Proxy-Klassen wenn eine Klasse definition könnte wiederverwendet werden, um mehrere Instanzen.

    InformationsquelleAutor der Antwort John Stauffer

  3. 6

    Dies ist eines der lästigen Probleme zu Debuggen. Es gibt eine Menge Gründe, Sie konnte sehen, wächst der permgen verwenden. Hier sind 2 links fand ich sehr nützlich, sowohl zu verstehen, wie Lecks passieren, sowie das aufspüren, was die Ursache Sie.

    http://frankkieviet.blogspot.com/2006/10/how-to-fix-dreaded-permgen-space.html

    http://frankkieviet.blogspot.com/2006/10/classloader-leaks-dreaded-permgen-space.html

    InformationsquelleAutor der Antwort Jason Stelzer

  4. 2

    Tun Sie etwas funky mit dem classloader Kette? Rufen Sie intern() auf eine Reihe von Zeichenfolgen?

    InformationsquelleAutor der Antwort Jonathan Feinberg

  5. 2

    Wenn Sie die Arbeit mit Java EE-Anwendung, ist es wahrscheinlich eine classloader-Leck.

    finden Sie vielleicht die folgenden weiterführenden links nützlich sein:

    http://www.zeroturnaround.com/blog/rjc201/

    http://www.ibm.com/developerworks/java/library/j-dclp3/index.html

    InformationsquelleAutor der Antwort Sajid

  6. 0

    Den häufigsten Ursachen, die ich gesehen habe sind:

    1. Java-Klassen geladen werden
    2. JAXBContext.newInstance
    3. String.Praktikant (in)

    InformationsquelleAutor der Antwort stones333

  7. 0

    Dies ist ein sehr häufiges problem, wenn Sie so manipulieren, dass der classloader. Das ist viel gesehen in Java EE-Anwendungen, wenn Sie die Versetzung von hibernate/cglib. Für mehr info check out

    http://opensource.atlassian.com/confluence/spring/display/DISC/Memory+leak+-+classloader+won%27t+let+go

    InformationsquelleAutor der Antwort Jim Mitchener

Schreibe einen Kommentar