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

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 中导致的冲突率由此膨胀。 如果这会对您的应用程序性能产生负面影响，我建议尝试使用一个带有IEqualityComparer的Dictionary构造函数来解决它，以便您可以提供更合适的GetHashCode实现。 我知道这不是理想的，并希望在未来的.NET Framework版本中修复此问题。

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

Answer 2

Eric lippert 在String的这个Curious属性中有一个很棒的博客

透露好奇的财产