Tomcat Guice / JDBC Speicherverlust

Ich nur befasste sich mit diesem problem selber. Im Gegensatz zu einigen anderen Antworten, die ich nicht empfehlen Erteilung der t.stop() Befehl. Diese Methode ist veraltet, und das aus gutem Grund. Referenz Oracle ' s Gründendies zu tun.

Aber es ist eine Lösung für die Beseitigung dieser Fehler ohne Rückgriff auf die t.stop()...

Können Sie die meisten der code @Oso zur Verfügung gestellt, ersetzen Sie einfach den folgenden Abschnitt

Set<Thread> threadSet = Thread.getAllStackTraces().keySet();
Thread[] threadArray = threadSet.toArray(new Thread[threadSet.size()]);
for(Thread t:threadArray) {
    if(t.getName().contains("Abandoned connection cleanup thread")) {
        synchronized(t) {
            t.stop(); //don't complain, it works
        }
    }
}

Ersetzen Sie es mit der folgenden Methode zur Verfügung gestellt von der MySQL-Treiber:

try {
    AbandonedConnectionCleanupThread.shutdown();
} catch (InterruptedException e) {
    logger.warn("SEVERE problem cleaning up: " + e.getMessage());
    e.printStackTrace();
}

Dieser sollte ordnungsgemäß Herunterfahren der thread, und der Fehler sollte Weg gehen.

InformationsquelleAutor der Antwort Bill

Ist die am wenigsten invasive Problemumgehung ist, zu zwingen, die Initialisierung des MySQL-JDBC-Treiber, die von code außerhalb des webapp-classloader.

In tomcat/conf/server.xml ändern Sie (in der Server-element):

<Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" />

zu

<Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener"
          classesToInitialize="com.mysql.jdbc.NonRegisteringDriver" />

Dies setzt Voraus, Sie setzen die MySQL-JDBC-Treiber in tomcat-lib-Verzeichnis und nicht in Ihre webapp.Krieg WEB-INF/lib Verzeichnis, da der springende Punkt ist, um den Treiber zu laden vor und unabhängig von der webapp.

Referenzen:

• http://bugs.mysql.com/bug.php?id=68556#c400606

• http://tomcat.apache.org/tomcat-7.0-doc/config/listeners.html#JRE_Memory_Leak_Prevention_Listener_-_org.apache.catalina.core.JreMemoryLeakPreventionListener

• http://markmail.org/message/dmvlkps7lbgpngil

InformationsquelleAutor der Antwort Stefan L

Nahm ich die besten Teile der oben genannten Antworten zusammengefasst und in eine leicht erweiterbare Klasse. Diese kombiniert die Oso 's ursprünglichen Vorschlag mit Bill' s driver improvement und Software Monkey ' s Reflexion Verbesserung. (Ich mochte die Einfachheit von Stephan L s Antwort auch, aber manchmal ändern die Tomcat-Umgebung selbst ist nicht eine gute option, vor allem, wenn man mit autoskalierender oder die migration zu anderen web-container.)

Statt direkt Bezug auf den Namen der Klasse, die thread-Namen, und stop-Methode, die ich auch gekapselt in eine private inner class ThreadInfo. Mit Hilfe einer Liste dieser ThreadInfo Objekte, können Sie weitere lästige threads herunterzufahren, mit dem gleichen code. Dies ist eine etwas komplexere Lösung als die meisten Menschen wahrscheinlich brauchen, aber mehr arbeiten müssen in der Regel, wenn Sie das brauchen.

import java.lang.reflect.Method;
import java.sql.Driver;
import java.sql.DriverManager;
import java.sql.SQLException;
import java.util.Arrays;
import java.util.Enumeration;
import java.util.List;
import java.util.Set;

import javax.servlet.ServletContextEvent;
import javax.servlet.ServletContextListener;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;


