你想要做的就是在一个很好的扩展位上,特别是对于普通值(如果任何值比其他值更常见).除了格式的特殊知识之外,那么使用字符串本身的哈希码就是最好的.

特别了解您的id格式的限制,可能会自定义并导致更好的性能,尽管虚假假设更有可能使事情变得更好.

编辑：在良好的位传播.

如这里和其他答案所述,完全独特的是不可能的,哈希冲突是可能的.哈希使用方法知道这一点,可以处理它,但它会影响性能,所以我们希望碰撞是罕见的.

此外,散列通常被重新散列,因此我们的32位数可能最终减少到例如.一个在0到22之间,我们希望尽可能好的分配.

我们还想平衡这一点,而不是花费太长的时间来计算我们的哈希,它本身就成为一个瓶颈.一个不完美的平衡行为.

一个坏的哈希方法的典型例子是一个X,Y的坐标对的一个,它是：

return X ^ Y;

尽管在4 ^ 32个可能的输入中返回2 ^ 32个可能的值非常好,但在现实世界中,使用一组坐标(X和Y相等)({0,0},{1,1},{2,2}等等),这些都将哈希到零,或匹配的对({2,3}和{3,2}),它们将散列到相同的数字.我们可能更好地服务于：

return ((X << 16) | (x >> 16)) ^ Y;

现在,与前者相比,这个可怕的价值是可怕的,但在现实世界的情况下往往更好.

当然,如果你正在写一个通用课程(不知道有什么可能的输入),或者更好地了解手头的目的,那就有不同的工作.例如,如果我使用的是Date对象,但是知道它们都只是日期(时间总是在午夜),而且只能在几年之内,那么我可能更喜欢使用仅使用日,月,年龄较低的数字超过标准.日期的作者虽然不能在这样的知识上工作,而是要尽力照顾每一个人.

因此,如果我例如知道一个给定的字符串总是由[az]或[0-9]范围内的6个不区分大小写的字符组成(您似乎是这样,但您的问题不清楚)那么我可以使用一个算法为每个字符分配0到35的值(每个字符的36个可能值),然后遍历字符串,每次将当前值乘以36,并将下一个字符

假设在ids中有很好的传播,这将是方式,特别是如果我做出这样的命令,使得我的哈希中的低位数字与id中最频繁变化的字符匹配(如果可以这样调用),因此幸存的重新哈希到较小的范围.

但是,由于缺乏这种格式的知识,我无法确定地进行这种调用,而且我可以使事情变得更糟(较慢的算法对于散列质量的影响甚微甚至不好).

您拥有的一个优点是,由于它本身是一个ID,所以推测没有其他不相等的对象具有相同的ID,因此不需要检查其他属性.这并不总是持之以恒.