Is using the Class instance as a Map key a best practice?
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:
- The old and new versions of the class will not be equal.
- Looking up the new class will initially give a "miss".
- After you have added the new class to the map, you will now have two different map entries for the different versions of the class.
- This applies even if there is no code difference between the two versions of the class. They will be different simply because they were loaded by different classloaders.
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.