I have read somewhere that using the class instances as below is not a good idea as it might cause memory leaks. Can someone tell me if that is a valid statement? Or are there any problems using them this way?
Map<Class<?>,String> classToInstance = new HashMap();
classToInstance.put(String.class,"Test obj");
Yes, you do need to be cautious! For example, if your code is running in a web container and you are in the habit of doing hot deployment of webapps, a retained reference to a single class object can cause a significant permgen memory leak.
This article explains the problem in detail. But in a nutshell, the problem is that each class contains a reference to its classloader, and each classloader contains references to every class that it has loaded. So if one class is reachable, all of them are.
The other thing to note is that if one of the classes that you are using as a key is reloaded then:
From Java 8 - Permgen was removed. Do you think it is ok to use Class instance as HashMap key in any situations?
Be aware that you will still have a memory leak. Any dynamicly loaded class used in your HashMap (key or value) and (at least) other dynamically loaded classes will be kept reachable. This means the GC won't be able to unload / delete them.
What was previously a permgen leak is now a ordinary heap and metaspace storage leak. (Metaspace is where the class descriptors and code objects for the classes are kept.)
As Stephen C mentioned, the memory leak is indeed because of classloaders. But the problem is more acute than at first glance. Consider this:
mapkey --> class --> classloader --> all other classes defined by this classloader.
Furthermore,
class --> any static members, including static Maps e.g. caches.
A few such static caches can start adding up to serious amounts of memory lost whenever a webapp or some other dynamically (classloaded) loaded app is cycled.
There are several approaches to working around this problem. If you don't care about different 'versions' of the same class from different classloaders, then simply key based on Class.getName(), which is a java.lang.String.
Another option is to use java.util.WeakHashMap. This form of Map only maintains weak references to the keys. Weak references don't hold up GC, so they key won't cause a memory accumulation. However, the values are not referenced weakly. So if the values are for example instances of the classes used as keys, the WeakHashMap does not work.
No, that's not a problem. As long as you were creating an instance of the class anyway, you're not using any more memory by holding a reference to the class itself.
That depends where the reference classToInstance=new HashMap(); is defined.
A class points back to its class loader, and as a consequence, the class loader can not be garbage collected while a reference to the class exists. But if the references form a circle (or an unreachable cluster), this still works -- the GC knows how to deal with circular references.
parent class loader --> class loader <--> class // no GC is possible
parent class loader class loader <--> class // circular references are GC'ed
So a reference to a class may prevent the class loader from being GC'ed only if the references come from an object/class in a parent class loader.
parent class loader class loader <--> class // no GC is possible
\-------------------/
That's what the sentence "any reference from outside the application to an object in the application of which the class is loaded by the application's classloader will cause a classloader leak" means in the article mentioned in Stephen C. answer.
But it's shouldn't be the case if the map is part of your application.
