科普：爲何 String hashCode 方法選擇數字31做爲乘子

1. 背景

某天，我在寫代碼的時候，無心中點開了 String hashCode 方法。而後大體看了一下 hashCode 的實現，發現並非很複雜。可是我從源碼中發現了一個奇怪的數字，也就是本文的主角31。這個數字竟然不是用常量聲明的，因此無法從字面意思上推斷這個數字的用途。後來帶着疑問和好奇心，到網上去找資料查詢一下。在看完資料後，默默的感嘆了一句，原來是這樣啊。那麼究竟是哪樣呢？在接下來章節裏，請你們帶着好奇心和我揭開數字31的用途之謎。

2. 選擇數字31的緣由

在詳細說明 String hashCode 方法選擇數字31的做爲乘子的緣由以前，咱們先來看看 String 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;
}

上面的代碼就是 String hashCode 方法的實現，是否是很簡單。實際上 hashCode 方法核心的計算邏輯只有三行，也就是代碼中的 for 循環。咱們能夠由上面的 for 循環推導出一個計算公式，hashCode 方法註釋中已經給出。以下：

s[0]*31^(n-1) + s[1]*31^(n-2) + ... + s[n-1]

這裏說明一下，上面的 s 數組即源碼中的 val 數組，是 String 內部維護的一個 char 類型數組。這裏我來簡單推導一下這個公式：

假設 n=3
i=0 -> h = 31 * 0 + val[0]
i=1 -> h = 31 * (31 * 0 + val[0]) + val[1]
i=2 -> h = 31 * (31 * (31 * 0 + val[0]) + val[1]) + val[2]
       h = 31*31*31*0 + 31*31*val[0] + 31*val[1] + val[2]
       h = 31^(n-1)*val[0] + 31^(n-2)*val[1] + val[2]

上面的公式包括公式的推導並非本文的重點，你們瞭解瞭解便可。接下來來講說本文的重點，即選擇31的理由。從網上的資料來看，通常有以下兩個緣由：

第一，31是一個不大不小的質數，是做爲 hashCode 乘子的優選質數之一。另一些相近的質數，好比3七、4一、43等等，也都是不錯的選擇。那麼爲啥恰恰選中了31呢？請看第二個緣由。

第2、31能夠被 JVM 優化，31 * i = (i << 5) - i。

上面兩個緣由中，第一個須要解釋一下，第二個比較簡單，就不說了。下面我來解釋第一個理由。通常在設計哈希算法時，會選擇一個特殊的質數。至於爲啥選擇質數，我想應該是能夠下降哈希算法的衝突率。至於緣由，這個就要問數學家了，我幾乎能夠忽略的數學水平解釋不了這個緣由。上面說到，31是一個不大不小的質數，是優選乘子。那爲啥同是質數的2和101（或者更大的質數）就不是優選乘子呢，分析以下。

這裏先分析質數2。首先，假設 n = 6，而後把質數2和 n 帶入上面的計算公式。並僅計算公式中次數最高的那一項，結果是2^5 = 32，是否是很小。因此這裏能夠判定，當字符串長度不是很長時，用質數2作爲乘子算出的哈希值，數值不會很大。也就是說，哈希值會分佈在一個較小的數值區間內，分佈性不佳，最終可能會致使衝突率上升。

上面說了，質數2作爲乘子會致使哈希值分佈在一個較小區間內，那麼若是用一個較大的大質數101會產生什麼樣的結果呢？根據上面的分析，我想你們應該能夠猜出結果了。就是不用再擔憂哈希值會分佈在一個小的區間內了，由於101^5 = 10,510,100,501。可是要注意的是，這個計算結果太大了。若是用 int 類型表示哈希值，結果會溢出，最終致使數值信息丟失。儘管數值信息丟失並不必定會致使衝突率上升，可是咱們暫且先認爲質數101（或者更大的質數）也不是很好的選擇。最後，咱們再來看看質數31的計算結果： 31^5 = 28629151，結果值相對於32和10,510,100,501來講。是否是很nice，不大不小。

