为什么这种并行算法的运行速度比它的顺序算法慢？

Question

顺序：

void do(List<D> d, final List<C> c) {
for (D datum : d)
    getChampoid(datum, c).tally(datum);

平行：

static final int procs = Runtime.getRuntime().availableProcessors();
static final ExecutorService pool = Executors.newFixedThreadPool(procs);
void do(List<D> d, final List<C> c) {
    List<Future> futures = new ArrayList<>();
    for (final D datum : d)
        futures.add(pool.submit(new Runnable() {

            @Override
            public void run() {
                getChampoid(datum, c).tally(datum);
            }

        }));
    for (Future f : futures)
        try {
            f.get();
        } catch (InterruptedException e) {
            e.printStackTrace();
        } catch (ExecutionException e) {
            e.printStackTrace();
        }

我很困惑，因为在我看来，它们看起来完全一样，并行版本应该更快，但速度要慢一个数量级。有什么想法吗？

仅供参考，d 和 c 都是包含数千到数十万项的巨大列表。

Answer 1

并行版本应该更快，

这是一个常见的误解。

但速度要慢一个数量级。

一个共同的结果

有什么想法吗？

使用多个线程会产生一个线程没有的开销。开销可能比实际完成的工作高几个数量级，从而使其慢得多。如果完成的工作远大于开销，您可以获得非常好的可扩展性。

例如假设将任务传递给另一个线程大约需要 10 微秒。如果您的任务需要 1 微秒，那么开销可能会影响您的性能。但是，如果任务需要 100 微秒，您可以看到显着的性能提升，并且值得为此付出代价。

简而言之，没有什么是免费的，尤其是多线程。

Answer 2

A) 您是否排除了任何同步？如果getChampoid 命中同步数据结构（例如哈希表），我不会对性能急剧下降感到惊讶。

B) 对于 Java，对象开销 通常会影响性能。确保使用诸如 VisualVM 之类的分析器。在您的情况下，如果您看到大量时间进入垃圾收集，我不会感到惊讶。

考虑将您的列表d 分解为少量部分，然后在一个线程中处理每个部分。现在，对于每个datum，您将创建一个Runnable 和一个Future 对象，可能还有更多。其中，当d 很大时，意味着垃圾收集器需要做大量工作（在这里，Hotspot 也无法对其进行优化）。