Почему пространство PermGen растет?
Я прочитал несколько статей, и я понял следующее (пожалуйста, исправьте меня и/или отредактируйте вопрос, если я неправ):
Явская куча сегментирована как это:
Молодое Поколение: объекты, которые созданы, идут сюда, эта часть часто и недорого собранный мусор
Старое Поколение: объекты, которые переживают сборки мусора поколения Янга, идут сюда, эта область - мусор, собираемый менее часто и использование большего количества центрального процессора требовательный процесс/алгоритм (я полагаю, что это назвало зачистку отметки),
Править: как указано другим пользователем, PermGen не часть названного региона heap
- PermGen: эта область заполнена из Ваших метаданных классов приложения и многих других вещей, которые не зависят от прикладного использования.
Так, знание этого..., почему делает мое пространство PermGen, растет, когда приложение находится под тяжелым грузом? Поскольку, что я сказал, прежде чем это пространство не должно с приращением заполняться несмотря на груз приложения, но поскольку я сказал в начале, вероятно, что я неправ относительно некоторых предположений.
На самом деле, если пространство PermGen растет, есть ли способ мусора, собирают или перезагружают его?
5 ответов
На самом деле, в постоянном генерировании JVM Sun ( Premgen) полностью отделен от кучи. Вы уверены, что вы не смотрите на поколении в курсе? Это было бы подозрительно, если ваше постоянное поколение продолжало расти.
Если ваш Perm Gen постоянно растет, это сложная область для копания. Как правило, он должен расти, когда новые классы загружаются впервые (и потенциально определенные виды отражения могут также вызвать это). Меженерные струны также хранятся в Перми Gen.
Если вы должны быть на Solaris, вы можете использовать jmap -permstat , чтобы выбросить статистику Пермь, но эта опция не может быть доступна в Windows (и потенциально других платформах). Вот Документация на JMAP для Java 6
из руководства Sun's на JConsole (который позволит вам просмотреть размер этих пулов):
для Hotspot Java VM, память Бассейны для серийного мусора следующие.
- Эдем пространство (куча): пул, из которого память изначально выделена для большинства предметов.
- Выживший пробел (куча): бассейн, содержащий объекты, которые выжили Мусорная коллекция Eden космос.
- Ускоренное поколение (куча): бассейн, содержащий объекты, которые существовали Некоторое время в выжившем пространстве.
- Постоянное поколение (нечета): пул, содержащий все отражающие данные самой виртуальной машины, такие как класс и метод объекты. С Java VMS, который использует совместное использование классов данных, Это поколение разделено на только для чтения и зоны чтения.
- Code Cache (не куча): Hotspot Java VM также включает в себя кеш кода, содержащая память, которая используется для Компиляция и хранение родных код.
Наиболее распространенные причины, которые я видел:
- Custom CloseLoaders, которые не аккуратно освобождают старые занятия после загрузки новых.
- Классы, остающиеся в Permgen после перерасхождения приложения несколько раз (более распространенные в разработке, чем PLOD)
- , тяжелое использование прокси-классов, которые создаются синтетически во время выполнения. Легко создавать новые классы прокси, когда одно определение класса можно повторно использовать для нескольких экземпляров.
Вы делаете что-то фанк с цепочкой классов классов? Вы звоните Стажером () на кучу строк?
Это одна из более раздражающих проблем для отладки. Есть много причин, по которым вы могли видеть растущее использование Prengen. Вот 2 ссылки, которые я нашел очень полезным в понимании того, как происходит утечки, а также отслеживая то, что их вызывает.
http://frankkievivet.blogspot.com/2006/10/how-to-fix-dreaded-permgen-space.html
http://frankkieviet.blogspot.com/2006/10/Classloader-leaks -Мадный Permgen-Space.html
Это очень распространенная проблема, когда вы управляете классовым загрузчиком. Это много видно в приложениях Java EE, когда вы перегреваете Hibernate / CGLIB. Для получения дополнительной информации проверить