Утечки памяти в Tomcat и JAXB

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

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

Но все равно ошибка регистрируется. Я видел в презентации Tomcat, что это известная ошибка, потому что JAXBContext.newInstance () создает блокировку JarURLConnection. Очевидно, этого можно избежать, отключив кэширование, но это ничего не сделало для меня.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 [com.sun.xml.bind.v2.ClassFactory$1@6a724da1]) and a value of type [java.util.WeakHashMap] (value [{class my.package.model.layout.Element=java.lang.ref.WeakReference@7646bb9f, class my.package.model.layout.ScriptBeforeFileID=java.lang.ref.WeakReference@1dc80063, class my.package.model.layout.OutputProperty=java.lang.ref.WeakReference@359172db, class my.package.model.layout.Data=java.lang.ref.WeakReference@600ba356, class my.package.model.layout.InputProperty=java.lang.ref.WeakReference@1c10945d, class my.package.model.layout.ToPort=java.lang.ref.WeakReference@47c7410, class my.package.model.layout.ConfigFile=java.lang.ref.WeakReference@6a7c8bd, class my.package.model.layout.LayoutInstanceID=java.lang.ref.WeakReference@716bf3b4, class my.package.model.layout.ScriptAfterFunction=java.lang.ref.WeakReference@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 

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

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