Ścigam to już od kilku dni. Używamy JAXB, implementacji słońca, w naszej aplikacji. Podczas zatrzymywania Tomcata (6 lub 7) w pliku dziennika catalina rejestruje się poważny wyciek pamięci zawierający wszystkie klasy JAXB, które mamy w naszej aplikacji, dwa zestawy w dwóch różnych pakietach.

Przeglądałem wiele linków Google i Stack Overflow. Użyłem JProfilera, który pokazuje mi, że Tomcat trzyma Enumy, gdy nie są używane, ale to nie powinno być problemem. Wszystkie instancje marshallera lub unmarshallera są tworzone lokalnie i ustawione na null dla agresywnego GC. Zapewniam, że JAXBcontext ma wartość null, gdy serwlety są niszczone, a także w moim kontekście Zniszczony uruchamiam System.gc (); jak zasugerowano, aby uniknąć błędu.

Ale nadal błąd jest rejestrowany. Widziałem w prezentacji Tomcata, że ​​jest to znany błąd, ponieważ blokada JarURLConnection jest tworzona przez JAXBContext.newInstance (), najwyraźniej można tego uniknąć, wyłączając buforowanie, ale to nic nie zrobiło.http://people.apache.org/~markt/presentations/2010-11-04-Memory-Leaks-60mins.pdf

Wszelkie inne sugestie dotyczące sposobu usunięcia tego wycieku pamięci w JAXB uruchomionym na Tomcat.

To jest dziennik błędów:

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