有必要重写 Java 基本类型的 hashcode 吗，比如 String 用到的 31，官方已经优化的很好了吧。
如果是求对象的哈希，就递归调用成员的 hashcode，再把他们加在一起，还有比这个更好的方案吗？
This topic created in 2351 days ago, the information mentioned may be changed or developed.
 | 1 OhYee Dec 3, 2019 先把对象成员的值转换成字节数组再对整个字节数组做哈希碰撞概率应该会更低一点（但是感觉不太必要） 真的怕碰撞，可以换成别的哈希函数来实现哈希，比如 SHA3，或者自己魔改下 SHA，把输出长度拓展到更长 |
 | 2 reus Dec 3, 2019 sha256 够了，还怕就 sha512。 就，如果你找到了一个冲突，可以出名那种。 |
 | 3 crclz Dec 3, 2019 |
 | 4 wangyzj Dec 3, 2019 我看到了一个好大的轮子 |
 | 5 geelaw Dec 3, 2019 @reus #2 Java 的 hash code 是 32 位，但 SHA-256/512 的输出远远长于 32 位 实际上一个很快速的策略是使用 AES + 固定 key + 截断，因为现代 CPU 有 AES 指令，所以这个可以非常非常快。此外，通常数据如果没有 adversarial behavior，那么 AES hash 的碰撞率比较低。 把数个成员的 hash 加在一起是一个非常糟糕的方案，比如 class X { int a, b; /* details omitted */ } 那么 (1,0) 和 (0,1) 一定会有相同的 hash。 |
 | 6 xupefei Dec 3, 2019 via iPhone 用多级哈希。现成的实现是 bloom filter。 |
 | 7 zunceng Dec 3, 2019 当年听人吹过暴雪有个 hash 算法 从来没用上过 |
 | 8 Raymon111111 Dec 3, 2019 楼主的意思是针对任意的槽大小, hash 结果可以均匀分布吧 |
 | 9 hzgit Dec 3, 2019 我看到了一个好大的轮子 |
 | 10 fluorinedog Dec 4, 2019 via Android 用 hash_combine 算法，别自己造轮子 |
Select Language