上面用了比較簡陋的數學手段證實了數字31是一個不大不小的質數，是做爲 hashCode 乘子的優選質數之一。接下來我會用詳細的實驗來驗證上面的結論，不過在驗證前，咱們先看看 Stack Overflow 上關於這個問題的討論，Why does Java's hashCode() in String use 31 as a multiplier?。其中排名第一的答案引用了《Effective Java》中的一段話，這裏也引用一下：

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，現代的 Java 虛擬機能夠自動的完成這個優化。

排名第二的答案設這樣說的：

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.

這段話也翻譯一下：

正如 Goodrich 和 Tamassia 指出的那樣，若是你對超過 50,000 個英文單詞（由兩個不一樣版本的 Unix 字典合併而成）進行 hash code 運算，並使用常數 31, 33, 37, 39 和 41 做爲乘子，每一個常數算出的哈希值衝突數都小於7個，因此在上面幾個常數中，常數 31 被 Java 實現所選用也就不足爲奇了。

上面的兩個答案完美的解釋了 Java 源碼中選用數字 31 的緣由。接下來，我將針對第二個答案就行驗證，請你們繼續往下看。

3. 實驗及數據可視化

本節，我將使用不一樣的數字做爲乘子，對超過23萬個英文單詞進行哈希運算，並計算哈希算法的衝突率。同時，我也將針對不一樣乘子算出的哈希值分佈狀況進行可視化處理，讓你們能夠直觀的看到數據分佈狀況。本次實驗所使用的數據是 Unix/Linux 平臺中的英文字典文件，文件路徑爲 /usr/share/dict/words。

3.1 哈希值衝突率計算

計算哈希算法衝突率並不難，好比能夠一次性將全部單詞的 hash code 算出，並放入 Set 中去除重複值。以後拿單詞數減去 set.size() 便可得出衝突數，有了衝突數，衝突率就能夠算出來了。固然，若是使用 JDK8 提供的流式計算 API，則可更方便算出，代碼片斷以下：

public static Integer hashCode(String str, Integer multiplier) {
    int hash = 0;
    for (int i = 0; i < str.length(); i++) {
        hash = multiplier * hash + str.charAt(i);
    }

    return hash;
}
    
/**
 * 計算 hash code 衝突率，順便分析一下 hash code 最大值和最小值，並輸出
 * @param multiplier
 * @param hashs
 */
public static void calculateConflictRate(Integer multiplier, List<Integer> hashs) {
    Comparator<Integer> cp = (x, y) -> x > y ? 1 : (x < y ? -1 : 0);
    int maxHash = hashs.stream().max(cp).get();
    int minHash = hashs.stream().min(cp).get();

    // 計算衝突數及衝突率
    int uniqueHashNum = (int) hashs.stream().distinct().count();
    int conflictNum = hashs.size() - uniqueHashNum;
    double conflictRate = (conflictNum * 1.0) / hashs.size();

    System.out.println(String.format("multiplier=%4d, minHash=%11d, maxHash=%10d, conflictNum=%6d, conflictRate=%.4f%%",
                multiplier, minHash, maxHash, conflictNum, conflictRate * 100));
}

結果以下：

從上圖能夠看出，使用較小的質數作爲乘子時，衝突率會很高。尤爲是質數2，衝突率達到了 55.14%。同時咱們注意觀察質數2做爲乘子時，哈希值的分佈狀況。能夠看得出來，哈希值分佈並非很廣，僅僅分佈在了整個哈希空間的正半軸部分，即 0 ~ 2³¹-1。而負半軸 -2³¹ ~ -1，則無分佈。這也證實了咱們上面斷言，即質數2做爲乘子時，對於短字符串，生成的哈希值分佈性不佳。而後再來看看咱們以前所說的 3一、3七、41 這三個不大不小的質數，表現都不錯，衝突數都低於7個。而質數 101 和 199 表現的也很不錯，衝突率很低，這也說明哈希值溢出並不必定會致使衝突率上升。可是這兩個傢伙一言不合就溢出，咱們認爲他們不是哈希算法的優選乘子。最後咱們再來看看 32 和 36 這兩個偶數的表現，結果並很差，尤爲是 32，衝突率超過了了50%。儘管 36 表現的要好一點，不過和 31，37相比，衝突率仍是比較高的。固然並不是全部的偶數做爲乘子時，衝突率都會比較高，你們有興趣能夠本身驗證。