/**
 * Context finalization to close threads (MySQL memory leak prevention).
 * This solution combines the best techniques described in the linked Stack
 * Overflow answer.
 * @see <a href="https://stackoverflow.com/questions/11872316/tomcat-guice-jdbc-memory-leak">Tomcat Guice/JDBC Memory Leak</a>
 */
public class ContextFinalizer
    implements ServletContextListener {

    private static final Logger LOGGER =
        LoggerFactory.getLogger(ContextFinalizer.class);

    /**
     * Information for cleaning up a thread.
     */
    private class ThreadInfo {

        /**
         * Name of the thread's initiating class.
         */
        private final String name;

        /**
         * Cue identifying the thread.
         */
        private final String cue;

        /**
         * Name of the method to stop the thread.
         */
        private final String stop;

        /**
         * Basic constructor.
         * @param n Name of the thread's initiating class.
         * @param c Cue identifying the thread.
         * @param s Name of the method to stop the thread.
         */
        ThreadInfo(final String n, final String c, final String s) {
            this.name = n;
            this.cue  = c;
            this.stop = s;
        }

        /**
         * @return the name
         */
        public String getName() {
            return this.name;
        }

        /**
         * @return the cue
         */
        public String getCue() {
            return this.cue;
        }

        /**
         * @return the stop
         */
        public String getStop() {
            return this.stop;
        }
    }

    /**
     * List of information on threads required to stop.  This list may be
     * expanded as necessary.
     */
    private List<ThreadInfo> threads = Arrays.asList(
        //Special cleanup for MySQL JDBC Connector.
        new ThreadInfo(
            "com.mysql.jdbc.AbandonedConnectionCleanupThread", //$NON-NLS-1$
            "Abandoned connection cleanup thread", //$NON-NLS-1$
            "shutdown" //$NON-NLS-1$
        )
    );

    @Override
    public void contextInitialized(final ServletContextEvent sce) {
        //No-op.
    }

    @Override
    public final void contextDestroyed(final ServletContextEvent sce) {

        //Deregister all drivers.
        Enumeration<Driver> drivers = DriverManager.getDrivers();
        while (drivers.hasMoreElements()) {
            Driver d = drivers.nextElement();
            try {
                DriverManager.deregisterDriver(d);
                LOGGER.info(
                    String.format(
                        "Driver %s deregistered", //$NON-NLS-1$
                        d
                    )
                );
            } catch (SQLException e) {
                LOGGER.warn(
                    String.format(
                        "Failed to deregister driver %s", //$NON-NLS-1$
                        d
                    ),
                    e
                );
            }
        }

        //Handle remaining threads.
        Set<Thread> threadSet = Thread.getAllStackTraces().keySet();
        Thread[] threadArray = threadSet.toArray(new Thread[threadSet.size()]);
        for (Thread t:threadArray) {
            for (ThreadInfo i:this.threads) {
                if (t.getName().contains(i.getCue())) {
                    synchronized (t) {
                        try {
                            Class<?> cls = Class.forName(i.getName());
                            if (cls != null) {
                                Method mth = cls.getMethod(i.getStop());
                                if (mth != null) {
                                    mth.invoke(null);
                                    LOGGER.info(
                                        String.format(
            "Connection cleanup thread %s shutdown successfully.", //$NON-NLS-1$
                                            i.getName()
                                        )
                                    );
                                }
                            }
                        } catch (Throwable thr) {
                            LOGGER.warn(
                                    String.format(
            "Failed to shutdown connection cleanup thread %s: ", //$NON-NLS-1$
                                        i.getName(),
                                        thr.getMessage()
                                    )
                                );
                            thr.printStackTrace();
                        }
                    }
                }
            }
        }
    }

}

InformationsquelleAutor der Antwort Richard J. Barbalace

Bill Lösung, sieht gut aus, allerdings habe ich eine andere Lösung gefunden direkt in der MySQL-bug-reports:

[5 Jun 2013 17:12] Christopher Schultz
Hier ist eine viel bessere Lösung, bis etwas anderes ändert.

