Подтвердить что ты не робот

Что это за предупреждения в каталинии?

У меня есть веб-приложение в Tomcat 7.
Когда я закрываю Tomcat, я вижу это предупреждение (но не всегда)

SEVERE: The web application [/MyApplication] created a ThreadLocal
with key of type
[org.apache.xml.security.algorithms.MessageDigestAlgorithm$1] (value
[[email protected]2e2c])
and a value of type [java.util.HashMap] (value
[{http://www.w3.org/2000/09/xmldsig#sha1=MESSAGE DIGEST SHA-1}]) but
failed to remove it when the web application was stopped. Threads are
going to be renewed over time to try and avoid a probable memory leak.
Apr 3, 2012 1:56:19 PM org.apache.catalina.loader.WebappClassLoader
checkThreadLocalMapForLeaks   SEVERE: The web application
[/MyApplication] created a ThreadLocal with key of type
[com.sun.xml.bind.v2.ClassFactory$1] (value
[[email protected]]) and a value of type
[java.util.WeakHashMap] (value [{class
[email protected]b17eb,
class
javax.xml.bind.a[email protected]178a178a,
class
[email protected]1c181c,
class
c[email protected]17711771,
class
c[email protected]17011701}])
but failed to remove it when the web application was stopped. Threads
are going to be renewed over time to try and avoid a probable memory
leak.   Apr 3, 2012 1:56:19 PM
org.apache.catalina.loader.WebappClassLoader
checkThreadLocalMapForLeaks   SEVERE: The web application
[/MyApplication] created a ThreadLocal with key of type
[org.apache.xml.security.utils.UnsyncBufferedOutputStream$1] (value
[[email protected]a90])
and a value of type [byte[]] (value [[[email protected]]) but failed to
remove it when the web application was stopped. Threads are going to
be renewed over time to try and avoid a probable memory leak.  

Что означают эти предупреждения в каталинии. on shutdown?
Я вижу некоторые из упомянутых мной классов JAXB, но не могу сказать, в чем проблема.

Любая помощь пожалуйста?

4b9b3361

Ответ 1

У вас есть один или несколько утечек памяти в приложении. Для полного объяснения того, почему это происходит, какие из них являются вашей виной, и что вы можете сделать, чтобы исправить их, см. Эту презентацию: http://people.apache.org/~markt/presentations/2010-11-04-Memory-Leaks-60mins.pdf

Ответ 2

Вкратце, некоторые ThreadLocals не были очищены должным образом. Большинство (если не все) J2EE-серверов/Контейнеры приложений используют пулы потоков для входящих запросов и других задач, чтобы предотвратить накладные расходы на запуск новых потоков все время. Проблема в том, что некоторые библиотеки (а вы сами, если не знаете лучше) не очищают свои ThreadLocals после завершения выполнения задачи/запроса.

Обычно, когда поток умирает в конце выполнения, объекты, хранящиеся в ThreadLocals, больше не ссылаются, и сборщик мусора заботится об удалении таких объектов:

Каждый поток содержит неявную ссылку на свою копию локального потока переменная, пока поток жив, и экземпляр ThreadLocal доступный; после того, как поток исчезнет, ​​все его копии поточно-локальные экземпляры подлежат сборке мусора (если только другие ссылки на эти копии существуют).

Но когда поток был извлечен из пула потоков, он не умирает, а возвращается в пул. Поскольку поток все еще жив, так называемые ThreadLocals. Это проявляется как утечка памяти и "утечка" значений из одного запроса другому, когда используется один и тот же ThreadLocal, и поток, обрабатывающий запрос/задачу, использовался раньше.

Ответ 3

Как минимум одно из сообщений JAXB связано с известной ошибкой:

org.apache.catalina.loader.WebappClassLoader checkThreadLocalMapForLeaks SEVERE: веб-приложение [/MyApplication] создал ThreadLocal с ключом типа [com.sun.xml.bind.v2.ClassFactory $1] (значение [[email protected]]) и значение типа [Java.util.WeakHashMap]

См. JAXB-563 и JAXB-831 ( NB - они находятся на java.net и требуют авторизации для просмотра). Первая ошибка была предположительно исправлена, но, как прокомментировали другие, это не полностью исправлено. У второй ошибки есть способ обхода, который должен вызвать gc(), прежде чем разрешить отключение контекста, которое смягчит проблему (хотя и не устранить ее полностью). Вы можете использовать пользовательский ServletContextListener и просто вызвать System.gc() в contextDestroyed().

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