java - 调试器中的 hashCode 值与 Netbeans 8.2 中的输出不同

Question

    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
     */

我的环境问题出在哪里 netbeans 8.2 jdk 1.8

Answer 1

字符串“Naveen”的实际hashCode确实是-1968696341，并且在specification之前必须始终如此。 (尽管有相反的评论)。

HashMap 实现不直接使用键的 hashCode 值。相反，它使用公式 h ^ (h >>> 16)“扩展”位，以便使用高阶位来帮助减少冲突。如果将此公式应用于字符串的 hashCode，结果为 -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);
    }