Question

32位和64位版本的string.GetHashCode（）之间存在差异的技术原因是什么？

更重要的是，为什么64位版本在遇到NUL字符时似乎终止了它的算法？例如，在64位CLR下运行时，以下表达式都返回true。

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

当我们将这些字符串用作词典中的键时，这种行为（错误？）表现为性能问题。

Answer 1

这看起来像微软无法修复：

的已知问题

正如你所提到的，对于某些程序而言，这将是一个重大变化（即使它们不应该真的依赖于此），在当前版本中，这种风险被认为太高而无法解决这个问题。

我同意这将导致默认字典＆lt; String，Object＆gt;中出现的冲突率将被夸大。如果这会对您的应用程序性能产生负面影响，我建议尝试使用一个带有IEqualityComparer的Dictionary构造函数来解决它，以便您可以提供更合适的GetHashCode实现。我知道这不是理想的，并希望在未来的.NET Framework版本中修复此问题。

来源：Microsoft Connect - String.GetHashCode ignores any characters in the string beyond the first null byte in x64 runtime

Answer 2

Eric lippert有一个精彩的博客 Curious property in String

Curious property Revealed

为什么String.GetHashCode（）在32位和64位版本的CLR中实现不同？

2 个答案: