String 源码探究

Posted 2020-10-25 handsomecui

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了String 源码探究相关的知识，希望对你有一定的参考价值。

起因：忽然想到平时用的HashMap 当key是字符串的时候为什么总可以覆盖，然后看了String的源码发现：

private final char value[];

private int hash; // Default to 0

hashCode方法：

public int hashCode() {
        int h = hash;
        if (h == 0 && value.length > 0) {
            char val[] = value;

            for (int i = 0; i < value.length; i++) {
                h = 31 * h + val[i];
            }
            hash = h;
        }
        return h;
    }

equals方法：

public boolean equals(Object anObject) {
        if (this == anObject) {
            return true;
        }
        if (anObject instanceof String) {
            String anotherString = (String)anObject;
            int n = value.length;
            if (n == anotherString.value.length) {
                char v1[] = value;
                char v2[] = anotherString.value;
                int i = 0;
                while (n-- != 0) {
                    if (v1[i] != v2[i])
                        return false;
                    i++;
                }
                return true;
            }
        }
        return false;
    }

很显然hashCode和eques方法都是根据char[]数组中的char判断的，但是hashCode函数里面为什么是

h = 31 * h + val[i];这个数字为什么选择31吶，引起了我的兴趣。

下面是知乎上的回答：

The value 31 was chosen because it is an odd prime. If it were even and the multiplication overflowed, information would be lost, as multiplication by 2 is equivalent to shifting. The advantage of using a prime is less clear, but it is traditional. A nice property of 31 is that the multiplication can be replaced by a shift and a subtraction for better performance: 31 * i == (i << 5) - i. Modern VMs do this sort of optimization automatically.
设计者选择 31 这个值是因为它是一个奇质数。如果它是一个偶数，在使用乘法当中产生数值溢出时，原有数字的信息将会丢失，因为乘以二相当于位移。
选择质数的优势不是那么清晰，但是这是一个传统。31 的一个优良的性质是：乘法可以被位移和减法替代： 31 * i == (i << 5) - i
现代的 VM 可以自行完成这个优化。

As Goodrich and Tamassia point out, If you take over 50,000 English words (formed as the union of the word lists
 provided in two variants of Unix), using the constants 31, 33, 37, 39, and 41 will produce less than 7 collisions 
in each case. Knowing this, it should come as no surprise that many Java implementations choose one of these constants.
Coincidentally, I was in the middle of reading the section "polynomial hash codes" when I saw this question.
正如 Goodrich 和 Tamassia 指出的那样，如果你使用 31，33， 37，39 和 41 这几个数值，将其应用于 hashCode 的算法中，每一个数字对超过 
50000 个英语单词（由两个 Unix 版本的字典的并集构成）产生的 hash 只会产生少于 7 个的冲突。知道了这个之后，Java 大多数的发行版均会使用这几个
数值之一的事实对你也不会显得奇怪了。巧合的是，我是在阅读『多项式哈希值』这一个章节的时候看到这个问题的。

可是为什么java可以s="abcd"这样直接赋值吶？难道和c语言里面的重载一样吗？

但是否定的：

因为从语言一级来看，java不支持运算符重载，这点是肯定的。

String类的”=”,”+”,”+=”，看似运算符重载，实际不是，只是在java编译器里做了一点手脚。
java编译器对String的运算符做了特殊处理。

例如：
String s = “a”;
s += “b”;
编译器转换成了：
String s = “a”;
s = (new StringBuilder()).append(s).append(“b”).toString();

HashSet: 继承的AbstractSet内

public int hashCode() {
        int h = 0;
        Iterator<E> i = iterator();
        while (i.hasNext()) {
            E obj = i.next();
            if (obj != null)
                h += obj.hashCode();
        }
        return h;
    }

Integer：

public int hashCode() {
    return hashCode(this.value);
  }

  public static int hashCode(int var0) {
    return var0;
  }

Double:

public int hashCode() {
    return hashCode(this.value);
  }

  public static int hashCode(double var0) {
    long var2 = doubleToLongBits(var0);
    return (int)(var2 ^ var2 >>> 32);
  }