3.2 哈希值分佈可視化

上一節分析了不一樣數字做爲乘子時的衝突率狀況，這一節來分析一下不一樣數字做爲乘子時，哈希值的分佈狀況。在詳細分析以前，我先說說哈希值可視化的過程。我本來是打算將全部的哈希值用一維散點圖進行可視化，可是後來找了一圈，也沒找到合適的畫圖工具。加以後來想了想，一維散點圖可能不合適作哈希值可視化，由於這裏有超過23萬個哈希值。也就意味着會在圖上顯示超過23萬個散點，若是不出意外的話，這23萬個散點會彙集的很密，有可能會變成一個大黑塊，就失去了可視化的意義了。因此這裏選擇了另外一種可視化效果更好的圖表，也就是 excel 中的平滑曲線的二維散點圖（下面簡稱散點曲線圖）。固然這裏一樣沒有把23萬散點都顯示在圖表上，太多了。因此在實際繪圖過程當中，我將哈希空間等分紅了64個子區間，並統計每一個區間內的哈希值數量。最後將分區編號作爲X軸，哈希值數量爲Y軸，就繪製出了我想要的二維散點曲線圖了。這裏舉個例子說明一下吧，以第0分區爲例。第0分區數值區間是[-2147483648, -2080374784)，咱們統計落在該數值區間內哈希值的數量，獲得 <分區編號, 哈希值數量> 數值對，這樣就能夠繪圖了。分區代碼以下：

/**
 * 將整個哈希空間等分紅64份，統計每一個空間內的哈希值數量
 * @param hashs
 */
public static Map<Integer, Integer> partition(List<Integer> hashs) {
    // step = 2^32 / 64 = 2^26
    final int step = 67108864;
    List<Integer> nums = new ArrayList<>();
    Map<Integer, Integer> statistics = new LinkedHashMap<>();
    int start = 0;
    for (long i = Integer.MIN_VALUE; i <= Integer.MAX_VALUE; i += step) {
        final long min = i;
        final long max = min + step;
        int num = (int) hashs.parallelStream()
                .filter(x -> x >= min && x < max).count();

        statistics.put(start++, num);
        nums.add(num);
    }

    // 爲了防止計算出錯，這裏驗證一下
    int hashNum = nums.stream().reduce((x, y) -> x + y).get();
    assert hashNum == hashs.size();

    return statistics;
}

本文中的哈希值是用整形表示的，整形的數值區間是 [-2147483648, 2147483647]，區間大小爲 2^32。因此這裏能夠將區間等分紅64個子區間，每一個自子區間大小爲 2^26。詳細的分區對照表以下：

