羣集中的計算機之間的Java和string.hashCode（）穩定性

Question

我已經在.NET中請求similar question瞭解string.GetHashCode()方法。從那時起，我已經瞭解到，如果我們要在不同的機器上使用哈希代碼，我們不能依賴隱式實現哈希代碼。因此，我假設String.hashCode()的Java實現在不同的硬件配置下也不穩定，並且可能在不同的虛擬機之間表現不同（不要忘記不同的虛擬機實現）

目前我們正在討論一種安全地將字符串轉換爲通過哈希計算，但散列算法必須在羣集的不同節點上保持穩定，並且要快速評估，因爲使用頻率很高。我的隊友堅持使用原生方法，我需要一些合理的論據讓他們重新考慮另一種方法。目前，我只能想到機器配置（x86和x64）與可能不同的某些機器上JVM的供應商（我們的情況幾乎不適用）和字節順序差異（取決於算法所在的機器）之間的差異跑。當然，字符編碼也可能被考慮。儘管所有這些東西都出現在我的腦海中，但我不能100％肯定他們兩個都有足夠的理由，我很感謝你在這方面的專業知識和經驗。這將幫助我建立更有力的論據來支持編寫自定義哈希算法。此外，我很感謝什麼不執行實施它時。

Answer 1

的String.hashCode()實施是文檔中specified，所以它的保證是一致的：

在字符串對象的哈希碼被使用INT算術，其中s計算爲

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

[i]是字符串的第i個字符，n是字符串的長度，^表示取冪。 （空字符串的散列值爲零）

所有這些操作都是針對Java平臺獨立實現的 - 例如，平臺字節順序無關緊要。

也就是說，得到 a String的方法可能會很棘手，如果你從文件或其他字節來源獲得它。在這種情況下，只要您明確指定Charset即可。 （請記住，String都不具備的不同編碼本身;編碼是轉換一個byte[]和String之間的規範。）

Answer 2

你可以看看sourcecode, also shown below。從我所能看到的（經過10秒鐘的分析）之後，這應該在機器和架構中保持穩定。路易斯通過引用一個規範來證實這一點，如果你相信規格，那就更好了。 :-)

但是，如果不同的JRE選擇以不同的方式實施並違反規範，則可能會有所不同。

public int hashCode() { 
    int h = hash; 
    if (h == 0) { 
     int off = offset; 
     char val[] = value; 
     int len = count; 

     for (int i = 0; i < len; i++) { 
      h = 31*h + val[off++]; 
     } 

     hash = h; 
    } 

    return h; 
}