为什么XOR是组合哈希的默认方法？

假设您有两个哈希H(A)，H(B)并且想要将它们组合在一起。我读过，将两个散列组合在一起的一种好方法是XOR，例如XOR( H(A), H(B) )。

这些哈希函数准则在此简要地介绍了我找到的最佳解释：

对具有大致随机分布的两个数字进行异或运算会导致另一个仍具有大致随机分布*的数字，但是现在取决于这两个值。
...
*在要组合的两个数字的每一位，如果两位相等，则输出0，否则为1。换句话说，在50％的组合中，将输出1。因此，如果两个输入位各自有大约50-50的可能性为0或1，那么输出位也是如此。

您能解释为什么XOR应该是用于组合哈希函数（而不是OR或AND等）的默认操作的直觉和/或数学方法吗？

假设均匀随机（1位）输入，AND函数输出概率分布分别为75％0和25％1。相反，OR为25％0和75％1。

XOR函数为50％0和50％1，因此对于组合均匀的概率分布非常有用。

通过写出真值表可以看出：

 a | b | a AND b
---+---+--------
 0 | 0 |    0
 0 | 1 |    0
 1 | 0 |    0
 1 | 1 |    1

 a | b | a OR b
---+---+--------
 0 | 0 |    0
 0 | 1 |    1
 1 | 0 |    1
 1 | 1 |    1

 a | b | a XOR b
---+---+--------
 0 | 0 |    0
 0 | 1 |    1
 1 | 0 |    1
 1 | 1 |    0

练习：两个1位输入具有多少逻辑功能，a并且b具有均匀的输出分布？为什么XOR最适合您提出问题的目的？

xor是在散列时使用的危险的默认函数。它比and和更好or，但这并不多。

xor是对称的，因此元素的顺序丢失了。因此，"bad"哈希组合与相同"dab"。

xor 将成对的相同值映射为零，并且应避免将“公共”值映射为零：

因此，(a,a)被映射为0，(b,b)也被映射为0。由于此类对几乎总是比随机性所暗示的更为普遍，因此最终在零处产生的碰撞要多得多。

遇到这两个问题，xor最终成为一个哈希混合器，看起来表面上还不错，但经过​​进一步检查后却没有。

在现代硬件上，添加速度通常与添加速度差不多xor（公认的，它可能会使用更多功能来实现此目的）。加法运算的真值表与所xor讨论的位类似，但是当两个值均为1时，它还会向下一位发送一个位。这意味着它将删除较少的信息。

因此hash(a) + hash(b)要比hash(a) xor hash(b)if 更好a==b，hash(a)<<1而不是0。

这保持对称；所以"bad"并"dab"得到同样的结果仍然是一个问题。我们可以以适度的成本打破这种对称性：

hash(a)<<1 + hash(a) + hash(b)

又名hash(a)*3 + hash(b)。（hash(a)如果使用班次解决方案，则建议一次计算并存储）。而不是任何奇数常量，3将双射地将一个“ k-bit”无符号整数映射到其自身，因为无符号整数的映射对2^k某些对象而言是数学模k，并且任何奇数常量都相对于2^k。

对于更高级的版本，我们可以检查boost::hash_combine，这实际上是：

size_t hash_combine( size_t lhs, size_t rhs ) {
  lhs ^= rhs + 0x9e3779b9 + (lhs << 6) + (lhs >> 2);
  return lhs;
}

在这里，我们将一些seed带有常数的移位版本加在一起（基本上是随机的0s和1s，尤其是32位固定点分数的黄金分割率的倒数），加上一些加法和一个xor。这打破对称，并介绍了一些“噪声”，如果传入的散列值是差（即，每一个部件散列想象到0 -上述处理得很好，产生的涂抹1和0。s各自结合后我的幼稚3*hash(a)+hash(b)简单地输出一个0在这种情况）。

（对于不熟悉C / C ++的人，a size_t是一个无符号整数值，该值足以描述内存中任何对象的大小。在64位系统上，它通常是64位无符号整数。在32位系统上，一个32位无符号整数。）

