Teilen von Codebeispielen für ThreadLocal-Speicherlecks in Java (Bild)

Vorwort

Ich habe zuvor eine ausführliche Analyse des ThreadLocal-Speicherverlustproblems geschrieben, bei der es sich um eine theoretische Analyse des <span class="wp_keywordlink">ThreadLocal</span> Speicherverlustproblems handelt. In diesem Artikel werden wir den tatsächlichen Speicherverlust analysieren Fall. Der Prozess der Problemanalyse ist wichtiger als das Ergebnis. Nur durch die Kombination von Theorie und Praxis kann die Ursache des Speicherverlusts gründlich analysiert werden.

Fall und Analyse

Problemhintergrund

In Tomcat befinden sich die folgenden Codes alle in der Webanwendung, die zu WebappClassLoader Lecks führen und nicht recycelt werden können.

public class MyCounter {
        private int count = 0;

        public void increment() {
                count++;
        }

        public int getCount() {
                return count;
        }
}

public class MyThreadLocal extends ThreadLocal<MyCounter> {
}

public class LeakingServlet extends HttpServlet {
        private static MyThreadLocal myThreadLocal = new MyThreadLocal();

        protected void doGet(HttpServletRequest request,
          HttpServletResponse response) throws ServletException, IOException {

                MyCounter counter = myThreadLocal.get();
                if (counter == null) {
                        counter = new MyCounter();
                        myThreadLocal.set(counter);
                }

                response.getWriter().println(
               "The current thread served this servlet " + counter.getCount()
                  + " times");
                counter.increment();
        }
}

Im obigen Code tritt LeakingServlet auf, solange WebappClassLoader einmal aufgerufen wird und der Thread, der es ausführt, nicht gestoppt wird. Jedes Mal, wenn Sie die Anwendung neu laden, gibt es eine zusätzliche Instanz von WebappClassLoader, was schließlich zu PermGen OutOfMemoryException führt.

Lösen Sie das Problem

Jetzt denken wir darüber nach: Warum verursacht die obige ThreadLocal-Unterklasse einen Speicherverlust?

WebappClassLoader

Zuerst müssen wir herausfinden, was zum Teufel ist WebappClassLoader?

Bei Webanwendungen, die in Java EE-Containern ausgeführt werden, wird der Klassenlader anders implementiert als bei allgemeinen Java-Anwendungen. Verschiedene Webcontainer werden unterschiedlich implementiert. Im Fall von Apache Tomcat verfügt jede Webanwendung über eine entsprechende Klassenlader-Instanz. Dieser Klassenlader verwendet auch den Proxy-Modus. Der Unterschied besteht darin, dass er zunächst versucht, eine bestimmte Klasse zu laden. Wenn er sie nicht finden kann, wird er an den übergeordneten Klassenlader weitergeleitet. Dies ist das Gegenteil der normalen Klassenladereihenfolge. Dies ist eine empfohlene Vorgehensweise in der Java-Servlet-Spezifikation und dient dazu, den eigenen Klassen der Webanwendung Vorrang vor den vom Webcontainer bereitgestellten Klassen einzuräumen. Eine Ausnahme von diesem Proxy-Muster besteht darin, dass Klassen der Java-Kernbibliothek nicht in die Suche einbezogen werden. Dadurch soll auch die Typsicherheit der Java-Kernbibliothek gewährleistet werden.

Mit anderen Worten: WebappClassLoader ist ein benutzerdefinierter Klassenlader, der von Tomcat zum Laden von Webanwendungen verwendet wird. Der Klassenlader jeder Webanwendung ist unterschiedlich. Dies dient dazu, die von verschiedenen Anwendungen geladenen Klassen zu isolieren.

Was hat die Funktion von WebappClassLoader also mit Speicherlecks zu tun? Es ist noch nicht sichtbar, aber es verfügt über eine sehr wichtige Funktion, die unsere Aufmerksamkeit verdient: Jede Webanwendung verfügt über ein eigenes WebappClassLoader, das sich vom Java-Kernklassenlader unterscheidet.

Wir wissen, dass das Leck von WebappClassLoader darauf zurückzuführen sein muss, dass es von anderen Objekten stark referenziert wird. Dann können wir versuchen, ihr Referenzbeziehungsdiagramm zu zeichnen. usw! Was genau ist die Rolle eines Klassenladers? Warum wird es stark zitiert?

Klassenlebenszyklus und Klassenlader

Um das obige Problem zu lösen, müssen wir die Beziehung zwischen Klassenlebenszyklus und Klassenlader untersuchen.

Das Wichtigste in unserem Fall ist die Deinstallation von Klassen:

Nachdem die Klasse verwendet wurde und die folgenden Bedingungen erfüllt sind, wird die Klasse deinstalliert:

1. Alle Instanzen dieser Klasse wurden recycelt, das heißt, es gibt keine Instanzen dieser Klasse im Java-Heap.

2. Das ClassLoader, das diese Klasse geladen hat, wurde recycelt.

3. Das entsprechende java.<a href="http://www.php.cn/java/java-ymp-Lang.html" target="_blank">lang</a>.Class-Objekt dieser Klasse wird nirgendwo referenziert, und es gibt nirgendwo eine Methode, um über Reflektion auf diese Klasse zuzugreifen.

Wenn alle oben genannten drei Bedingungen erfüllt sind, deinstalliert die JVM die Klasse während der Speicherbereinigung im Methodenbereich. Der Deinstallationsprozess der Klasse dient tatsächlich dazu, die Klasseninformationen im zu löschen Methodenbereich Java Der gesamte Lebenszyklus der Klasse ist vorbei.

Klassen, die vom Klassenlader geladen werden, der mit der Java Virtual Machine geliefert wird, werden während des Lebenszyklus der virtuellen Maschine niemals entladen. Zu den Klassenladern, die mit der Java Virtual Machine geliefert werden, gehören Stammklassenlader, Erweiterungsklassenlader und Systemklassenlader. Die Java Virtual Machine selbst verweist immer auf diese Klassenlader, und diese Klassenlader verweisen immer auf die Klassenobjekte der von ihnen geladenen Klassen, sodass diese Klassenobjekte immer erreichbar sind.

Klassen, die von benutzerdefinierten Klassenladern geladen wurden, können entladen werden.

Achten Sie auf den obigen Satz. Wenn WebappClassLoader durchgesickert ist, bedeutet dies, dass die geladenen Klassen nicht entladen werden können, was erklärt, warum der obige Code PermGen OutOfMemoryException verursacht.

Wichtige Punkte sehen Sie sich das Bild unten an

Wir können feststellen, dass das Klassenladeobjekt bidirektional mit dem Klassenobjekt verknüpft ist, das es lädt. Dies bedeutet, dass das Klassenobjekt möglicherweise die starke Referenz WebappClassLoader ist, was zu einem Leck führt.

Referenzdiagramm

Nachdem wir die Beziehung zwischen dem Klassenlader und dem Lebenszyklus der Klasse verstanden haben, können wir mit dem Zeichnen des Referenzdiagramms beginnen. (Die Referenzen von LeakingServlet.class und myThreadLocal im Bild sind nicht präzise, ​​hauptsächlich um auszudrücken, dass myThreadLocal eine Klassenvariable ist)

下面，我们根据上面的图来分析WebappClassLoader泄漏的原因。

1. LeakingServlet持有static的MyThreadLocal，导致myThreadLocal的生命周期跟LeakingServlet类的生命周期一样长。意味着myThreadLocal不会被回收，弱引用形同虚设，所以当前线程无法通过ThreadLocal<a href="http://www.php.cn/code/8210.html" target="_blank">Map</a>的防护措施清除counter的强引用。

2. 强引用链：thread -> threadLocalMap -> counter -> MyCounter.class -> WebappClassLocader，导致WebappClassLoader泄漏。

总结

内存泄漏是很难发现的问题，往往由于多方面原因造成。ThreadLocal由于它与线程绑定的生命周期成为了内存泄漏的常客，稍有不慎就酿成大祸。

本文只是对一个特定案例的分析，若能以此举一反三，那便是极好的。最后我留另一个类似的案例供读者分析。

课后题

假设我们有一个定义在 Tomcat Common Classpath 下的类（例如说在 tomcat/lib 目录下）

public class ThreadScopedHolder {
        private final static ThreadLocal<Object> threadLocal = new ThreadLocal<Object>();

        public static void saveInHolder(Object o) {
                threadLocal.set(o);
        }

        public static Object getFromHolder() {
                return threadLocal.get();
        }
}

两个在 webapp 的类：

public class MyCounter {
        private int count = 0;

        public void increment() {
                count++;
        }

        public int getCount() {
                return count;
        }
}
public class LeakingServlet extends HttpServlet {

        protected void doGet(HttpServletRequest request,
                    HttpServletResponse response) throws ServletException, IOException {

                MyCounter counter = (MyCounter)ThreadScopedHolder.getFromHolder();
                if (counter == null) {
                        counter = new MyCounter();
                        ThreadScopedHolder.saveInHolder(counter);
                }

                response.getWriter().println(
                           "The current thread served this servlet " + counter.getCount()
                                                + " times");
                counter.increment();
        }
}

提示

Das obige ist der detaillierte Inhalt vonTeilen von Codebeispielen für ThreadLocal-Speicherlecks in Java (Bild). Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!