Проблемы PermGen с Лифтом и Причалом
Создание неизменных вещей предотвращает большое количество частых ошибок.
, Например, у Студента никогда не должно быть их студенческого изменения # на них. Если Вы не позволяете устанавливать переменную (и делать ее константой или финалом, или безотносительно Ваших поддержек языка) тогда, можно осуществить это во время компиляции.
, Если вещи изменяемы и Вы не хотите, чтобы они изменились, при передаче их вокруг Вас, должен сделать защитную копию, которую Вы передаете. Тогда, если метод/функция, Вы называете изменения копией объекта оригинал, является нетронутым.
неизменные вещи Создания означают, что Вы не должны помнить (или занять время/память) сделать защитные копии.
, Если Вы действительно работаете в нем и думаете о каждой переменной, что делаете, Вы найдете, что подавляющее большинство (у меня обычно есть 90-95%) Ваших переменных, никогда не изменяются, как только им дают значение. Выполнение этого делает программы легче следовать и сокращает количество ошибок.
Для ответа на вопрос на состоянии состояние является значениями, которые имеют переменные "объекта" (быть, что класс или структура). Если бы Вы взяли состояние "объекта" человека, то были бы вещи как цвет глаз, цвет волос, длина волос, и т.д.... некоторые из тех (скажите, что цвет глаз), не изменяются, в то время как другие, такие как длина волос действительно изменяются.
3 ответа
Из это сообщение :
Это исключение произошло по одной простой причине:
перманентное пространство- это место, где свойства класса, такие как методы, поля, аннотации, а также статические переменные и т. д., хранятся в виртуальной машине Java, но особенность этого пространства заключается в том, что его не очищает сборщик мусора. Итак, если ваше веб-приложение использует или создает много классов (я думаю о динамических поколениях классов), скорее всего, вы столкнулись с этой проблемой. Вот несколько решений, которые помогли мне избавиться от этого исключения:
-XX: + CMSClassUnloadingEnabled: этот параметр включает сборку мусора в постоянном пространстве-XX: + CMSPermGenSweepingEnabled: позволяет сборщику мусора выполнять удалить четные классы из памяти-XX: PermSize = 64M -XX: MaxPermSize = 128M: увеличивает объем памяти, выделенной для permgenspace
Может быть, это может помочь.
Редактировать июль 2012 г. ( почти 3 года спустя):
Ондра Жижка комментирует (и я обновил ответ выше):
JVM 1.6.0_27 говорит: Пожалуйста, используйте:
CMSClassUnloadingEnabled(Включена ли выгрузка классов, когда с использованием CMS GC)- вместо
CMSPermGenSweepingEnabledв будущем
См. полные параметры JVM Hotspot - Полная ссылка для mroe.
Список рассылки ( http://groups.google.com/group/liftweb/ ) - это официальный форум поддержки для Lift, где вы сможете чтобы получить лучший ответ. Я не знаю подробностей вашей настройки разработчика (вы не вдавайтесь в подробности), но я предполагаю, что вы перезагружаете свою войну в Jetty, фактически не перезапуская ее. Lift не выполняет генерацию динамических классов (как это было предложено VonC выше), но Scala компилирует каждое закрытие как отдельный класс. Если вы добавляете и удаляете замыкания в своем коде в течение нескольких дней, возможно, что слишком много классов загружается, но никогда не выгружается и занимает постоянное пространство. Я предлагаю вам включить параметры JVM, упомянутые выше VonC, и посмотреть, помогут ли они.
Постоянная генерация - это то место, куда JVM помещает вещи, которые, вероятно, не будут (мусор) собраны, как пользовательские загрузчики классов.
В зависимости от того, что вы развертываете, настройка perm gen может быть низкой. Некоторые комбинации приложений и / или контейнеров действительно содержат некоторые утечки памяти, поэтому, когда приложение не развертывается, иногда некоторые вещи, такие как загрузчики классов, не собираются, что приводит к заполнению пермского пространства, что приводит к возникновению ошибки.
К сожалению, в настоящее время лучший вариант в этом случае - максимально увеличить перманентное пространство с помощью следующего флага jvm (например, для разрешенного размера 192 м):