为什么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运行时中第一个空字节之外的字符串中的任何字符