Я запускаю java-приложение с помощью Hibernate и Glassfish Server. Я получаю
java.lang.OutOfMemoryError: PermGen space исключение, если после его развертывания несколько раз.
Я пробовал -XX:MaxPermSize=128M в своих переменных среды, но это не работает.
Это утечка памяти класса загрузчика. Каждый раз, когда вы повторно развертываете приложение, для него создается новый загрузчик классов, и все классы вашего приложения загружаются снова. Это потребляет память в пространстве perm gen.
Старый загрузчик классов и все его загруженные классы должны быть собраны в мусор, иначе вы будете запускаться в пространство PermGen OOME после развертывания несколько раз. Это не работает, если объект, загруженный внешним загрузчиком классов, содержит ссылку на любой объект, загруженный старым загрузчиком классов. Эта статья дает хорошее объяснение проблемы.
Как правило, утечки загрузчика классов трудно анализировать, а иногда трудно исправить. Чтобы узнать, почему старые загрузчики классов не собирают мусор, вам нужно использовать профилировщик. В JProfiler используйте кулачок-ходок, выберите объекты-загрузчики классов Glassfish и используйте представление входящих ссылок, чтобы проверить пути к корням сборщика мусора.
Класс загрузчика класса называется org.apache.servlet.jasper.JasperLoader. Вот скриншот обычной ситуации, где загрузчик классов поддерживается только живыми экземплярами загруженных объектов.
В вашей ситуации вы должны увидеть ссылки из внешних объектов. Другой распространенной причиной утечки загрузчика класса в веб-контейнерах является фоновый поток, который не останавливается. Например, Google Guice имеет такую ошибку в версии 3.0.
(Отказ от ответственности: моя компания разрабатывает JProfiler)
Чтобы решить эту проблему (в linux based os) выполните следующие
1) увеличить память (так что эта проблема не возникает часто) путем настройки "domain.xml" в
/GlassFish/домен/domain1/конфигурации
выполните поиск
<jvm-options>-XX:MaxPermSize=
set it to higher value eg- 198m or 256m
2) убейте процесс стеклянной рыбы, чтобы освободить порт, на котором он работал (, в моем случае это 8686). открытый терминал (в linux based os) и тип -
sudo netstat -npl | grep 8686
это приведет к чему-то вроде.
tcp6 0 0 :::8686 :::* LISTEN 3452/java
следующее использование
kill -9 3452, чтобы убить этот процесс (3452 в этом случае)
Теперь попробуйте запустить старую рыбку, она должна начинаться.
Если вы используете Windows, попробуйте убить процесс Glassfish (java.exe * 32) с помощью Диспетчера задач и перезапустить сервер.
Эта проблема возникает при итеративном развертывании много раз. Я сталкивался с этим много раз. Пожалуйста, обратитесь к приведенной ниже ссылке JIRA для ошибки в стеклянном ящике: