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添加一个特殊案例，就像现在对字符串所做的那样。

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

Answer 1

_评论由：michalmarczyk_发出_

为了完整性，在hasheq中直接在{{Map}}, {{Set}}等进行分支，就像Jozef的原始补丁所做的那样，结果如我前一个评论中引入的微观基准测试

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

Answer 2

_评论由：michalmarczyk_发出_

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

Java映射条目并没有真正集成到Clojure中 -- 您不能像向量一样使用它们，不能在它们上调用{{seq}}等 -- 所以只要j.u.maps做，我认为它们不需要在hasheq中与Clojure映射条目相匹配。

时间

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

Answer 3

_评论由：michalmarczyk_发出_

在行内检查Map/可迭代对象似乎对XOR基准测试结果影响不大，但会使jium hashing更快。这对我来说相当令人惊讶。无论如何，这里有一个新的补丁（0007）和性能时间

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

Answer 4

评论者：alexmiller

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

Answer 5

_评论由：michalmarczyk_发出_

这些在介绍基准测试的评论中的表中列出——xor为148.128748 ns，juhm为1.701640 µs。

Answer 6

评论者：alexmiller

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

Answer 7

评论者：michalmarczyk

重载方法是在静态中解析的，因此在Object的重载中不能避免类型检查。

可以使用更具体的重载来加快对参数类型的哈希处理，前提是有类型提示或字面量，因为编译器将会在编译时提供适当的信息，调用那个重载。然而，在哈希表/集合操作中的“隐式”哈希并没有任何加速。

Answer 8

评论者：[email protected]

当将Factual/skuld从1.5.1升级到1.6时，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报告）