java - 有没有理由不使用 Java 8 的 parallelSort？

Question

我正在阅读 this question关于 Java 的 Arrays.sort 之间的区别和 Arrays.parallelSort ，到现在已经有几年了。令我惊讶的是，只有一个问题提到了使用 parallelSort 的任何缺点；也就是说，如果您使用大量 CPU，则加速会降低。

假设您不在某种专门的单线程环境中，是否应该始终选择parallelSort？有没有理由不这样做？请注意，上述问题的答案之一提到，如果元素少于 4096 个，则 parallelSort 无论如何都会简单地调用 sort。

Answer 1

使用 Arrays.parallelSort

有一些缺点

• 它使用 ForkJoinPool.commonPool() 并会与默认使用它的其他函数(例如流上的 parallel())进行斗争
• Arrays.parallelSort 使用的线程池是不可配置的(仅在全局级别通过增加公共(public)池线程数量)
• 它在小型数据集上表现更差(通常数组包含很少的元素，JDK 甚至承认，例如大多数 ArrayList stay empty for their whole lifetime 这节省了相当多的内存和 CPU 时间实例化永远不会被填充的数组)

还有一个轶事场景:假设您实现了一些需要排序的纸牌游戏。它非常容易并行化多个游戏执行，而不是并行化一次运行的排序机制，这可能只占用整个游戏循环的一小部分。您现在失去了一种简单的并行化方法(例如，在遗传算法的上下文中运行游戏时)。

但是，如果您碰巧有大型数组并且排序是应用程序运行时的重要组成部分，请使用 Arrays.parallelSort。

编辑:即使 Arrays.parallelSort 切换到正常排序，如果给定数组的元素少于 4096:这完全是为了表明意图 - 如果可能的话，你想要一个并行排序，它的含义与调用 排序。并且要吹毛求疵:它确实在小型数组上表现更差，因为它必须额外检查数组是否包含少于 4096 个元素以及一些其他关于公共(public)池线程数的检查(开销当然可以忽略不计):) .