clojure.core/sort在支持数组背衬的Java集合上不是线程安全的

Question

如果将一个（可变的）Java集合（其暴露其背衬数组）传递给c.c/sort多线程，该集合将在多个线程中同时修改。

`
user=> (def q (java.util.concurrent.ArrayBlockingQueue. 1))

'user/q

user=> (future (loop [] (.add q 1) (.remove q 1) (recur)))

object[clojure.core$future_call$reify__4393 0x4769b07b {:status :pending, :val nil}]

user=> (take 3 (distinct (repeatedly #(sort q))))
((1) () nil)
`

方法：在将其转换为数组之前将coll转换为序列，从而保留原始集合。

补丁： 0001-CLJ-1763-make-sort-thread-safe.patch

替代方案

1. 在sort中记录，与Java数组类似，由数组支持的Java集合是在原地修改的。
2. 将RT.toArray()更改为从（非IPersistentCollection）Java集合返回的数组进行防御性副本。这个方法从多个路径调用，因此具有许多潜在的后果。
3. 对于非Clojure集合，也可以使用Collections.sort()代替将它们倒入数组并使用Arrays.sort()。

Answer 1

评论者：alexmiller

文档字符串说“如果coll是Java数组，它将被修改。为了避免这种情况，排序数组的副本。”这在此情况下也是一种很好的建议。

创建输入集合的序列视图将显著改变性能特征。

Answer 2

评论者：alexmiller

我想说的是，我们不应该为了使任意Java集合更安全而牺牲持久集合的性能。但是，在不影响持久集合性能和/或更新文档字符串的情况下使它更安全可能仍然有用。

Answer 3

评论者：bronsa

Alex，没有创建额外的序列，seq调用已经在那里了

Answer 4

评论者：alexmiller

嗯，这在某种程度上是正确的。前面的用法并没有强制整个seq的实现，只是第一个元素。话虽如此，从快速测试来看，在集合上额外成本似乎很小（由于它们的结构，vector seqs实际上更快）。

Answer 5

评论者：stu

我认为这应该是一个docstring更改，如果需要进行任何更改的话。

Answer 6

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