尽管XOR具有方便的位混合特性，但由于具有可交换性，因此也不是组合哈希的好方法。考虑一下如果将{1、2，…，10}的置换存储在10元组的哈希表中会发生什么。

更好的选择是m * H(A) + H(B)，其中m是一个大的奇数。

信用：以上组合器是鲍勃·詹金斯的秘诀。

Xor可能是组合哈希的“默认”方式，但是Greg Hewgill的答案也表明了它有陷阱的原因：两个相同哈希值的Xor为零。在现实生活中，存在相同的散列比人们预期的更常见。然后，您可能会发现，在这些（不是那么少见的）极端情况下，所得的组合哈希值始终相同（零）。哈希冲突比您预期的要频繁得多。

在一个人为的示例中，您可能正在组合来自您管理的不同网站的用户的哈希密码。不幸的是，大量用户重复使用了他们的密码，并且产生的哈希值中令人惊讶的比例为零！

我想为找到此页面的其他人明确指出一些内容。AND和OR限制输出，例如BlueRaja-Danny Pflughoe试图指出，但可以更好地定义：

首先，我想定义两个简单的函数来解释这一点：Min（）和Max（）。

Min（A，B）将返回A和B之间较小的值，例如：Min（1，5）返回1。

Max（A，B）将返回在A和B之间较大的值，例如：Max（1，5）返回5。

如果给出： C = A AND B

然后，您会发现C <= Min(A, B)我们知道这一点，因为您无法将A或B的0位与AND设为1。因此，每个零位保持为零位，并且每个位都有机会变为零位（因此值较小）。

带有： C = A OR B

相反的情况是：C >= Max(A, B)这样，我们看到了AND函数的推论。任何已经为1的位都不能被或为0，因此它保持为1，但是每个零位都有机会变为1，从而变成更大的数字。

这意味着输入的状态对输出施加了限制。如果与90进行任何运算，您将知道输出等于或小于90，而不管其他值是多少。

对于XOR，没有基于输入的隐含限制。在某些特殊情况下，您会发现，如果将一个字节与255进行XOR运算，则会得到相反的值，但是可以从中输出任何可能的字节。每一位都有机会根据其他操作数中的同一位更改状态。

如果您XOR是带有偏置输入的随机输入，则输出是随机的。AND或并非如此OR。例：

00101001 XOR 00000000 = 00101001
00101001和00000000 = 00000000
00101001或11111111 = 11111111

正如@Greg Hewgill提到的，即使两个输入都是随机的，使用AND或OR也会导致输出有偏差。

我们之所以使用XOR更复杂的东西，是因为，没有必要： XOR完美地工作，而且速度极快。

覆盖左侧的两列，并尝试仅使用输出确定输入的含义。

 a | b | a AND b
---+---+--------
 0 | 0 |    0
 0 | 1 |    0
 1 | 0 |    0
 1 | 1 |    1

当您看到一个1位时，您应该已经确定两个输入均为1。

现在对XOR执行相同的操作

 a | b | a XOR b
---+---+--------
 0 | 0 |    0
 0 | 1 |    1
 1 | 0 |    1
 1 | 1 |    0

XOR不放弃任何输入。

对于各种版本的源代码hashCode()在java.util.Arrays中为固体，一般使用的散列算法有很大的参考。它们很容易理解，并被翻译成其他编程语言。

粗略地说，大多数多属性hashCode()实现遵循以下模式：

public static int hashCode(Object a[]) {
    if (a == null)
        return 0;

    int result = 1;

    for (Object element : a)
        result = 31 * result + (element == null ? 0 : element.hashCode());

    return result;
}

您可以搜索其他StackOverflow问答，以获取有关背后的魔力31以及Java代码如此频繁使用它的更多信息。它虽然不完美，但是具有非常好的总体性能特征。

XOR不会忽略某些输入，例如OR和AND。

如果以AND（X，Y）为例，并为输入X提供false，则输入Y无关紧要……并且在组合哈希时可能希望输入具有重要性。

如果您采用XOR（X，Y），则两个输入始终很重要。X与Y无关紧要，将没有X的值。如果更改X或Y，则输出将反映出来。