分區編號	分區下限	分區上限	分區編號	分區下限	分區上限
0	-2147483648	-2080374784	32	0	67108864
1	-2080374784	-2013265920	33	67108864	134217728
2	-2013265920	-1946157056	34	134217728	201326592
3	-1946157056	-1879048192	35	201326592	268435456
4	-1879048192	-1811939328	36	268435456	335544320
5	-1811939328	-1744830464	37	335544320	402653184
6	-1744830464	-1677721600	38	402653184	469762048
7	-1677721600	-1610612736	39	469762048	536870912
8	-1610612736	-1543503872	40	536870912	603979776
9	-1543503872	-1476395008	41	603979776	671088640
10	-1476395008	-1409286144	42	671088640	738197504
11	-1409286144	-1342177280	43	738197504	805306368
12	-1342177280	-1275068416	44	805306368	872415232
13	-1275068416	-1207959552	45	872415232	939524096
14	-1207959552	-1140850688	46	939524096	1006632960
15	-1140850688	-1073741824	47	1006632960	1073741824
16	-1073741824	-1006632960	48	1073741824	1140850688
17	-1006632960	-939524096	49	1140850688	1207959552
18	-939524096	-872415232	50	1207959552	1275068416
19	-872415232	-805306368	51	1275068416	1342177280
20	-805306368	-738197504	52	1342177280	1409286144
21	-738197504	-671088640	53	1409286144	1476395008
22	-671088640	-603979776	54	1476395008	1543503872
23	-603979776	-536870912	55	1543503872	1610612736
24	-536870912	-469762048	56	1610612736	1677721600
25	-469762048	-402653184	57	1677721600	1744830464
26	-402653184	-335544320	58	1744830464	1811939328
27	-335544320	-268435456	59	1811939328	1879048192
28	-268435456	-201326592	60	1879048192	1946157056
29	-201326592	-134217728	61	1946157056	2013265920
30	-134217728	-67108864	62	2013265920	2080374784
31	-67108864	0	63	2080374784	2147483648

接下來，讓咱們對照上面的分區表，對數字二、三、1七、3一、101的散點曲線圖進行簡單的分析。先從數字2開始，數字2對於的散點曲線圖以下：

上面的圖仍是很一幕瞭然的，乘子2算出的哈希值幾乎所有落在第32分區，也就是 [0, 67108864)數值區間內，落在其餘區間內的哈希值數量幾乎能夠忽略不計。這也就不難解釋爲何數字2做爲乘子時，算出哈希值的衝突率如此之高的緣由了。因此這樣的哈希算法要它有何用啊，拖出去斬了吧。接下來看看數字3做爲乘子時的表現：

3做爲乘子時，算出的哈希值分佈狀況和2很像，只不過稍微好了那麼一點點。從圖中能夠看出絕大部分的哈希值最終都落在了第32分區裏，哈希值的分佈性不好。這個也沒啥用，拖出去槍斃5分鐘吧。在看看數字17的狀況怎麼樣：

數字17做爲乘子時的表現，明顯比上面兩個數字好點了。雖然哈希值在第32分區和第34分區有必定的彙集，可是相比較上面2和3，狀況明顯好好了不少。除此以外，17做爲乘子算出的哈希值在其餘區也均有分佈，且較爲均勻，還算是一個不錯的乘子吧。

接下來來看看咱們本文的主角31了，31做爲乘子算出的哈希值在第33分區有必定的小彙集。不過相比於數字17，主角31的表現又好了一些。首先是哈希值的彙集程度沒有17那麼嚴重，其次哈希值在其餘區分佈的狀況也要好於17。總之，選31，準沒錯啊。

最後再來看看大質數101的表現，不難看出，質數101做爲乘子時，算出的哈希值分佈狀況要好於主角31，有點喧賓奪主的意思。不過不能否認的是，質數101的做爲乘子時，哈希值的分佈性確實更加均勻。因此若是不在乎質數101容易致使數據信息丟失問題，或許其是一個更好的選擇。

4.寫在最後

通過上面的分析與實踐，我想你們應該明白了 String hashCode 方法中選擇使用數字31做爲乘子的緣由了。本文本質是一篇簡單的科普文而已，並無銀彈😁。若是你們讀完後以爲又漲知識了，那這篇文章的目的就達到了。最後，本篇文章的配圖畫的仍是很辛苦的，因此若是你們以爲文章不錯，不妨就給個贊吧，就當是對個人鼓勵了。另外，若是文章中有不妥或者錯誤的地方，也歡迎指出來。若是能不吝賜教，那就更好了。最後祝你們生活愉快，再見。

本文在知識共享許可協議 4.0 下發布，轉載請註明出處
做者：coolblog
爲了得到更好的分類閱讀體驗，
請移步至本人的我的博客： http://www.coolblog.xyz

本做品採用知識共享署名-非商業性使用-禁止演繹 4.0 國際許可協議進行許可。