Guava CacheBuilder or MapMaker with Weak/Soft usage

Question

I'm not used to deal with Soft and Weak references in Java but i understand the principle since i'm used to deal with datagrids like Gemfire, which provide overflow to hdd features when memory is full, probably using soft references or something similar i guess.

What i don't understand in Guava is that it provides methods to make the keys soft/weak, and the values soft/weak.

I just wonder what's the point of creating soft keys with non-soft values for exemple? I mean, when the soft references start to be collected, we can't find anymore the entry by its key, so why would we like the values to stay in the map?

Can someone give us some usecases with:

• Weak key / soft values
• Weak key / normal values
• Soft key / weak values
• Soft key / normal values

Thanks

---

Edit I'm not sure my question is precise enough so what i'd like to know is:

• when a key is collected (weak/soft), what happens to the value (non weak/soft)
• when a value is collected (weak/soft), what happens to the key
• Are entries with a missing part (key or value) kept in the cache?
• And is there any usecase when you want such entries to stay in the cache.

---

Edit: As discussed on Kevin Bourillon's answer, finally i think i understand why using soft keys doesn't mean anything. Here's why:

static class KeyHolder {
    final private String key;
    public KeyHolder(String key) {
        this.key = key;
    }
    public String getKey() {
        return key;
    }
    @Override
    public boolean equals(Object o) {
        KeyHolder that = (KeyHolder)o;
        boolean equality = this.getKey().equals(that.getKey());
        return equality;
    }
    @Override
    public int hashCode() {
        return key != null ? key.hashCode() : 0;
    }
    @Override
    public String toString() {
        return "KeyHolder{" +
                "key='" + key + '\'' +
                '}';
    }
}

public static void main(String[] args) {
    System.out.println("TESTING WEAK KEYS");
    testMap( new MapMaker().weakKeys().<KeyHolder,String>makeMap() );


    System.out.println("\n\n");
    System.out.println("TESTING SOFT KEYS");
    testMap(new MapMaker().softKeys().<KeyHolder, String>makeMap());


    System.out.println("\n\n");
    System.out.println("TESTING SOFT REFERENCES");
    KeyHolder key1 = new KeyHolder("toto");
    KeyHolder key2 = new KeyHolder("toto");
    SoftReference<KeyHolder> softRef1 = new SoftReference<KeyHolder>(key1);
    SoftReference<KeyHolder> softRef2 = new SoftReference<KeyHolder>(key2);
    System.out.println( "equals keys? " + key1.equals(key2) );
    System.out.println( "equals ref? " + softRef1.equals(softRef2) );
}

private static void testMap(Map<KeyHolder,String> map) {
    KeyHolder strongRefKey = new KeyHolder("toto");
    KeyHolder noStrongRefKey = new KeyHolder("tata");
    map.put(strongRefKey,"strongRef");
    map.put(noStrongRefKey,"noStrongRefKey");
    // we replace the strong reference by another key instance which is equals
    // this could happen for exemple in case of serialization/deserialization of the key
    noStrongRefKey = new KeyHolder("tata");
    System.gc();
    System.out.println( "strongRefKey = " + map.get(strongRefKey) );
    System.out.println( "noStrongRefKey = " + map.get(noStrongRefKey) );
    System.out.println( "keyset = " + map.keySet() );
}

This code produces the output:

TESTING WEAK KEYS
strongRefKey = strongRef
noStrongRefKey = null
keyset = [KeyHolder{key='toto'}]



TESTING SOFT KEYS
strongRefKey = strongRef
noStrongRefKey = null
keyset = [KeyHolder{key='tata'}, KeyHolder{key='toto'}]



TESTING SOFT REFERENCES
toto == toto -> true
equals keys? true
equals ref? false

As you can see, with the (deprecated) soft keys map, the KeyHolder containing "tata" still exists in the map. But notice that i'm still not able to find my entry with a newly created key "new KeyHolder("tata");" This is because, my keys are meaningfully equals, but the reference wrappers around them are not equals because their equals method is not overriden in Guava! In this case, yes, softKeys doesn't mean anything since you absolutly need to keep an identity reference to that key to be able to retrieve it.

Answer 1

softKeys never makes sense, so we removed the method. softValues is the only way soft refs make sense, assuming the value instances aren't also reachable in other ways outside the cache.

Then usage of weakKeys basically boils down to whether you want identity equality for keys. If the key overrides equals and you need that equality behavior, you can't use it. If you want identity, then weakKeys is how you get that, and it also makes sense because once all other references to the key have been GC'd, there would be no way to look up that entry anyway, so it might as well be removed.

I actually am not entirely clear on when weakValues is useful, and was going to look into it. It would probably be a case where weakKeys is not an option (say, Integer keys), and where the values are ordinarily strongly referenced through other means, like some sort of session object, but when that object goes away, it signifies that no one will be looking for this in the cache anymore. It seems slightly farfetched when I put it that way, though.

Answer 2

The non-Guava WeakHashMap is based on weak keys and discards the whole entry when a key is no longer in use. Thus, there is no "value staying in the map" then. This is the kind of behaviour I would intuitively expect from such a data structure and I strongly suspect that Guava behaves the same way, also for collected soft references.

Note that the Java Collections library only provides a weak key / normal values map, not weak keys /soft values or weak keys / weak values, as the user can do the value wrapping themself (but cannot do likewise with the keys as the lookup in a hashmap should not be expected to work the same way for the actual keys and weak references to the keys).

I myself used a WeakHashMap once to associate objects that could become obsolete by a mechanism somewhere else with information unrelated to that mechanism (to be exact: moving balls that could be destroyed by certain collisions with information on their recent movement). These values were created specifically for that map and not referenced elsewhere (except locally in methods that could only be called while their keys still existed). Thus, there was no need to use anything other than normal references to the values as when the key became obsolete, the value would become unreferenced and garbage-collectible.