Java集合中的哈希不一致

Question

c.c/hash总是会使用hashCode对Java集合进行哈希，这与使用Murmur3的Clojure集合不兼容。

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

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

有关此主题在Clojure群组中的讨论链接：https://groups.google.com/forum/#!topic/clojure/dQhdwZsyIEw

Answer 1

_Comment made by: michalmarczyk_

为了完整性，直接在{{hasheq}}中对{{Map}}、{{Set}}等分支，就像 joself 的原始补丁一样，在我的前一个评论中引入了以下微基准测试的时间

|xor|315.866626 ns|
|juhm|18.520133 µs|

Answer 2

_Comment made by: michalmarczyk_

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

Java映射项并没有真正集成到Clojure中 - 你不能像 vectors 一样使用它们，不能对它们调用{{seq}}等 - 因此，只要 j.u.maps 保持不变，我认为它们不需要在 hasheq 中与 Clojure 映射项匹配。

时间

|xor|233.341689 ns|
|juhm|9.104637 µs|

Answer 3

_Comment made by: michalmarczyk_

在行内检查Map/Iterable似乎不会对xor基准测试的结果产生很大影响，但会使juhm散列更快。这对我来说相当出人意料。无论如何，这里有一个新的补丁（0007）和时间

|xor|233.062337 ns|
|juhm|8.629149 µs|

Answer 4

评论者：alexmiller

没有补丁的等效时间是多少？

Answer 5

_Comment made by: michalmarczyk_

它们在提及基准测试的评论中的表中列出 - xor为148.128748 ns，juhm为1.701640 µs。

Answer 6

评论者：alexmiller

如果我们不使用instanceof，而是为不同类型覆盖hasheq，会怎样？

Answer 7

评论者：michalmarczyk

重载方法是在编译时解决的，所以在Object重载中测试类型是无法避免的。

如果给定类型提示或字面量，可以使用更具体的重载来加快针对参数类型的散列速度，因为编译器会根据合适的编译时信息发出对该重载的调用。但是，在散列映射/设置操作中的"隐式"散列不会有任何加速。

Answer 8

评论者：[email protected]

当从1.5.1升级到1.6的Factual/skuld时，clojure.data.fressian将c.l.PersistentHashSet集合序列化为java.util.HashSet。这破坏了在https://github.com/Factual/skuld/blob/b720feb142e6d274e85be208dc1d6d8634801719/test/skuld/net_test.clj#L8-L29中的等性检查，因为我们比较的集合中包含一个PersistentSet，而序列化和反序列化的集合包含一个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报告）