有没有理由不使用Java8的ParallelSort？

Question

我读到这个关于Java的arrays.sort和arrays.parallelsort之间的区别的问题，后者已经有几年的历史了。让我吃惊的是，只有一个问题提到了使用ParallelSort的任何缺点；也就是说,如果使用大量CPU,加速比就会降低。

假设您不在某种特殊的单线程环境中，是否应该始终选择parallelsort？有什么理由不这样做吗？请注意，上面问题的一个答案提到，如果元素少于4096个，ParallelSort将直接调用Sort。

Answer 1

使用数组有一些缺点。ParallelSort

• 它使用ForkJoinPool.CommonPool()，并且会与默认情况下使用它的其他函数（例如，流上的Parallel())
• 线程池Arrays.ParallelSort使用的线程池是不可配置的（仅在全局级别上通过增加公共池线程数量）
• 它在小数据集上的性能更差（数组通常包含很少的元素，JDK甚至承认，例如，大多数arraylist在它们的整个生存期内都是空的，这为不实例化永远不会填充的数组节省了相当多的内存和CPU时间）

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

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

编辑：如果给定数组的元素少于4096个，即使arrays.parallelsort切换到普通排序：这完全是为了显示意图--如果可能，您需要一个并行排序，它的意义与调用sort不同。挑剔一点：它确实在小数组上表现更差，因为它必须进行额外的检查，如果数组包含的元素少于4096个，以及一些关于公共池线程计数的其他检查（这当然是可以忽略不计的开销）：）。