2

At this link here

They describe memory leaks when using classloaders. Now this comment:

A classloader will be removed by the garbage collector only if nothing else refers to it. All classes hold a reference to their classloader and all objects hold references to their classes. As a result, if an application gets unloaded but one of its objects is still being held (e.g., by a cache or a thread-local variable), the underlying classloader cannot not be removed by the garbage collector!

I understand somewhat. But in the portion when they say:

(e.g., by a cache or a thread-local variable)

am I correct to say that by cache they mean a static reference and by threadlocal, they mean a non-static threadlocal variable. I say this because all code explanations of threadlocal memory leaks make the threadlocal variable as static. For example, this question in SO

My other question with the comment about cache is: a static variable will be GC-ed when application does down, so why does this present a problem?

Community
  • 1
  • 1
Victor
  • 16,609
  • 71
  • 229
  • 409
  • Do you mind tagging this as Java or would your question also hold for other GC's, like the .Net one? – rene Aug 29 '13 at 18:15

1 Answers1

1

Each Thread has (effectively) a WeakHashMap, where Data is some object, the object refers to the Class, the Class refers to the ClassLoader, the ClassLoader refers to all classes it has loaded (e.g., ThreadLocalHolder), ThreadLocalHolder class has a static that holds the ThreadLocal, and so the WeakHashMap value refers to the key, which prevents the key+value from being collected until the entire Thread object goes away. See my this answer for a more detailed explanation and example.

Community
  • 1
  • 1
Brett Kail
  • 33,593
  • 2
  • 85
  • 90