@biziclop никто не жаловался на качество на самом деле: P, что касается эффективности, я довольно быстрый программист (все же, но время берет свое) ... корпоративные вещи: ну, что угодно

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.

Два вопроса возникают из этого:

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

Есть ли более простые способы устранить утечку загрузчика классов?

 John Vint20 янв. 2011 г., 01:25
@bestsss - это хорошо, я был слишком эмпирическим там.
 bestsss20 янв. 2011 г., 00:51
Между прочим, не связанное с этим, но leaks и java.util.Logger были одним из худших решений, появившихся в java 6.0.18. Это сделало их, удерживаемые WeakReferences, полностью разрушающими большую часть существующего кода.
 bestsss20 янв. 2011 г., 01:22
нет, это не так ... абсолютно невинно выглядящие потоки могут также пропускать загрузчики классов, если вы не будете осторожны.
 CurtainDog20 янв. 2011 г., 01:13
Интересный вопрос ... мне кажется, что утечка загрузчика классов всегда является результатом разной утечки где-то еще в системе (например, нежелательный экземпляр зависает, поэтому его загрузчик классов не может быть собран, и т. Д., И т. Д.). .) Это справедливое заключение?
 John Vint20 янв. 2011 г., 01:19
@CurtainDog Да. Загрузчик классов будет иметь утечку, только если загружаемый класс ограничивает его сборку мусора. По мере того, как статьи заканчиваются, класс сервлета, который создает анонимный внутренний класс одного из классов начальной загрузки, заставит загрузчик классов не собирать мусор.

Ответы на вопрос(5)

Решение Вопроса

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

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

 Michael Borgwardt21 янв. 2011 г., 09:55
@bestsss: так ты подтверждаешь, что тыимеют утечка. На самом деле исправить это может быть как угодно сложнее.
 bestsss20 янв. 2011 г., 20:34
утечки легко остановить на самом деле: гистограмма jmap, и если вы видите 2 раза один и тот же класс, вы знаете, что это утечка. Утечки могут стать серьезной проблемой, если по какой-либо причине какой-либо класс содержит статические ссылки (но не ThreadLocal) на большие структуры, такие как кэш, ByteBuffers и т. Д.
 John Vint20 янв. 2011 г., 15:18
Это была моя позиция, так как мы наблюдали факт утечки. К счастью для этой ситуации, я имею дело с первой из ваших двух ситуаций, поэтому я, вероятно, могу привести аргумент против того, чтобы не разрешить ее в настоящее время.
 bestsss21 янв. 2011 г., 17:46
Оппс Я вижу, куда вы идете от остановки = место. опечатка. не значит исправлять вообще.

@biziclop прав..

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

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

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

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

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

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

есть более простые и правильные способы устранения утечек. ДобавитьБиблиотека предотвращения утечек ClassLoader к вашему проекту, и он должен позаботиться о проблеме для вас!

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

Это вызывает проблемы в производственных условиях?У вас есть достаточно времени и ресурсов, чтобы отследить это?

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

 biziclop20 янв. 2011 г., 01:21
@bestsss Что вам нужно, так это обработка еженедельных встреч о корпоративных ценностях и управлении качеством. Да, и как повысить эффективность.
 bestsss20 янв. 2011 г., 00:54
забавно, я не буду спать по ночам, если знаю, что пропускаю уроки в дикой природе :)
 biziclop20 янв. 2011 г., 01:09
@bestsss Думаю, это называется совесть. Не волнуйтесь, это пройдет через несколько лет. :)
 bestsss20 янв. 2011 г., 01:26
@biziclop никто не жаловался на качество на самом деле: P, что касается эффективности, я довольно быстрый программист (все же, но время берет свое) ... корпоративные вещи: ну, что угодно
 bestsss20 янв. 2011 г., 01:13
@ biziclop: я сомневаюсь ... я программирую, так как мне было 6 (с половиной), это было чертовски много времени, и моя совесть все еще там.

но разрешаю их. Профилирование также помогает. Простых путей как таковых нет, но:

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

Нижняя линия:

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

Ваш ответ на вопрос