Develop Reference

Java WeakHashMap clean up

I try to figure out how the WeakHashMap cleans up after garbare collection.
As many of you may know, the WeakHashMap entry is removed automatically when its key becomes garbage collected. But, for instance, if I do something like this:
List<WeakReference<Main>> list = new ArrayList<>();
list.add(new WeakReference<>(new Main()));
System.gc();
Thread.sleep(1000);
list.get(0).get(); //null - WeakReference referent has been removed
list.get(0); //empty WeakReference object is still present in the List
ArrayList doesn't clean the empty WeakReference objects, but why WeakHashMap does? Which component is responsible for this automatic entry removing. I don't see any code in the WeakHashMap sources which could do that.

WeakHashMap cleans itself up. Calls to getTable() (itself called by get, put, etc.), size() and resize(int) all first call expungeStaleEntries, which iterates a ReferenceQueue of GC'd Entries and removes them from the table. The garbage collector is responsible for putting unreachable WeakReference objects on the queue.

Weak Reference maintainability

I was reading up on weak references in java and sounds simple enough, if an object only has weak references on it, then it can be collected by the garbage collector. Except what happens if your reference becomes dead before you use the value?
Example:
Suppose I have a weak hashmap with the keys {1,2,3,4,5}, all with values of 1. Now suppose you have a random number generator for numbers in [1:10]. Now every time the number is gotten, it checks if it a key in the map and then gives a temporary strong reference to the key. So with this setup, you'll have some keys having strong references and thus stay in memory, but you also have the probability that some keys will become dead before being chosen.
If my intuition for weak hashmaps is correct, does that mean that the map will at some point be altered from its original state?

