Ошибка NetBeans/Glassfish и PermGen при повторном развертывании (да, STILL)

Я знаю, что это, вероятно, было задано много раз раньше, но я до сих пор не видел реального исправления.

Моя повседневная среда разработки выглядит следующим образом:
1. NetBeans (последняя версия), 2. Glassfish (последняя в комплекте с NB), 3. JPA, JSF, JAXB, Jersey для JAX-RS

У меня около 600 классов в моем проекте, которые распространяются на два проекта EJB и один проект WAR, все внутри EAR.

Я нахожусь на последнем JDK 7 (на OS X), и я нахожусь на почасовой основе, получая печально известную ошибку «PermGen space». Предположим, что если я делаю 3 инкрементных повторных развертывания в минуту, я могу работать только на короткое время:

* У Glassfish заканчивается пространство PermGen, поэтому мне просто нужно убить процесс.
* Развертывание становится чрезвычайно медленным, из-за того, что я увеличиваю максимальное пространство перменто (как это рекомендуется делать из десятков ответов на S.O.)

Часто единственным решением является уничтожение стеклянной рыбы каждые 30 минут или около того. Это определенно из-за ошибки где-то, которая просто загружает новые классы для каждого нового инкрементного повторного развертывания вместо того, чтобы избавляться от старых. Я думал, что это должно быть исправлено в JDK 7?

Это была ошибка  *долгое время*  в среде разработки, и я довольно шокирован тем, что она продолжается и после моего 5-летнего развития Java. Это так расстраивает и невероятно непродуктивно.

( **Перед тем, как кто-либо предложит увеличить пространство с пергеном** , поверьте, я пробовал это, и единственное, что он «решает», - это продлить неизбежное. Я видел, что повторные развертывания занимают до 400 секунд худшее. Перераспределение должно занимать 5-6 секунд для проекта такого размера, не более.)

**EDIT**: I ran jmap and jhat on the Glassfish process after the following steps:

1. Запуск стеклянной рыбы
2. Разверните мой советник
3. Развернуть мой советник
4. Затем сделал кучу кучи с jmap

Оказывается, все мои классы (которые должны были быть выгружены) все еще загружены! Надеюсь, это полезная информация для кого-то, кто читает это ...

Конечно, это ошибка, и я не думаю, что для этого есть простое решение. (Если бы это было, возможно, у вас уже было это).

Что вы можете попробовать: используйте  **инструмент замены горячих кодов** , например  `JRebel` . Таким образом, вам не нужно постоянно развертывать, вместо этого этот инструмент отслеживает изменения  `.class`  (и даже другие веб-ресурсы, если вы это настроили), а  *заменяет*  определение класса  *в запущенной JVM* . Звучит круто, правда?

Он работает как агент  *Java* , он запускается при запуске JVM.

Есть три недостатка этого решения: развертывание немного медленнее, его отлаживать сложнее, и это проприетарное программное обеспечение (но не дорого)



При разработке с помощью Netbeans + Glassfish и использовании «Deploy on Save» мы обнаружили, что библиотеки, упакованные в приложение, не разгружаются при повторном развертывании проекта; это заставляет GF замедляться и быстро исчерпать память.

Попробуйте отменить «Пакет» для всех библиотек времени компиляции и поместить те, которые еще не находятся в пути класса Glassfish в каталоге domainX/lib.

Не уверен, но это может быть связано с GLASSFISH-17449 или GLASSFISH-16283.