c# - 为什么 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

这看起来像是一个已知问题，Microsoft 不会修复:

As you have mentioned this would be a breaking change for some programs (even though they shouldn't really be relying on this), the risk of this was deemed too high to fix this in the current release.

I agree that the rate of collisions that this will cause in the default Dictionary<String, Object> will be inflated by this. If this is adversely effecting your applications performance, I would suggest trying to work around it by using one of the Dictionary constructors that takes an IEqualityComparer so you can provide a more appropriate GetHashCode implementation. I know this isn't ideal and would like to get this fixed in a future version of the .NET Framework.

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