Java – provides two different class instances of the same hashcode

I encountered a strange problem on the JBoss server, where two classes generated the same hashcode ()

Class<?> cl1 = Class.forName("fqn.Class1");
Class<?> cl2 = Class.forName("fqn.Class2");
out.println(cl1.getCanonicalName());
out.println(cl2.getCanonicalName());
out.println(cl1.hashCode());
out.println(cl2.hashCode());
out.println(System.identityHashCode(cl1));
out.println(System.identityHashCode(cl2));
out.println(cl1 == cl2);
out.println(cl1.equals(cl2));
out.println(cl1.getClassLoader().equals(cl2.getClassLoader()));

Production:

fnq.Class1
fnq.Class2
494722
494722
494722
494722
false
false
true

I don't usually care, but we're using a framework that uses a key consisting of a hash code of class and property names to cache setters This is a bad design of caching, but it cannot be controlled at present (ognl 3.0.6 fixes this problem in the latest struts 2.3.24, see source. A newer ognl, but struts will not be in beta until 2.5.)

This question makes me a little strange

>The problem occurs a few days after use. I'm sure that during this time, classes / attributes are cached This leads me to believe that class instance hash codes are actually changing... They become equal in a few days. > We have observed a very outdated hotspot 1.6 behavior, now in 1.7 0_ 80. Both are 32-bit builds on Sun SPARC > JVM report - XX: hashcode is "0"

I read that the RNG hash code generator ("0" policy) in hotspot can generate duplicate if there are racing threads, but I can't imagine that class loading triggers this behavior

When creating a class instance, does hotspot use a special hash code?

Solution

> java. Lang. class does not override hashcode, and the JVM does not handle it specifically This is just from Java General identity inherited by lang.Object hashcode