使用 Java 集合时的不一致哈希

Question

c.c/hash 总是使用 hashCode 为 Java 集合生成哈希，当与使用 Murmur3 的 Clojure 集合比较时，是不兼容的。

user=> (== (hash (java.util.ArrayList. [1 2 3])) (hash [1 2 3])) false user=> (= (java.util.ArrayList. [1 2 3]) [1 2 3]) true

修复这个问题的一种方法是在 Util/hasheq 中为 java.util.Collections 添加一个特殊案例，就像它现在对 String 所做的那样。

有关这个主题的 Clojure 小组讨论链接： https://groups.google.com/forum/#!topic/clojure/dQhdwZsyIEw

Answer 1

_评论者：michalmarczyk_

为了完整性，就像 Jozef 的原始补丁那样，直接在 {{hasheq}} 中分支到 {{Map}}, {{Set}} 等，在我的上一个评论中引入的微基准测试中的时间如下

|xor|315.866626 纳秒|
|juhm|18.520133 微秒|

Answer 2

_评论者：michalmarczyk_

新补丁（0006）省略了 {{Map.Entry}} 检查；相反，在 {{Murmur3}} 类中引入了两个方法来处理 j.u.maps。

Java 映射实体并没有真正集成到 Clojure 中--你不能像向量那样使用它们，不能对其调用 {{seq}} 等--所以我认为只要 j.u.maps done

计时

|xor|233.341689 纳秒|
|juhm|9.104637 微秒|

Answer 3

_评论者：michalmarczyk_

检查Map/Iterable的inline实现似乎对xor基准测试结果的影响不大，但使得juhm哈希更快。这让我相当惊讶。无论如何，这里有一个新的补丁（0007）和计时数据

|xor|233.062337纳秒|
|juhm|8.629149微秒|

Answer 4

评论人：alexmiller

补丁未应用时的等效计时是多少？

Answer 5

_评论者：michalmarczyk_

这些数据在介绍基准测试的评论中的表中列出——xor的148.128748纳秒，juhm的1.701640微秒。

Answer 6

评论人：alexmiller

如果我们使用typeof而不是instanceof来覆盖hash eq以处理不同的数据类型，会怎样？

Answer 7

评论人：michalmarczyk

重载方法在静态中解析，所以在Object重载中测试类型是不可避免的。

如果给出了类型提示或对于字面量，可以使用更具体的重载来加速给定参数类型的哈希，因为编译器会根据编译时的适当信息发出对该重载的调用。然而，在哈希图/集操作期间的“隐式”哈希中不会有任何加速。

Answer 8

评论人：[email protected]

这在我将Factual/skuld从1.5.1升级到1.6时出现问题。clojure.data.fressian将c.l.PersistentHashSet集合序列化为java.util.HashSet。这破坏了在以下链接中的等价性检查：

Answer 9

评论人：[email protected]

这个问题又出现在我面前了，详细信息请见 http://dev.clojure.org/jira/browse/DFRS-7

Answer 10

评论者：mpenet

今天这又让我头疼了很久（在解决这个问题之前浪费了很多时间）。我们能否为1.7版本提供一个补丁呢？

Answer 11

评论人：alexmiller

据我所知，我们仍在寻找在此之前可接受的性能影响的解决方案。

Answer 12

评论人：alexmiller

虽然我们不反对解决这个问题，但我们也不愿意以牺牲我们更关心的比较性能的代价来解决，而且目前的所有建议都无法达到那个标准。目前，我将其移至“待办事项”列表，但如果出现解决方案，我将将其拉出来。

Answer 13

参考： https://clojure.atlassian.net/browse/CLJ-1372 （由wagjo报告）