调试器中的 hashCode 值与 netbeans 8.2 中的输出不同

hashCode values not same in debugger and output in netbeans 8.2

    Map<String, Integer> map = new HashMap<>();
    map.put("Naveen", 100);
    System.out.println("Naveen".hashCode());
    /* output (-1968696341) so index=(-1968696341&15)=11
    but in netbeans 8.2 and jdk 1.8 debugger hashcode = -1968662205
    so the index=(-1968662205&15)=3
     */

我的环境哪里出了问题 网豆 8.2 jdk 1.8

字符串 "Naveen" 的实际 hashCode 确实是 -1968696341,并且 specification 必须始终如此(尽管有相反的评论)。

HashMap 实现不直接使用键的 hashCode 值。相反,它使用公式 h ^ (h >>> 16) 来“展开”这些位,以便使用高阶位来帮助减少冲突。如果将此公式应用于字符串的哈希码,结果为 -1968662205,与您在调试器中看到的相匹配。

此 JDK 8 代码是 here,以及评论中的解释,为方便起见在此处引用。

    /**
     * Computes key.hashCode() and spreads (XORs) higher bits of hash
     * to lower.  Because the table uses power-of-two masking, sets of
     * hashes that vary only in bits above the current mask will
     * always collide. (Among known examples are sets of Float keys
     * holding consecutive whole numbers in small tables.)  So we
     * apply a transform that spreads the impact of higher bits
     * downward. There is a tradeoff between speed, utility, and
     * quality of bit-spreading. Because many common sets of hashes
     * are already reasonably distributed (so don't benefit from
     * spreading), and because we use trees to handle large sets of
     * collisions in bins, we just XOR some shifted bits in the
     * cheapest possible way to reduce systematic lossage, as well as
     * to incorporate impact of the highest bits that would otherwise
     * never be used in index calculations because of table bounds.
     */
    static final int hash(Object key) {
        int h;
        return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
    }