I am referring to this code example, which is being reported in https://bugs.java.com/bugdatabase/view_bug?bug_id=6254531
import java.net.URL;
class Loader {
public static void main(String[] args) throws Exception {
for (;;) {
System.gc();
System.out.print(".");
System.out.flush();
new java.net.URLClassLoader(
new URL[] { new java.io.File(".").toURL() },
ClassLoader.getSystemClassLoader().getParent()
).loadClass("Weakling").newInstance();
}
}
}
public class Weakling {
private static ThreadLocal<Object> local;
private static Weakling staticRef;
private Object var = new byte[1000*1000];
public Weakling() {
local = new ThreadLocal<Object>();
local.set(this);
staticRef = this;
}
@Override
protected void finalize() {
System.out.print("F");
System.out.flush();
}
}
The finalize will never be called. However, if I change the
new java.net.URLClassLoader(
new URL[] { new java.io.File(".").toURL() },
ClassLoader.getSystemClassLoader().getParent()
).loadClass("Weakling").newInstance();
to
new Weakling();
It works very well and no leaking detected.
Can anyone explain why the object created by ClassLoader do not have chance to garbage collect itself?
The ThreadLocal mechanism effectively stores on the current thread a WeakHashMap of ThreadLocal instances to values. Consequently, if the ThreadLocal instance never becomes weakly referenceable, then the entry is effectively leaked.
There are two cases to consider. For the simplicity of discussion, let’s assume that ThreadLocal actually stores a WeakHashMap on Thread.currentThread(); in reality, it uses a more sophisticated mechanism that has an equivalent effect.
First consider the “new Weakling” scenario:
Second consider the “new URLClassLoader(…).loadClass(…).newInstance()” scenario:
Note that during this final step, ThreadLocal instance #1 is not weakly referenceable. This is because of the following reference chain:
As long as the loop continues to run, more entries are added to the ThreadLocal WeakHashMap, and the strong reference chain from value-to-key (Weakling instance to ThreadLocal) in the WeakHashMap prevents garbage collection of otherwise stale entries.
I’ve modified the Loader program to iterate 3 times and then wait for user input. Then, I generated a heap dump using java -Xrunhprof:heap=dump and ctrl-pause/break. The following is my analysis of the final heap dump:
First, there are three Weakling objects:
Note that all three Weakling instances (500002a1, 500003a4, and 500003e0) are created from three distinct class instances (50000296, 5000039d, and 500003d9, respectively). Looking at the first object, we can see that it is held as a value in an entry object in the threadLocal map:
The referent here is value being held weakly:
Searching, we can see that this object is held as a value in the static
variable “local” of the aforementioned Weakling class:
In conclusion, we have the following strong reference chain loop for this Weakling instance, which prevents it from being garbage collected.
A similar analysis on the other Weakling objects would show a similar result. Allowing the program to run for additional iterations shows that the objects continue to accumulate in this manner.