2013-09-17 3 views
7

Я преследовал это в течение нескольких дней. Мы используем JAXB, воплощение солнца, в нашем приложении. При остановке Tomcat (6 или 7) в файле журнала каталогов регистрируется серьезная утечка памяти, в которой перечислены все классы JAXB, которые у нас есть в нашем приложении, два набора в двух разных пакетах.Утечки памяти Tomcat и JAXB

Я прошел через множество ссылок переполнения google и Stack. Я использовал JProfiler, который показывает мне, что Tomcat держится за Enums, когда они не используются, но это не должно быть проблемой. Все экземпляры marshaller или unmarshaller создаются локально и устанавливаются в null для агрессивного GC. Я гарантирую, что JAXBcontext имеет значение NULL, когда сервлеты уничтожаются, а также в моем контекстеDestroyed Я запускаю System.gc(); как было предложено избежать ошибки.

Но все же ошибка регистрируется. Я видел в презентации Tomcat, что это известная ошибка, поскольку JarURLConnection блокируется JAXBContext.newInstance(), очевидно, этого можно избежать, отключив кэширование, но это ничего не сделало для меня. http://people.apache.org/~markt/presentations/2010-11-04-Memory-Leaks-60mins.pdf

Любые другие предложения относительно того, как исправить эту утечку памяти в JAXB, работающем на Tomcat.

Это журнал ошибок:

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]bb9f, class my.pack[email protected]1dc80063, class my.[email protected]359172db, class [email protected]6, class my[email protected]1c10945d, class [email protected]10, class [email protected]a7c8bd, class my.pa[email protected]716bf3b4, class my.packa[email protected]664ce898, class be.securit.trustbuilder.config.model.........}]) 
    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. 
     17-sep-2013 15:21:45 org.apache.catalina.loader.WebappClassLoader checkThreadLocalMapForLeaks 

ответ

11

После возвращения через все различные посты я заметил упоминание о размещении JAXB LIB в общий Lib в Tomcat. Поэтому я удалил jaxb-impl-x.x.x.jar из своих приложений WEB-INF/lib и поместил его в [TomcatHome]/lib. Теперь все работает прекрасно. Не уверен, что это лучше всего, потому что теперь при установке под Tomcat должен быть другой метод.

+0

Не работает для меня. Не могу понять, как движущаяся банка будет работать, так как они все равно загружаются одинаково ... –

+1

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

+0

Перемещение банки в систему. Путь Tomcat не исправляет ошибку в 'jaxb-impl'. ** Багги-библиотека по-прежнему забывает очищать локальные переменные потока **. Код проверки Tomcat предупреждает, только если ссылка объекта на загрузчик классов веб-приложений, если 'jaxb-impl' в ссылке' $ CATALINA_HOME/lib' приводит к загрузчику системного класса. – gavenkoa

4

У меня была очень похожая проблема. Утечка осуществлялась при реализации метода контекста jaxb:

StringWriter writer = new StringWriter(200); 
JAXBContext context = JAXBContext.newInstance(objectClass); 
Marshaller marshaller = context.createMarshaller(); 
marshaller.marshal(object, writer); 

Этот код создает новый экземпляр при каждом запросе веб-сервиса.

см. Это Memory leak in webservices with JAXB

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