欢迎！请查看关于页面以了解更多关于如何使用本服务的详细信息。
c.c/hash始终为Java集合使用hashCode，这与使用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添加一个特殊情况，就像它现在对Strings所做的那样。
关于这个话题在Clojure群组的讨论链接： https://groups.google.com/forum/#!topic/clojure/dQhdwZsyIEw
评论者：alexmiller
没有补丁的等效时间是什么？
如果我们用 instanceof 来代替直接使用 hasheq，为不同类型重载会怎样？
评论者：michalmarczyk
重载方法是在静态解析的，所以在Object的重载中测试类型是无法避免的。
可以更具体地选择用于加速特定参数类型哈希的重载，给出类型提示或对字面量而言，因为编译器会根据适当的编译时信息调用该重载。然而，在映射/集合操作中的"隐式"哈希并没有任何加速。
评论者：[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。
这个问题又出现了，详细信息请参考 http://dev.clojure.org/jira/browse/DFRS-7
评论者：mpenet
今天这问题又让我头疼了（在解决这个问题之前浪费了很多时间）。我们能否为 1.7 提供一个补丁？
据我所知，我们仍在寻找一种具有可接受性能影响的解决方案，然后才能考虑这个问题。
虽然我们不反对解决这个问题，但我们不希望以牺牲我们在比较中更关心的性能为代价，而且目前的所有建议都不符合这个标准。目前，我将这个问题移至待办事项列表，但如果出现解决方案，我会将其取出。
