為什么String.GetHashCode（）在32位和64位版本的CLR中實現不同？

Question

string.GetHashCode（）的32位和64位版本之間的差異背后的技術原因是什么？

更重要的是，為什么64位版本在遇到NUL字符時似乎終止了它的算法？ 例如，在64位CLR下運行時，以下表達式都返回true。

"\0123456789".GetHashCode() == "\0987654321".GetHashCode()
"\0AAAAAAAAA".GetHashCode() == "\0BBBBBBBBB".GetHashCode()
"\0The".GetHashCode() == "\0Game".GetHashCode()

當我們將這樣的字符串用作Dictionary中的鍵時，這種行為（bug？）表現為性能問題。

Answer 1

這看起來像微軟無法修復的已知問題：

正如你所提到的那樣，對於某些程序來說這將是一個重大變化（即使它們不應該真的依賴於此），這種風險被認為太高而無法在當前版本中解決這個問題。

我同意這將在默認的Dictionary <String，Object>中導致的沖突率將由此膨脹。 如果這會對您的應用程序性能產生負面影響，我建議嘗試使用一個帶有IEqualityComparer的Dictionary構造函數來解決它，以便您可以提供更合適的GetHashCode實現。 我知道這不太理想，並希望在未來的.NET Framework版本中修復此問題。

源： Microsoft Connect - String.GetHashCode忽略x64運行時中第一個空字節之外的字符串中的任何字符

Answer 2

Eric lippert 在String的這個Curious屬性中有一個很棒的博客

透露好奇的財產