意外的可伸缩性导致Java Fork-Join（Java 8）

Question

最近，我正在使用Java Fork-Join进行一些可伸缩性实验。 在这里，我使用了非默认的ForkJoinPool构造函数ForkJoinPool(int parallelism) ，将所需的并行性（＃worker）作为构造函数参数传递。

具体来说，使用以下代码：

public static void main(String[] args) throws InterruptedException {
    ForkJoinPool pool = new ForkJoinPool(Integer.parseInt(args[0]));
    pool.invoke(new ParallelLoopTask());    
}

static class ParallelLoopTask extends RecursiveAction {

    final int n = 1000;

    @Override
    protected void compute() {
        RecursiveAction[] T = new RecursiveAction[n];
        for(int p = 0; p < n; p++){
            T[p] = new DummyTask();
            T[p].fork();
        }
        for(int p = 0; p < n; p++){
            T[p].join();
        }
        /*
        //The problem does not occur when tasks are joined in the reverse order, i.e.
        for(int p = n-1; p >= 0; p--){
            T[p].join();
        }
        */
    }
}


static public class DummyTask extends RecursiveAction {
    //performs some dummy work

    final int N = 10000000;

    //avoid memory bus contention by restricting access to cache (which is distributed)
    double val = 1;

    @Override
    protected void compute() {
        for(int j = 0; j < N; j++){
            if(val < 11){
                val *= 1.1;
            }else{
                val = 1;
            }
        }
    }
}

我在具有4个物理和8个逻辑内核的处理器上获得了这些结果（使用Java 8：jre1.8.0_45）：

T1：11730

T2：2381（加速：4,93）

T4：2463（加速：4,76）

T8：2418（加速：4,85）

当使用Java 7（jre1.7.0）时，我得到

T1：11938

T2：11843（加速：1,01）

T4：5133（加速：2,33）

T8：2607（加速：4,58）

（其中TP是执行时间，以毫秒为单位，使用并行度P）

虽然这两个结果都令我感到惊讶，但我可以理解后者（联接将导致1个工作程序（执行循环）被阻塞，因为它无法识别它可以在等待时处理其本地队列中的其他未完成的虚拟任务）。 但是，前者让我感到困惑。

顺便说一句：当计算开始但尚未完成的虚拟任务的数量时，我发现某个时间点内并行度为2的池中最多存在24个此类任务...？

编辑：

我使用JMH（jdk1.8.0_45）（选项-bm avgt -f 1）（= 1 fork，20 + 20次迭代）对上述应用程序进行了基准测试

T1：11,664

11,664 ±(99.9%) 0,044 s/op [Average]
(min, avg, max) = (11,597, 11,664, 11,810), stdev = 0,050
CI (99.9%): [11,620, 11,708] (assumes normal distribution)

T2：4,134（加速：2,82）

4,134 ±(99.9%) 0,787 s/op [Average]
(min, avg, max) = (3,045, 4,134, 5,376), stdev = 0,906
CI (99.9%): [3,348, 4,921] (assumes normal distribution)

T4：2,972（加速：3,92）

2,972 ±(99.9%) 0,212 s/op [Average]
(min, avg, max) = (2,375, 2,972, 3,200), stdev = 0,245
CI (99.9%): [2,759, 3,184] (assumes normal distribution)

T8：2,845（加速比：4,10）

2,845 ±(99.9%) 0,306 s/op [Average]
(min, avg, max) = (2,277, 2,845, 3,310), stdev = 0,352
CI (99.9%): [2,540, 3,151] (assumes normal distribution)

乍一看，人们会认为这些可伸缩性结果更接近人们的预期，即T1 <T2 <T4〜T8。 但是，仍然困扰我的是以下内容：

1. Java 7和8之间T2的区别。我猜一个解释是，执行并行循环的工作程序不会在Java 8中变为空闲状态，而是找到其他要执行的工作。
2. 2名工人的超线性加速（3倍）。 另外，请注意，T2似乎随着每次迭代都增加（请参见下文，请注意，尽管P = 4,8的程度较小，情况也是如此）。 预热的第一次迭代中的时间与上面提到的时间相似。 也许预热时间应该更长一些，但是执行时间增加并不奇怪，例如，我希望它减少吗？
3. 最后，我仍然发现，启动和未完成的虚拟任务比工作线程好奇的多。

>

Run progress: 0,00% complete, ETA 00:00:40
Fork: 1 of 1
Warmup Iteration   1: 2,365 s/op
Warmup Iteration   2: 2,341 s/op
Warmup Iteration   3: 2,393 s/op
Warmup Iteration   4: 2,323 s/op
Warmup Iteration   5: 2,925 s/op
Warmup Iteration   6: 3,040 s/op
Warmup Iteration   7: 2,304 s/op
Warmup Iteration   8: 2,347 s/op
Warmup Iteration   9: 2,939 s/op
Warmup Iteration  10: 3,083 s/op
Warmup Iteration  11: 3,004 s/op
Warmup Iteration  12: 2,327 s/op
Warmup Iteration  13: 3,083 s/op
Warmup Iteration  14: 3,229 s/op
Warmup Iteration  15: 3,076 s/op
Warmup Iteration  16: 2,325 s/op
Warmup Iteration  17: 2,993 s/op
Warmup Iteration  18: 3,112 s/op
Warmup Iteration  19: 3,074 s/op
Warmup Iteration  20: 2,354 s/op
Iteration   1: 3,045 s/op
Iteration   2: 3,094 s/op
Iteration   3: 3,113 s/op
Iteration   4: 3,057 s/op
Iteration   5: 3,050 s/op
Iteration   6: 3,106 s/op
Iteration   7: 3,080 s/op
Iteration   8: 3,370 s/op
Iteration   9: 4,482 s/op
Iteration  10: 4,325 s/op
Iteration  11: 5,002 s/op
Iteration  12: 4,980 s/op
Iteration  13: 5,121 s/op
Iteration  14: 4,310 s/op
Iteration  15: 5,146 s/op
Iteration  16: 5,376 s/op
Iteration  17: 4,810 s/op
Iteration  18: 4,320 s/op
Iteration  19: 5,249 s/op
Iteration  20: 4,654 s/op

Answer 1

在您如何进行此基准测试的示例中没有任何内容。 看起来您在运行的开始和结束都只是做了一分钟。 这是不准确的。 我建议您看看这个SO答案，然后重新发布您的时间安排。 顺便说一句，jmh基准测试将成为Java9中的标准，因此您应该使用它。

编辑：

您承认可伸缩性结果符合您的预期。 但是您说您仍然对结果不满意。 现在该看一下代码内部了。

该框架存在严重问题。 自2010年以来，我一直在对此进行评论。正如我在这里指出的那样，join不起作用。 作者尝试了各种方法来解决该问题，但问题仍然存在。

将您的运行时间增加到一分钟左右（n = 100000000）或在compute（）中进行大量计算。 现在在VisualVM或其他探查器中探查应用程序。 这将向您显示停滞线程，过多线程等。

如果那不能帮助您回答问题，则应使用调试器查看代码流。 分析/代码分析是您获得满意答案的唯一途径。