Trying to use Integer objects as keys for a WeakHashMap is likely to result in some strange behavior. To start with, the javadoc for WeakHashMap has the following note:
This class is intended primarily for use with key objects whose equals methods test for object identity using the == operator. Once such a key is discarded it can never be recreated, so it is impossible to do a lookup of that key in a WeakHashMap at some later time and be surprised that its entry has been removed. This class will work perfectly well with key objects whose equals methods are not based upon object identity, such as String instances. With such recreatable key objects, however, the automatic removal of WeakHashMap entries whose keys have been discarded may prove to be confusing.
Consider the following code:
WeakHashMap<Integer, String> map = new WeakHashMap<>();
Integer k = Integer.valueOf(9001);
map.put(k, "OVER 9000!?");
while (true)
{
System.out.println(map.get(k));
Thread.sleep(100);
k = Integer.valueOf(9001);
System.gc();
}
The loop will start by printing "OVER 9000!?", but after the first loop, the original key has been discarded (even if there's now a reference to a key that is equals to it). As a result, if that key object gets garbage collected, the entry will be removed from the map and the loop will begin printing "null" instead. Since we call System.gc(); after discarding the key, it's likely that this happens after a single loop.
That's not the end of the issues with using Integer as a WeakHashMap key, though. If you change the value 9001 above to 1, you'll find that the behavior changes! (Probably? This may be implementation-dependent.) Now, the entry never gets removed from the map. This is because of the integer cache--Integer.valueOf(1) always returns the same Integer instance, but Integer.valueOf(9001) creates a new Integer instance each time.
This second issue is specific to Integer, but the first actually applies to any scheme where you try to use keys where equals is not based on ==. And if equals is based on ==, then your question doesn't really apply--if you don't have a strong reference to the key anymore, it doesn't matter whether the value gets removed from the map because you no longer have a way to get to it--you can't recreate a key that uses identity-based equality.

This answer already addresses issues stemming from the use of types with value-based equality in a construct whose behavior depends on the identity of objects, like the reachability.
In short, when you are able to construct new objects with the same equality as the weakly reachable keys, it’s possible to detect the sudden removal of the keys.
However, you can also turn weakly reachable objects back to the strongly reachable state, e.g. by calling the get() method of a WeakReference or when iterating over the mappings of a WeakHashMap.
WeakHashMap<Object, Boolean> map = new WeakHashMap<>();
Object key = new Object();
map.put(key, true);
WeakReference<Object> ref = new WeakReference<>(key);
key = null;
// now, the key object is only weakly reachable
key = ref.get();
// now, the key object might be strongly reachable again
// in that case, this statement will print true
System.out.println(map.get(key));
The construction of an object with a distinct identity and no overridden equals method via new Object() ensures that no other reference to the same object nor an equal object can exist. At one point of this code, the object is only weakly reachable, but then, it is made strongly reachable, with a very high likelihood.
It is possible that a garbage collection happens between these points and since all weak references to an object are cleared atomically, you can detect this situation by getting a null reference from get(). The likelihood for a garbage collection to happen right at this point is very low, though. That’s why the linked answer uses calls to System.gc() in-between, to raise the likelihood of the weak references to get cleared.
This is rather a contrived example, but helps addressing you question, “…does that mean that the map will at some point be altered from its original state?”.
If you use equal keys with a different identity or keys which are weakly reachable for some time, the map may get altered at some time, but there is no guaranty that this ever happens. This depends on when the garbage collector will run and actually discover the weak reachability of some objects. But typically, JVMs try to prevent garbage collection until there’s really a demand for it. So an application may run quiet a while without garbage collection at all. Further, if you do poll a mapping regularly, it may even happen, that the gc runs right at that point of time when the key is strongly reachable during the lookup.

The purpose of WeakReference is to help with memory management. As you wrote, "if the object is not used normally" (there is no strong reference, in fact direct variable holding it), "then you don't need it any more" (it can be garbage collected). In case of weak hash map it aplies to the key, so you typically use it for caching of temporary associated data.
From that being said, it doesnt make sense to only put something into weak hash map without continue using the key as strong reference, because the collector can collect it immediately before you access it.
It may not (even System.gc() doesn't force the GC to run), but you cannot rely on it.

GC doesnt remove objects from weakhashmap

I hava a test application with one class that stores a map and a button that invokes method of that class:
Map<Object, Object> weakMap = new WeakHashMap<Object, Object>();
The button does this:
public void fillWeakHashMap(int size) {
List<String> createObjects = (List<String>) createObject(size);
for (Object ob : createObjects) {
weakMap.put(ob, ob);
}
}
So the main class with the map lives but objects which I put to it are created in separate method and since it is a WeakHashMap I thought that after exit from the method fillWeakHashMap the keys / objects in map would be cleared by the GC.
I opened the VisualVM->VisualGC and clicked Monitor->PerformGC 10 times and the Old space is almost full meaning that GC isnt clearing those objects. So what am I doing wrong?

The first sentence of WeakHashMap's javadoc says:
Hash table based implementation of the Map interface, with weak keys. An entry in a WeakHashMap will automatically be removed when its key is no longer in ordinary use. More precisely, the presence of a mapping for a given key will not prevent the key from being discarded by the garbage collector, that is, made finalizable, finalized, and then reclaimed. When a key has been discarded its entry is effectively removed from the map, so this class behaves somewhat differently from other Map implementations.
and somewhat further down, it writes:
The value objects in a WeakHashMap are held by ordinary strong references. Thus care should be taken to ensure that value objects do not strongly refer to their own keys, either directly or indirectly, since that will prevent the keys from being discarded.
That is, only the keys are weakly referenced, but the values are strongly referenced. In your code, each key is also used a value, therefore strongly referenced, and therefore not garbage collected.

You are keeping a reference for each object in the map like ob is still referring itself that is why nothing is being cleared, since GC cant claimed that those objects are not is use and can be cleaned.

What is the purpose of WeakHashMap when there is HashMap and Concurrent HashMap?

What is the need arises for introducing Weak HashMap when there is already other implementations available.
In short i have two issues :
Why jdk has WeakHashMap when there is HashMap and Concurrent HashMap in java ?
What is the use of it in real life applications ?
EDIT :
Though WeakHashmap key is a weak references but still they refer to
something than on what basis GC discard keys in WeakHashMap.

One Common use of WeakReferences and WeakHashMaps in particular is for
adding properties to objects. Occasionally you want to add some
functionality or data to an object but subclassing and/or composition
are not an option in that case the obvious thing to do would be to
create a hashmap linking the object you want to extend to the property
you want to add. then whenever you need the property you can just look
it up in the map. However, if the objects you are adding properties to
tend to get destroyed and created a lot, you can end up with a lot of
old objects in your map taking up a lot of memory
If you use a WeakHashMap instead the objects will leave your map as
soon as they are no longer used by the rest of your program, which is
the desired behavior.
The key of a WeakHashMap has weak reference. If the key has been garbage collected, then the entry in WeakHashMap object will automatically be deleted. It does not happen in normal HashMap. The entry will not be deleted if the key is garbage collected.
In the example I have taken one HashMap and one WeakHashMap. I will put entry in both the object and then later we will make the reference key as null and then garbage collected. And again check the entry. In the HashMap object entry will be there but in WeakHashMap object there will not be entry present.
import java.util.HashMap;
import java.util.Map;
import java.util.WeakHashMap;
public class WeakHashMapTest {
public static void main(String[] args) {
Map hashMap= new HashMap();
Map weakHashMap = new WeakHashMap();
String keyHashMap = new String("keyHashMap");
String keyWeakHashMap = new String("keyWeakHashMap");
hashMap.put(keyHashMap, "Ankita");
weakHashMap.put(keyWeakHashMap, "Atul");
System.gc();
System.out.println("Before: hash map value:"+hashMap.get("keyHashMap")+" and weak hash map value:"+weakHashMap.get("keyWeakHashMap"));
keyHashMap = null;
keyWeakHashMap = null;
System.gc();
System.out.println("After: hash map value:"+hashMap.get("keyHashMap")+" and weak hash map value:"+weakHashMap.get("keyWeakHashMap"));
}
}
The output would be:
Before: hash map value:Ankita and weak hash map value:Atul
After: hash map value:Ankita and weak hash map value:null
More info:
When would you use a WeakHashMap or a WeakReference?
WeakHashMap vs. HashMap

unlike the normal collections, which hold data until you decide to clear it out, data in WeakHashMap may be removed at any point in time and without notice when the JVM decides it wants the memory back. this makes it suitable for all sorts of caching purposes.
you can read up on weak references (and various other related types) here

First you should understand the purpose of WeakReferences. Once you understand that then reading the WeakedHashMap definition from docs clearly tells its purpose
A hashtable-based Map implementation with weak keys. An entry in a
WeakHashMap will automatically be removed when its key is no longer in
ordinary use. More precisely, the presence of a mapping for a given
key will not prevent the key from being discarded by the garbage
collector, that is, made finalizable, finalized, and then reclaimed.
When a key has been discarded its entry is effectively removed from
the map, so this class behaves somewhat differently from other Map
implementations.

You can use an object as a key without preventing its collection.
From the WeakHashMap documentation:
When a key has been discarded its entry is effectively removed from the map, so this class behaves somewhat differently from other Map implementations.

They provide a a way of using an object as a key without creating a strong reference to it. This is good practice where you don't want to hinder JVM's ability to garbage collect the object but yet still want the ability to track some aspect of the object. This makes them ideal for caching or storing metadata about the object.

From the answers, the only cache feature is automatic eviction on GC and it probably won't happen during young gen GC but in tenured old gen GC for the usecase of caching large files that are used for sometime. Is the entry evicted on any GC or only when tenured generation is full?
Besides unpredictable eviction there is no size constraint that can be specified on the map, so any cache library with pre-defined cache size (number of elements and memory size) along with an eviction strategy seems like a better option to me as most caches also include a provision to reduce size/flush more elements when heap usage goes beyond a certain size. These also provide consistency during concurrency.
So, I wonder if there is a good use case to use this besides the risk of memory leaks and missed hits due to bad design.

How HashMap handles the updated <key,value>,if value itself is a Hashmap?

when we put a <key,value> in a HashMap,if the key is already present in the HashMap then the value gets replaced. But if for a key the value is itself a HashMap then would it get replaced with the HashMap?

Yes, it would be replaced. Remember that a Map only stores references to other objects.
You put a reference to a HashMap in a map, and the map keeps a reference to this HashMap.
If you put a reference to another HashMap using the same key, the reference to the first put HashMap is replaced by the reference to the new HashMap. The type of the object doesn't matter. It always works the same way.

If I understand what you're asking, you want to know if what you just said will cause a memory leak (please update your question if this isn't what you're asking).
If you do:
Map<?, ?> m = new HashMap<Object, Object>();
m.put(m, m);
Then m will ultimately only contain a reference to itself. Because of how Java's GC works via an object reference graph, and because they use an algorithm which tracks visited nodes during a GC sweep, if nothing maintains a reference to m, then m will be garbage collected, despite containing a reference to itself. Circular references are perfectly handled in the Java GC.
If m is placed into a field (i.e., not a local variable declared inside a method) then it's a different story.
If m is placed in a static field, then there will always be a reference to it from a GC root, which means it won't be reclaimed. Note: nothing strongly referenced to from a static field will ever be garbage collected.
If m is placed in a member field (non-static), then the map won't be garbage collected until the object that contains it is garbage collected.
If there are multiple fields that refer to m, then m won't be garbage collected until all those references are either a) part of an object that can be garbage collected or b) are set to null or some other value to no longer refer to m.
TL;DR the garbage collector handles circular object references just fine.
Sidenote: Please update your question with information, don't just add it as comments to your question or others' answers.

The wording in your question is a bit opaque, but a HashMap<HashMap, Object> is perfectly valid (if somewhat strange). In that case, if:
HashMap map = new HashMap<HashMap<String, String>, String>();
HashMap a = new HashMap<String, String>();
HashMap b = new HashMap<String, String>(); //a.equals(b) == true
map.put(a, "foo"); //map.get(a) would now return "foo"
map.put(b, "bar"); //original entry is replaced, map.get(a) would now return "bar"