Sie können über schwierige Probleme mit Speicherlecks in Tomcat (und diese Warnung im Besonderen) lesen unter http://wiki.apache.org/tomcat/MemoryLeakProtection -- insbesondere für die Warnung, die Sie sehen:
Wenn eine Webapplikation einen Thread erstellt, wird dessen Kontext-Classloader standardmäßig auf den des Eltern-Threads (der Thread, der den neuen Thread erstellt hat) gesetzt. In einer Webapp ist dieser übergeordnete Thread einer der Tomcat-Worker-Threads, dessen Kontext-Classloader auf den Webapp-Classloader gesetzt wird, wenn er Webapp-Code ausführt.
Darüber hinaus kann der gespawnte Thread einen Code ausführen (oder darin blockiert sein), der von der Webapp geladene Klassen beinhaltet, wodurch verhindert wird, dass der Classloader der Webapp gesammelt wird.
Wenn also der gespawnte Thread nicht ordnungsgemäß beendet wird, wenn die Anwendung gestoppt wird, wird der Webapp-Klassenlader aufgrund der starken Referenz, die der gespawnte Thread hält, undicht.
Meiner Erfahrung nach wirkt sich dies nur begrenzt aus, wenn Sie Ihre Webanwendung einmal starten und dann einfach wieder abbauen. In einigen Fällen jedoch, z. B. in einem kontinuierlichen Integrationsszenario (in dem Ihr CI-Server wiederholt Builds Ihrer Anwendung in einem Tomcat-Container bereitstellt, der nicht neu gestartet wird), kann der Speicher in der JVM schnell erschöpft sein. Dies äußert sich schließlich in einem OutOfMemoryException in Ihrer PermGen-Region (vorausgesetzt, Sie verwenden die Sun/Oracle JVM). Weitere Einzelheiten zu PermGen finden Sie unter http://blogs.oracle.com/fkieviet/entry/classloader_leaks_the_dreaded_java
