2

ClassLoaders are stored in Permanent generation memory . And as specified in white paper of java Memory Management in the Java HotSpot™ Virtual Machine, permanent generation memory is garbage collected for sure. So, Does custom Classloader still lead to memory leakage? If yes, then how come that it happens?

UPDATE

With the help of @Marko Topolnik and @Prunge I got my doubt clear. And following points are made out about ClassLoaders and Memory Leaks:

  1. Custom ClassLoaders are not stored in Perm generation.
  2. Custom ClassLoader could lead to memory leakage if ClassLoder is out of scope but the classes that it has loaded is still referred by the Application no matter if we set the ClassLoader object to null.
  3. If we don't need a given ClassLoader object then we should make sure that all the references to the objects developed from loaded classes should be null.
  4. If any of the classes loaded by ClassLoader is not eligible for GC then the ClassLoader will not be GCed.
Mac
  • 1,711
  • 3
  • 12
  • 26
  • What evidence do you have of a memory leak? – Joni Jul 27 '13 at 13:33
  • @Joni: perhaps I worded my question in wrong way..Please see my updated Question. – Mac Jul 27 '13 at 13:41
  • 1
    Classloaders are *not* stored in permGen. Class *data* is stored there, which is totall independent of the classloader which did the loading. – Marko Topolnik Jul 27 '13 at 14:03
  • @MarkoTopolnik: Thanks for your response. But in the following answer http://stackoverflow.com/a/6471947/2536255 It is said that : *in many JVM implementations Classes and ClassLoaders are allocated straight into permgen and are never GC'd at all* – Mac Jul 27 '13 at 14:10
  • 1
    That statement about classloaders is incorrect. They are just plain Java classes. PermGen contains special material which is not regular object data. – Marko Topolnik Jul 27 '13 at 14:15
  • @MarkoTopolnik: Thanks. Can you please send me some official source where I could be confirmed about the storage area of `ClassLoader` object? And apart from that..I still didn't get an answer that Does Custom `ClassLoader` lead to memory leakage? If yes, then Why ? Your any citation on this will be much helpful for me.. – Mac Jul 27 '13 at 14:22
  • 1
    [This is a great read on the HotSpot GC](https://blogs.oracle.com/jonthecollector/entry/presenting_the_permanent_generation). – Marko Topolnik Jul 27 '13 at 14:29
  • @MarkoTopolnik: Thanks..I will go through that link..In fact I am reading it right now..You have been very helpful.. – Mac Jul 27 '13 at 14:46
  • @MarkoTopolnik: Please correct me if I am wrong in any points: 1)Custom `ClassLoader`s are not stored in Perm generation 2) Custom `ClassLoader` could lead to memory leakage if `ClassLoder` is out of scope but the classes that it has loaded is still referred by the Application no matter if I set the `ClassLoader` object to `null`. 3)If we don't need a given classLoader object we should make sure that all the references to the objects developed from loaded classes should be `null`.4) If any of the classes loaded by `ClassLoader` is not eligible for `GC` then the ClassLoader will not be `GCed`. – Mac Jul 27 '13 at 16:24
  • 1
    Yes, you are right on all points, and you have nicely summarized why it is so easy to end up with a classloader leak. – Marko Topolnik Jul 27 '13 at 16:50
  • Thanks @MarkoTopolnik. Now my all doubts are clear because of your much needful help.. I would be glad if you please post your answer mentioning the strong points .. So that I could accept it as an answer and the other people reading this Post will also be benefited by reading your answer... – Mac Jul 27 '13 at 17:22

2 Answers2

3

Custom classloaders do not lead to memory leaks by themselves. If the classes they load are not used correctly, then leaks can occur.

Classes and classloaders can be garbage collected normally - this can be turned off with the -Xnoclassgc command line option but the user has to explicitly do this. Classloaders have reference to all their classes, so a classloader can only be garbage collected if all their classes are no longer referenced.

Leaks can occur when classes or instances of these classes loaded from the custom classloader are still referenced in an application.

A common example is Java EE web containers such as Tomcat:

Let's assume that each webapp in the container has its own classloader. When a webapp is unloaded, the container drops the app and all the classes (including compiled JSPs) should no longer be referenced, and sooner or later the classes and the classloader are cleaned up by garbage collection. But the webapp might have registered a database driver in DriverManager, or used some bean introspection (quite possible indirectly through a popular third party library that does reflection) that keeps bean metadata cached and therefore the classes from the webapp classloader live on after the webapp has been undeployed, still being strongly referenced from other objects not loaded by the webapp's classloader.

Tomcat has a page describing a few of the possible leak scenarios and how it works around them.

But custom classloaders do not cause leaks if they are written correctly.

prunge
  • 22,460
  • 3
  • 73
  • 80
  • Thanks for the clear and beautiful explanation.. So let me recollect everything that I have known in this thread: 1)Custom `ClassLoader`s are not stored in Permanent generation 2) Custom `ClassLoader`s could lead to memory leakage if **ClassLoder is out of scope** but the classes that it has loaded is still referred by the Application no matter if I set the `ClassLoader` object to `null`. 3)If we don't need a given classLoader object we should make sure that all the references to the objects developed from loaded classes should be `null`. Please , correct me if I am wrong anywhere.. – Mac Jul 27 '13 at 14:58
2

Classloaders are not stored in the PermGen space. Class data is stored there, which is only indirectly related to the classloader which did the loading: the classloader holds a reference to each class it has loaded.

This answer gives good information, except for one thing: it is wrong about the classloaders being allocted in the PermGen space. Classloaders are just plain Java classes, and PermGen only contains special material which is not regular object data. For example, it holds all static class variables and executable code of methods.

A great resource on the details of HotSpot memory layout and garbage collection can be found here.

Community
  • 1
  • 1
Marko Topolnik
  • 195,646
  • 29
  • 319
  • 436