Что можно сделать с исключением PermGen out of space в веб-приложении Tomcat-Spring-Hibernate?

-XX:MaxPermSize действительно работает, вам просто нужно получить правильное значение. По умолчанию, я считаю, что это 32 МБ для виртуальной машины в режиме клиента и 64 МБ для виртуальной машины в режиме сервера. Предлагаю установить 256 МБ, если у вас есть память:

java -XX:MaxPermSize=256m

Проблема возникает из-за того, что Spring и Hibernate могут интенсивно использовать классы, созданные во время выполнения, а иногда и много. Все эти сгенерированные классы попадают в пул памяти PermGen, поэтому, если вы используете эти фреймворки, вам часто нужно увеличивать PermGen до больших объемов.

Вы должны знать, что в некоторых версиях Tomcat возникают утечки памяти при передислокации во время войны. Это случилось со мной на tomcat 6.0.x.

Как было предложено увеличить MaxPermSize, это временное решение для вашей машины разработки - и когда вы получите сообщение об ошибке через 2-3 дня, просто перезапустите сервер. На производстве не все так просто. Таким образом, этот подходит для разработки, но этот подход не работает для производства, где вам следует исправить проблемы с утечкой памяти.

Для обнаружения утечек используйте приложение jconsole, которое поставляется с jdk 1.6 и 1.5. Вы можете выполнить привязку к процессу и наблюдать за использованием памяти с течением времени.

Вы также можете прочитать это:

• http://frankkieviet.blogspot.com/2006/10/classloader-leaks-dreaded-permgen-space.html.
• http://frankkieviet.blogspot.com/2006/10/how-to-fix-dreaded-permgen-space.html
• http://java.sun.com/developer/technicalArticles/J2SE/monitoring/index.html
• http://my.opera.com/karmazilla/blog/2007/03/13/good-riddance-permgen-outofmemoryerror
• http://my.opera.com/karmazilla/blog/2007/03/15/permgen-strikes-back

Я видел эту проблему с Hibernate (используется без Spring). Проблема заключалась в том, что мы создавали экземпляр SessionFactory для каждого пользовательского запроса, а не для создания единственного экземпляра на время существования приложения.

Я использовал профилировщик YourKit, чтобы исследовать это и обнаружить проблему.

Как говорит скаффман, свойство -XX: MaxPermSize действительно работает, однако иногда у вас может возникнуть основная проблема, когда повышение предела может только отложиться.

Вы видели эту заметку? Однажды это помогло мне решить аналогичную проблему. Подведем итог по ссылке:

• Поместите драйвер JDBC в common / lib (как документация tomcat говорит), а не в WEB-INF / lib
• Не помещайте общий журнал в WEB-INF / lib, так как tomcat уже загружает его

Visual GC, теперь часть JDK 6, дает очень красивое графическое представление памяти в реальном времени. Вы можете увидеть, что происходит с райским пространством, пространством поколений и перманентным пространством. Вы просто не поймете почему.

ОБНОВЛЕНИЕ: это bin / jvisualvm.exe в моем дистрибутиве JDK 1.6.0_13. Дайте ему PID процесса, который вы хотите отслеживать.

Все ответы здесь относятся к проблеме PermGen, которая возникает из-за нескольких перезапусков веб-приложения, но в этом случае проблема уже возникает при первом развертывании после перезапуска tomcat, поэтому это не может быть проблемой ссылок ClassLoader или общего журнала.

Если вы работаете на jdk6, вы можете использовать приложение jconsole для отслеживания использования памяти приложением и дальнейшего исследования.

Еще одно направление - использовать профилировщик, я использую JProfiler, и взглянуть на приложение с ним. Он скажет вам, в чем именно заключается проблема.

Я столкнулся с той же проблемой, и у меня

Затем я переключился на причал, и все оказалось отлично, и приложение развертывается / запускается, как ожидалось. Так что, если кот не обязателен, я бы посоветовал Джетти.