2012-04-12 2 views
2

Я столкнулся с проблемой в своем веб-приложении, которое использует Spring + Hibernate.java.lang.OutOfMemoryError: верхний предел GC превышен Spring Hibernate Tomcat 6

Я случайно получаю ошибку

java.lang.OutOfMemoryError: GC предела накладных расходов превысил

, когда веб-приложение работает в коте

Я пытался получить дамп кучи и сделал анализ дампа кучи Использование Eclipse MAT

Вот мои выводы

объектов org.hibernate.impl.SessionFactoryObjectFac tory содержит 86% памяти, экземпляр Fashhashmap этого объекта содержит более 100000 Hashmaps. Внутри каждого Hashmap есть экземпляр org.hibernate.impl.SessionFactoryImpl, кажется org.hibernate.impl.SessionFactoryImpl загружается несколько раз и хранится внутри org.hibernate.impl.SessionFactoryObjectFactory «s Fashhashmap

Может кто-то поможет мне найти основную причину этой проблемы и предложить какое-то решение, чтобы исправить это.

+2

Можете ли вы показать нам, как настроить Hibernate это весной, как вы управляете транзакциями и каким-то примером запроса Hibernate? Может быть анонимным. –

ответ

1

Ну, даже если вы получаете это SessionFactoryObjectFactory holds 86% of the memory, это не кажется причиной для меня. Прежде всего, прежде чем полагаться на любой инструмент анализа памяти, мы должны сначала понять, как этот инструмент предсказывает проблемы outofmemory. Инструменты памяти просто пытаются захватить мгновенные HIKES, которые отображаются в приложении после запуска этого инструмента. Я уверен, что вы получите одни и те же журналы ошибок, но с разными причинами, упомянутыми инструментом, Catalina web class loader обращается к большому объему памяти, что очевидно и ожидается.

Так что я просто хочу понять, что вместо того, чтобы полагаться на любые такие инструменты (которые могут быть в порядке, в частности, случаи/реализации), вы пытаетесь выкопать исходный код своего приложения и попытаться найти, где находятся ненужные временные объекты создано.

Для цели отладки вы можете включить опцию JVM - -XX:-PrintGCDetails, чтобы посмотреть, что именно собирает GC.

Посмотреть эти сообщения/ссылки для получения дополнительной информации - http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html#Options java.lang.OutOfMemoryError: GC overhead limit exceeded

0

Ну ваш GC нить тратит 98% или больше процессорного времени, пытаясь очистить объекты.

Идея шаблона Factory заключается в том, чтобы возвращать ненулевой экземпляр объекта, который вы хотите создать, что обычно делается путем возврата того же экземпляра, как только он был создан.

Теперь возможно, что у вас есть 100 000 различных сеансов или что-то еще, но я сомневаюсь, что это правильно, поэтому вам нужно проверить свой код, чтобы убедиться, что вызовы метода Factory не работают правильно и, вероятно, без локальной копии кэшируются.

Если у вас действительно есть 100 000 сеансов, взгляните на методы, которые их создают. Разрыв длинных методов вверх, чтобы циклы и структуры были разделены вызовами метода, так что локальные переменные метода можно было очистить один раз из области видимости.

Также убедитесь, что эти более мелкие методы не являются окончательными, поскольку компилятор будет сшивать окончательные методы вместе в единый стек кадров в качестве метода оптимизации.

Смежные вопросы