[英]Why is String.GetHashCode() implemented differently in 32-bit and 64-bit versions of the CLR?
string.GetHashCode()的32位和64位版本之间的差异背后的技术原因是什么?
更重要的是,为什么64位版本在遇到NUL字符时似乎终止了它的算法? 例如,在64位CLR下运行时,以下表达式都返回true。
"\0123456789".GetHashCode() == "\0987654321".GetHashCode()
"\0AAAAAAAAA".GetHashCode() == "\0BBBBBBBBB".GetHashCode()
"\0The".GetHashCode() == "\0Game".GetHashCode()
当我们将这样的字符串用作Dictionary中的键时,这种行为(bug?)表现为性能问题。
这看起来像微软无法修复的已知问题:
正如你所提到的那样,对于某些程序来说这将是一个重大变化(即使它们不应该真的依赖于此),这种风险被认为太高而无法在当前版本中解决这个问题。
我同意这将在默认的Dictionary <String,Object>中导致的冲突率将由此膨胀。 如果这会对您的应用程序性能产生负面影响,我建议尝试使用一个带有IEqualityComparer的Dictionary构造函数来解决它,以便您可以提供更合适的GetHashCode实现。 我知道这不太理想,并希望在未来的.NET Framework版本中修复此问题。
源: Microsoft Connect - String.GetHashCode忽略x64运行时中第一个空字节之外的字符串中的任何字符
Eric lippert 在String的这个Curious属性中有一个很棒的博客
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.