org.springframework.cache.interceptor.DefaultKeyGenerator is implemented by calculating the hashcode of all arguments. This is problematic in many cases:
- methods with similar signature - foo(int, String), foo(int, List) - if the 2nd argument is null they will get mixed
- methods with the same signature in different classes, using the same cache - they will get mixed
- is there a collision resolution mechanism? If not, things will randomly fail. Rarely, but they will. Imagine that the arguments of two distinct methods (that use the same cache region) evaluate to the same hashcode (not unlikely) - they will override each other's values, and possibly a ClassCastException will occur on retrieval
What is in the first place the reason to get the hashcodes? The underlying cache mechanism is a hashtable of some sort, so it will calculate the hash of the key anyway. But it will have a collision-resolution strategy, unlike the KeyGenerator.
- concatenating the string representations of primitives, and the hashcode of non-primitives.
- adding the class name and method name to the key
- optionally, where non-primitive values are used as keys, log a warning - this is usually wrong, as the hashcode will change even though the values inside the object are the same