为什么 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()

当我们使用此类字符串作为字典中的键时，此行为（错误？）表现为性能问题。

Answer 1

这看起来像是微软不会修复的已知问题：

正如您所提到的，这对于某些程序来说将是一个重大更改（即使它们不应该真正依赖于此），这种风险被认为太高，无法在当前版本中修复此问题。

我同意这会导致默认字典中的冲突率因此而增加。如果这对您的应用程序性能产生不利影响，我建议您尝试使用采用 IEqualityComparer 的 Dictionary 构造函数之一来解决此问题，以便您可以提供更合适的 GetHashCode 实现。我知道这并不理想，并且希望在 .NET Framework 的未来版本中修复此问题。

来源：Microsoft Connect - String.GetHashCode 在 x64 运行时中忽略字符串中第一个空字节之外的任何字符

Answer 2

Eric lippert 有一个很棒的博客对此 字符串中奇怪的属性

揭晓奇怪的属性