Различные варианты для решения проблем PermGen
Я изучаю различные варианты вокруг сборки "мусора" на Java 6 18 VM и хотел бы некоторые указатели.
Мы запускаем наше приложение на JBoss, и иногда существуют печально известные ошибки PermGen во время, повторно развертывается. Существует большой конфликт и устаревшая информация в Интернете о лучшем способе решить или смягчить эту проблему.
Из того, что я вижу, следующее корректно:
- Опции VM самостоятельно не решат этот вопрос, только отложат его.
- Единственный надежный способ решить эту проблему состоит в том, чтобы зафиксировать ошибки кодирования или в самом Сервере приложений (вряд ли) или в коде (наш код или сторонние библиотеки), который работает в Сервере приложений (более вероятно). Заполнение Permgen часто является результатом ссылок от объектов, загруженных приложением classloader к объектам, загруженным Сервером приложений classloader, таким образом предотвращая сборку "мусора" classloader приложения.
У меня есть два вопроса, следующие из этого:
- Вышеупомянутое корректно?
- Где делают опции VM
CMSClassUnloadingEnabledиCMSPermGenSweepingEnabledвошедший это? Из того, что я вижуCMSClassUnloadingEnabledзаменяет или неявно включаетCMSPermGenSweepingEnabled. Любой из них помогает с вышеупомянутой проблемой?
2 ответа
К сожалению, ответы таковы:
- Да
- Эти варианты VM только отсрочат проблему.
Основная проблема заключается в том, что GC не будет собирать мусор в сильно достижимый объект. Вам нужно выяснить, почему эти старые загрузчики классов приложений все еще доступны после передислокации... и устранить утечку.
Как вариант, откажитесь от горячей передислокации на производственных серверах или чаще перезапускайте веб-контейнер (например, JBoss).
Долгое, но хорошее чтение: http://victor-jan.blogspot.com/2010/05/classloader-leaks-dreaded.html Короче говоря, это разрешимо. Непросто, но решаемо.