Spring MVC на Tomcat PermGen Space постоянно увеличивается

У меня есть веб-приложение, созданное поверх SpringMVC 3.2 и работающее на Tomcat. Я использую VisualVM для наблюдения за пространством permgen и обнаружил, что оно постоянно увеличивается: введите описание изображения здесь

Я беру три дампа кучи и запускаю анализ «Гистограмма загруженных классов ClassLoader» и обнаружил следующие результаты:

свалка в 21:44:

loader:org.springframework.instrument.classloading.tomcat.TomcatInstrumentableClassLoader#1,
count:3285

свалка в 21:55:

loader:org.springframework.instrument.classloading.tomcat.TomcatInstrumentableClassLoader#1,
count:3286

свалка в 7:40:

loader:org.springframework.instrument.classloading.tomcat.TomcatInstrumentableClassLoader#1,
count:3855

Мое приложение очень тихо в этот период. Однако похоже, что количество загруженных классов постоянно увеличивается. Я хочу понять, какие классы загружаются в этот дамп кучи. Запуск «загруженных классов ClassLoader» не дает мне слишком много информации, так как я погружен в эту информацию: введите  описание изображения здесь

У кого-нибудь есть опыт анализа такого рода вопросов?

Обновите информацию о JVM

JVM: Java HotSpot(TM) 64-Bit Server VM (20.45-b01, mixed mode)
Java: version 1.6.0_45, vendor Sun Microsystems Inc.

Аргументы JVM:

-Dvisualvm.id=4226015013703
-Xdebug
-Xrunjdwp:transport=dt_shmem,address=javadebug,suspend=y,server=n
-Dvisualvm.id=4214057282541
-Denv=dev-no-mas
-Dorg.slf4j.simpleLogger.defaultLogLevel=debug
-Dssgateway.disabled=true
-Dcom.sun.management.jmxremote=
-Dcom.sun.management.jmxremote.port=1299
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
-Djava.rmi.server.hostname=127.0.0.1
-Djava.util.logging.config.file=C:\Users\luog.IKARI\.IntelliJIdea13\system\tomcat\Unnamed_rythm_2\conf\logging.properties
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
-Djava.endorsed.dirs=C:\l\j\apache-tomcat-6.0.29\endorsed
-Dcatalina.base=C:\Users\luog.IKARI\.IntelliJIdea13\system\tomcat\Unnamed_rythm_2
-Dcatalina.home=C:\l\j\apache-tomcat-6.0.29
-Djava.io.tmpdir=C:\l\j\apache-tomcat-6.0.29\temp

person Gelin Luo    schedule 29.05.2014    source источник
comment
Вы пробовали включить perm gen gc - XX:+CMSClassUnloadingEnabled?   -  person Boris the Spider    schedule 30.05.2014
comment
Какую JVM вы используете?   -  person acdcjunior    schedule 30.05.2014
comment
Добавлена ​​информация о JVM   -  person Gelin Luo    schedule 30.05.2014
comment
@BoristheSpider, похоже, этот флаг не работает для JDK1.6 в соответствии с этим SO: stackoverflow.com/questions/3717937/   -  person Gelin Luo    schedule 30.05.2014
comment
Вы используете Hibernate? По моему опыту, это обычный подозреваемый в утечке памяти permgen.   -  person Jules    schedule 30.05.2014
comment
Я не использую спящий режим. Я использую MongoTemplate   -  person Gelin Luo    schedule 30.05.2014


Ответы (1)


  • PermGen - это, по сути, куча, которая должна содержать системный объект. Куча для объекта приложения - это обычное пространство кучи.

Общая проблема заключается в том, что каждый класс содержит ссылку на определение класса и каждый загрузчик классов, который его создал, а каждый загрузчик классов содержит ссылку на все классы, которые он создал. Поэтому, когда сборщик мусора перемещается по всем объектам, поскольку у них всегда есть ссылки, они продолжают расти ... и GC не освобождает их. В примере они используют:

$ {JAVA_HOME} / bin / jvisualvm

Это инструмент, который может вам помочь. Решение длинное, а ссылка предоставляет помощь с изображениями. Этот инструмент может помочь вам найти загрузчик классов, вызывающий утечку (Загрузчик классов предназначен для каждого приложения на сервере, чтобы запускать несколько приложений вместе на одном сервере)

Затем вы найдете класс проблемы. Как только вы узнаете, что вызывает проблему, вы сможете ее вылечить.

Это ссылка, которая объяснит, почему это происходит и как бороться:

cdivilly.wordpress.com/2012/04/23/permgen-memory-leak/

Вы можете прочитать эту отличную презентацию .. На странице 11 вы можете увидеть, как вы можете идентифицировать утечки и решения .. Очень Очень полезно http://people.apache.org/~markt/presentations/2010-11-04-Memory-Leaks-60mins.pdf

Надеюсь, что более полезно

person Aviad    schedule 29.05.2014