Sharing code examples of ThreadLocal memory leaks in Java (picture)

Preface

I previously wrote an in-depth analysis of the memory leak problem of ThreadLocal. It is a theoretical analysis of the memory leak problem of <span class="wp_keywordlink">ThreadLocal</span>. Let’s take a look at this article. Analyze actual memory leak cases. The process of analyzing the problem is more important than the result. Only by combining theory with practice can the cause of the memory leak be thoroughly analyzed.

Case and Analysis

Problem Background

In Tomcat, the following codes are all in webapp, which will cause WebappClassLoader to leak and cannot be recycled.

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();
        }
}

In the above code, as long as LeakingServlet is called once and the thread executing it does not stop, it will cause WebappClassLoader to leak. Every time you reload the application, there will be one more instance of WebappClassLoader, which will eventually lead to PermGen OutOfMemoryException.

Solution to the problem

Now let’s think about it: Why does the above ThreadLocal subclass cause a memory leak?

WebappClassLoader

First of all, we have to figure out what WebappClassLoader is?

For web applications running in Java EE containers, the class loader is implemented differently from general Java applications. Different web containers are implemented differently. In the case of Apache Tomcat, each web application has a corresponding class loader instance. This class loader also uses the proxy mode. The difference is that it first tries to load a certain class. If it cannot find it, it then proxy to the parent class loader. This is the opposite of the normal class loader order. This is a recommended practice in the Java Servlet specification, and its purpose is to give priority to the Web application's own classes over those provided by the Web container. An exception to this proxy pattern is that Java core library classes are not included in the search. This is also to ensure the type safety of the Java core library.

That is to say WebappClassLoader is a custom class loader for Tomcat to load webapps. The class loader of each webapp is different. This is to isolate the loading of different applications. the type.

So what does WebappClassLoader’s features have to do with memory leaks? It's not visible yet, but it has a very important feature worthy of our attention: each webapp will have its own WebappClassLoader, which is different from the Java core class loader.

We know that the leakage of WebappClassLoader must be because it is strongly referenced by other objects, then we can try to draw their reference relationship diagram. etc! What exactly is the role of a class loader? Why is it strongly quoted?

Class life cycle and class loader

To solve the above problem, we have to study the relationship between the class life cycle and the class loader.

The main thing related to our case is the uninstallation of classes:

After the class is used, if the following conditions are met, the class will be uninstalled:

1. All instances of this class have been recycled, that is, there are no instances of this class in the Java heap.

2. The ClassLoader that loaded this class has been recycled.

3. The java.<a href="//m.sbmmt.com/java/java-ymp-Lang.html" target="_blank">lang</a>.Class object corresponding to this class is not referenced anywhere, and this class is not accessed through reflection anywhere. method.

If all the above three conditions are met, the JVM will uninstall the class during garbage collection in the method area. The uninstallation process of the class is actually to clear the class information in the method area. Java The entire life cycle of the class is over.

Classes loaded by the class loader that comes with the Java virtual machine will never be unloaded during the life cycle of the virtual machine. The class loaders that come with the Java virtual machine include root class loaders, extension class loaders and system class loaders. The Java virtual machine itself will always refer to these class loaders, and these class loaders will always refer to the Class objects of the classes they load, so these Class objects are always reachable.

Classes loaded by user-defined class loaders can be unloaded.

Pay attention to the above sentence, WebappClassLoaderIf it leaks, it means that the classes it loads cannot be unloaded, which explains why the above code will cause PermGen OutOfMemoryException.

Key points look at the picture below

We can find that the class loader object is bidirectionally related to the Class object it loads. This means that the Class object may be a strong reference to WebappClassLoader, causing it to leak.

Reference diagram

After understanding the relationship between the class loader and the life cycle of the class, we can start to draw the reference diagram. (The references to LeakingServlet.class and myThreadLocal in the picture are not rigorous, mainly to express that myThreadLocal is the class variable)

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

1. LeakingServlet持有static的MyThreadLocal，导致myThreadLocal的生命周期跟LeakingServlet类的生命周期一样长。意味着myThreadLocal不会被回收，弱引用形同虚设，所以当前线程无法通过ThreadLocal<a href="//m.sbmmt.com/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();
        }
}

提示

The above is the detailed content of Sharing code examples of ThreadLocal memory leaks in Java (picture). For more information, please follow other related articles on the PHP Chinese website!