ClassLoader Leak - стоит ли их решать?

Question

ClassLoader утечки обычно приводят к java.lang.OutOfMemoryError: PermGen .В случае работы на серверах приложений вы можете увидеть это в результате многочисленных повторных развертываний обычного приложения.Объяснение и возможные решения этой проблемы можно увидеть по этим двум ссылкам.(среди прочих)

http://dev.eclipse.org/blogs/memoryanalyzer/2008/05/17/the-unknown-generation-perm/ http://blogs.oracle.com/fkieviet/entry/classloader_leaks_the_dreaded_java

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

В связи с этим возникает два вопроса:

Разумно ли говорить, что для решения такой проблемы лучше просто увеличить максимальный размер перми и перезапустить, где это необходимо, или найти решение с более высоким приоритетом?

Существуют ли более простые способы устранения утечки из загрузчика классов?

Answer 1

Это действительно зависит от приложения, а точнее от используемого процесса развертывания. Многие приложения переопределяются только во время разработки, новые выпуски выпускаются раз в несколько месяцев, а сервер приложений перезапускается по другим причинам гораздо чаще, чем развертывание приложения. В этих условиях погоня за утечками из Classloader является пустой тратой времени.

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

Answer 2

@ Бизиклоп прав. Вы должны быть прагматичными по этому поводу.

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

Если проблема в производственных серверах, вам нужно решение или обходной путь. Решение - тяжелая работа, но обходные пути могут быть меньше работы:

• Обходной путь № 1 - не выполнять горячее развертывание на производственных серверах; делайте только полную передислокацию и перезапуск.

• Обходной путь # 2 - периодически делайте полный перезапуск производственных серверов, чтобы избежать исчерпания пространства permgen. Добавьте к этому увеличение пространства пермгена.

В хорошо обеспеченной ресурсами / хорошо работающей среде вы должны проводить все тестирование на отдельных серверах. Если время простоя полного развертывания вызывает беспокойство, вы должны минимизировать сбои повторного развертывания, используя репликацию сервера и постепенное повторное развертывание. Горячие развертывания в производство должны быть ненужными.

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

Answer 3

Да, есть более простые и правильные способы устранения утечек.Добавьте в свой проект библиотеку ClassLoader Leak Prevention , и она должна решить эту проблему для вас!

Если вы хотите самостоятельно обнаружить утечки, эта серия блогов поможет.

Answer 4

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

• Потоки идут в threadGroups + начальный поток для каждого модуля, чтобы гарантировать, что новые потоки () имеют эту группу.
• Особая забота о Thread.inheritedAccessControlContext (который содержит ссылку на загрузчик классов)
• WeakReferences, когда вам нужно сохранить классы, фактически используйте WeakReferences для слушателей, чтобы никто не мог пропустить отмену регистрации (и использовать только annon. Clasess). Наличие фреймворка для WeakListeners действительно помогает.
• Дополнительный уход за дисками БД, java.security.Provider
• еще несколько хитростей (включая динамическое улучшение файлов классов, но обычно это излишне)

Нижняя строка:

---

утечки - это зло.

Answer 5

Я бы подошел к проблеме прагматично:

1. Это вызывает проблемы в производственной среде?
2. Достаточно ли у вас времени и ресурсов, чтобы его отследить?

Если ответ на оба этих вопроса положительный, то обязательно сделайте это. Если это один «да», один - «нет», то, вероятно, это зависит от руководства, чтобы решить, если оба - нет, не беспокойтесь.