Aktivieren der Tomcat JreMemoryLeakPreventionListener (standardmäßig aktiviert Tomcat 7), und fügen Sie dieses Attribut, um das element:

classesToInitialize="com.mysql.jdbc.NonRegisteringDriver"

Wenn "classesToInitialize" ist bereits gesetzt , fügen Sie einfach NonRegisteringDriver, um den vorhandenen Wert durch ein Komma getrennt.

und die Antwort:

[8 Jun 2013 21:33] Marko Asplund
Ich habe einige Tests mit der JreMemoryLeakPreventionListener /classesToInitialize workaround (Tomcat 7.0.39 + MySQL Connector/J 5.1.25).

Vor dem anwenden der Problemumgehung thread-dumps aufgeführt mehrere AbandonedConnectionCleanupThread Instanzen nach der Versetzung von der webapp mehrmals. Nach dem anwenden der Problemumgehung es gibt nur eine AbandonedConnectionCleanupThread Instanz.

Musste ich ändern Sie meine app, obwohl, und bewegen Sie MySQL-Treiber von der webapp auf dem Tomcat-lib.
Andernfalls wird der classloader nicht in der Lage ist, laden Sie com.mysql.jdbc.NonRegisteringDriver auf Tomcat starten.

Ich hoffe, es hilft für alle, die noch kämpfen mit diesem Problem...

InformationsquelleAutor der Antwort wmiki

Es scheint, dies wurde behoben in 5.1.41. Sie könnte ein upgrade Connector/J 5.1.41 oder neuer.
https://dev.mysql.com/doc/relnotes/connector-j/5.1/en/news-5-1-41.html

Die Umsetzung der AbandonedConnectionCleanupThread wurde nun verbessert, so dass es jetzt vier Möglichkeiten für Entwickler, um mit der situation umzugehen:

• Wenn Sie den standardmäßigen Tomcat-Konfiguration verwendet wird und der Connector/J jar in einer lokalen Bibliothek Verzeichnis der neuen, integrierten Anwendung Melder in Connector/J erkennt nun das beenden der web-Anwendung innerhalb von 5 Sekunden, und tötet AbandonedConnectionCleanupThread. Keine unnötigen Warnungen über das Gewinde, das unaufhaltsam werden auch vermieden. Wenn der Connector/J jar in eine Globale Bibliothek, der thread wird laufen gelassen, bis die JVM ist entladen.

• Wenn der Tomcat-Kontext konfiguriert ist, die mit dem Attribut clearReferencesStopThreads="true", Tomcat aufhören alle threads hervorgebracht, wenn die Anwendung beendet, es sei denn, Connector/J wird gemeinsam mit anderen web-Anwendungen, in welchem Fall Connector/J ist jetzt geschützt gegen eine unangemessene stoppen von Tomcat; die Warnung über die nicht-beendet-thread ist immer noch ausgestellt in der Tomcat-Fehler-log.

• Wenn ein ServletContextListener implementiert ist, in jedem web-Anwendung, die Anrufe AbandonedConnectionCleanupThread.checkedShutdown() auf die Kontext-Zerstörung, Connector/J nun, wieder, überspringt diesen Vorgang, wenn der Fahrer möglicherweise gemeinsam mit anderen Anwendungen. Keine Warnung über das Gewinde, das nicht aufzuhalten ist ausgestellt Tomcat error log in diesem Fall.

• Wenn AbandonedConnectionCleanupThread.uncheckedShutdown() aufgerufen, die AbandonedConnectionCleanupThread ist auch dann geschlossen, wenn Connector/J ist mit anderen Anwendungen gemeinsam genutzt. Allerdings kann es nicht möglich sein, starten Sie den thread danach.

Wenn Sie einen Blick auf source-code, Sie nannten setDeamon(true) auf dem Gewinde, damit es nicht zu blockieren Herunterfahren.

Thread t = new Thread(r, "Abandoned connection cleanup thread");
t.setDaemon(true);

InformationsquelleAutor der Antwort Le Zhang