ForkJoinPool性能Java 8 vs 11

Question

考虑以下代码：

package com.sarvagya;

import java.util.Arrays;
import java.util.List;
import java.util.concurrent.ExecutionException;
import java.util.concurrent.ForkJoinPool;
import java.util.stream.Collectors;

public class Streamer {
    private static final int LOOP_COUNT  = 2000;
    public static void main(String[] args){
        try{
            for(int i = 0; i < LOOP_COUNT; ++i){
                poolRunner();
                System.out.println("done loop " + i);
                try{
                    Thread.sleep(50L);
                }
                catch (Exception e){
                    System.out.println(e);
                }
            }
        }
        catch (ExecutionException | InterruptedException e){
            System.out.println(e);
        }

        // Add a delay outside the loop to make sure all daemon threads are cleared before main exits.
        try{
            Thread.sleep(10 * 60 * 1000L);
        }
        catch (Exception e){
            System.out.println(e);
        }
    }

    /**
     * poolRunner method.
     * Assume I don't have any control over this method e.g. done by some library.
     * @throws InterruptedException
     * @throws ExecutionException
     */
    private static void poolRunner() throws InterruptedException, ExecutionException {
        ForkJoinPool pool = new ForkJoinPool();
        pool.submit(() ->{
            List<Integer> numbers = Arrays.asList(1,2,3,4,5,6,7,8,9,10, 11,12,14,15,16);
            List<Integer> collect = numbers.stream()
                    .parallel()
                    .filter(xx -> xx > 5)
                    .collect(Collectors.toList());
            System.out.println(collect);
        }).get();
    }
}

在上面的代码中， poolRunner方法正在创建一个ForkJoinPool并向其提交一些任务。 当使用Java 8并将LOOP_COUNT保持为2000时，我们可以看到创建的最大线程大约为3600，如下所示 图：分析

图：线程信息。

经过一段时间后，所有这些线程都会下降到接近10。 但是，在OpenJDK 11中保持相同的LOOP_COUNT会产生以下错误：

[28.822s][warning][os,thread] Failed to start thread - pthread_create failed (EAGAIN) for attributes: stacksize: 1024k, guardsize: 4k, detached.
[28.822s][warning][os,thread] Failed to start thread - pthread_create failed (EAGAIN) for attributes: stacksize: 1024k, guardsize: 4k, detached.
[28.822s][warning][os,thread] Failed to start thread - pthread_create failed (EAGAIN) for attributes: stacksize: 1024k, guardsize: 4k, detached.
Exception in thread "ForkJoinPool-509-worker-5" java.lang.OutOfMemoryError: unable to create native thread: possibly out of memory or process/resource limits reached
    at java.base/java.lang.Thread.start0(Native Method)
    at java.base/java.lang.Thread.start(Thread.java:803)
    at java.base/java.util.concurrent.ForkJoinPool.createWorker(ForkJoinPool.java:1329)
    at java.base/java.util.concurrent.ForkJoinPool.tryAddWorker(ForkJoinPool.java:1352)
    at java.base/java.util.concurrent.ForkJoinPool.signalWork(ForkJoinPool.java:1476)
    at java.base/java.util.concurrent.ForkJoinPool.deregisterWorker(ForkJoinPool.java:1458)
    at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:187)

它很快达到最大线程限制。 将LOOP_COUNT保持为500，工作正常，但是，这些线程非常缓慢地清除并达到大约500个线程的平台。 见下图：

图：OpenJDK 11中的线程信息

图：OpenJDK中的分析11

线程在JDK 8中是PARKED ，但在JDK 11中是WAIT 。在Java 11中也应该减少守护程序线程的数量，但是它很慢并且不能按预期工作。 而且，假设我无法控制poolRunner方法。 考虑这种方法是由一些外部库提供的。

这是OpenJDK 11的问题，还是我在代码中做错了什么。 谢谢。

Answer 1

你做错了。

在上面的代码中，我正在创建一个ForkJoinPool并向其提交一些任务。

实际上，你正在创建2000个ForkJoinPool实例......

您应该创建一个具有适合当前任务的并行度（即线程数）的ForkJoinPool ，而不是这样做。

创建大量（即数千个）线程是一个非常糟糕的主意。 即使您可以在不触发OOME的情况下执行此操作，您将消耗大量的堆栈和堆内存，并在调度程序和垃圾收集器上施加大量负载......没有任何实际好处。

Answer 2

您的代码正在创建大量的ForkJoinPool实例，并且在使用后永远不会在任何池上调用shutdown() 。 因为在Java 8的情况下，规范中没有任何内容保证工作线程将终止，这个代码甚至可能最终得到2000（⟨ 池数 ⟩）次数cores 核心数量 。

在实践中，观察到的行为源于未记录的两秒空闲超时 。 请注意，根据注释，超时过去的后果是尝试缩小与终止不同的工作者数量 。 因此，如果n线程遇到超时，并非所有n个线程都终止但线程数减少一个，其余线程可能再次等待。 此外，短语“初始超时值”已经暗示了它，实际超时每次发生时都会增加。 因此，由于此（未记录的）超时， n空闲工作线程需要n * ( n + 1)秒才能终止。

从Java 9开始，有一个可配置的keepAliveTime ，可以在ForkJoinPool的新构造函数中指定，它也记录了默认值：

keepAliveTime

自线程终止之前上次使用以来经过的时间（如果需要，稍后再替换）。 对于默认值，请使用60, TimeUnit.SECONDS 。

这个文档可能误导以为现在所有工作线程可能在keepAliveTime空闲时一起终止，但实际上，仍然存在一次只能将池缩小一个的行为，尽管现在，时间没有增加。 所以现在， n空闲工作线程终止需要60 * n秒。 由于之前的行为未指定，因此甚至不兼容。

必须强调的是，即使具有相同的超时行为，最终的最大线程数也可能发生变化，因为具有更好代码优化的较新JVM会减少实际操作的执行时间（无需人为插入Thread.sleep(…) ）它会更快地创建新线程，而终止仍然受到挂钟时间的限制。

---

需要注意的是，当您知道不再需要线程池时，您永远不应该依赖自动工作线程终止。 相反，你应该在完成后调用shutdown() 。

---

您可以使用以下代码验证行为：

int threadNumber = 8;
ForkJoinPool pool = new ForkJoinPool(threadNumber);
// force the creation of all worker threads
pool.invokeAll(Collections.nCopies(threadNumber*2, () -> { Thread.sleep(500); return ""; }));
int oldNum = pool.getPoolSize();
System.out.println(oldNum+" threads; waiting for dying threads");
long t0 = System.nanoTime();
while(oldNum > 0) {
    while(pool.getPoolSize()==oldNum)
        LockSupport.parkNanos(TimeUnit.MILLISECONDS.toNanos(200));
    long t1 = System.nanoTime();
    oldNum = pool.getPoolSize();
    System.out.println(threadNumber-oldNum+" threads terminated after "
        +TimeUnit.NANOSECONDS.toSeconds(t1 - t0)+"s");
}

Java 8：

 8 threads; waiting for dying threads 1 threads terminated after 2s 2 threads terminated after 6s 3 threads terminated after 12s 4 threads terminated after 20s 5 threads terminated after 30s 6 threads terminated after 42s 7 threads terminated after 56s 8 threads terminated after 72s 

Java 11：

 8 threads; waiting for dying threads 1 threads terminated after 60s 2 threads terminated after 120s 3 threads terminated after 180s 4 threads terminated after 240s 5 threads terminated after 300s 6 threads terminated after 360s 7 threads terminated after 420s 

^{从来没有完成，显然，至少有一个最后的工作线程仍然活着}