-
-
Save DiveInto/4057644 to your computer and use it in GitHub Desktop.
| import java.net.MalformedURLException; | |
| import java.net.URL; | |
| import java.net.URLClassLoader; | |
| public class MLeaks { | |
| static byte[] m = new byte[1024 * 1024]; | |
| static ThreadLocal<MLeaks> tLocal = new ThreadLocal<MLeaks>(){ | |
| @Override | |
| protected MLeaks initialValue() | |
| { | |
| return new MLeaks(); | |
| } | |
| }; | |
| public static void main(String[] args){ | |
| while(true){ | |
| Thread thread = new Thread(){ | |
| public void run() { | |
| try { | |
| URLClassLoader cl = new URLClassLoader(new URL[]{new URL("file:/path-to/MLeaks/bin/")}); | |
| System.out.println(cl.toString()); | |
| Class<MLeaks> tmpClass = (Class<MLeaks>) cl.loadClass(MLeaks.class.getName()); | |
| tmpClass = null; | |
| } catch (MalformedURLException e1) { | |
| e1.printStackTrace(); | |
| } catch (ClassNotFoundException e) { | |
| e.printStackTrace(); | |
| } | |
| } | |
| }; | |
| thread.start(); | |
| } | |
| } | |
| } |
Because you load MLeaks with the system classloader (your main() is inside MLeaks, after all), then any URLClassLoader you create has no effect. The default behavior of URLClassLoader is to first check its parent ClassLoader to see if the class has already been loaded, and if so it doesn't load it again.
To make this a proper test, isolate your main() into a different class from your MLeaks, and don't have any reference to MLeaks from your main(). If you're doing it correctly, each Class instance returned by loadClass() should be distinct.
@dpryden thanks for your reply, now I change the code into this:
package com.demo.app;
import java.net.MalformedURLException;
import java.net.URL;
import java.net.URLClassLoader;
public class LeakApp {
public static void main(String[] args){
while(true){
Thread thread = new Thread(){
public void run() {
try {
URLClassLoader cl = new URLClassLoader(new URL[]{new URL("file:/path-to/MLeaks/bin/")});
//System.out.println(cl.toString());
Class<?> tmpClass = cl.loadClass("com.demo.learn.MLeaks");
//System.out.println(">>>>" + tmpClass.hashCode());
tmpClass = null;
Thread.sleep(1000);
} catch (Exception e1) {
e1.printStackTrace();
}
}
};
thread.start();
}
}
}and the above app load class below:
package com.demo.learn;
public class MLeaks {
static byte[] m = new byte[1024 * 1024];
static ThreadLocal<MLeaks> tLocal = new ThreadLocal<MLeaks>(){
@Override
protected MLeaks initialValue()
{
return new MLeaks();
}
};
}Is that right now?
According to your answer at stackoverflow, this cause memory leak cause the ThreadLocal refers to the instance of MLeaks which refers to the MLeaks class which refers to the URLClassLoader,so even though the thread loading the class cannot access the MLeaks class again, the memeory occupied by MLeaks class can not be GCed.
while according to the javadoc of ThreadLocal：
This method（ThreadLocal's initialValue method） will be invoked the first time a thread accesses the variable with the get() method
so I think simply load the class won't call the initialValue method, so no instance of MLeaks will be stored into ThreadLocal, and that makes the rest reasoning invalid.
Correct me if I make mistake here, Thanks again.
It's true, if you only subclass ThreadLocal and never actually assign a value into the the thread local storage, then you're not leaking. In my experience, for these kinds of use cases (a thread local in a framework), the ThreadLocal object is almost always instantiated directly instead of being subclassed.
As it turns out, a lot of existing code follows this kind of pattern. For example, most Java servlet containers create a bunch of long running threads which are used to handle requests, then load each application in its own ClassLoader. When you update the application (e.g. by replacing the WAR file), the old ClassLoader is discarded and a new one is created. All of this works fine, unless you also have a framework in place that uses ThreadLocals. As it turns out, lots of popular frameworks use thread local storage (including many Java web application frameworks), and many frameworks compound the problem by creating their own ClassLoaders to do runtime bytecode manipulation (Hibernate and many AOP frameworks do this). A large application can easily pull in a dozen or so different large libraries and frameworks, and it can be very difficult to determine exactly where you have the one dangling reference that is keeping your entire application in memory.
The common way that this problem manifests is on a development/debugging server. For example, on a previous project, I would develop our web application (which used Stripes, Guice, Hibernate, and a handful of other big libraries) on a local Tomcat server. Throughout the day I would frequently redeploy the application to my local server, and I was guaranteed to to have to restart my local server at least once every few hours because the PermGen would fill up and the server would crash.
The point of my answer over at StackOverflow was that this is a true memory leak: once the ClassLoader is discarded, there's no way to retrieve the ThreadLocal instance anymore, and so short of killing the Thread (and maybe not even then) there is no way to release the memory.
GC logs