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