源码分析CompletableFuture使用默认线程池ForkJoinPool的弊端

先说结论：
假如有20CompletableFuture任务并发执行时，都使用默认线程池ForkJoinPool，但cpu的核心数又小于3，那么就会新建20个线程（不使用默认线程池了），这20个线程相互竞争cpu资源和内存，很多线程都在等待，浪费了大量的性能在线程上下文切换上。

线程池大小设定：

• 如果服务是cpu密集型的，设置为电脑的核数
• 如果服务是io密集型的，设置为电脑的核数*2

从runAsync方法点进去

    CompletableFuture<Void> voidCompletableFuture = CompletableFuture.runAsync(() -> {System.out.println(1);});

可以看见使用的是asyncPool。点进asyncPool

    public static CompletableFuture<Void> runAsync(Runnable runnable) {return asyncRunStage(asyncPool, runnable);}

useCommonPool是否为true决定了使用 ForkJoinPool线程池还是新建一个线程池。点进useCommonPool。

    private static final Executor asyncPool = useCommonPool ?ForkJoinPool.commonPool() : new ThreadPerTaskExecutor();

这里判定的是ForkJoinPool common线程池中并行度级别是否大于1。点进 getCommonPoolParallelism() 方法

    private static final boolean useCommonPool =(ForkJoinPool.getCommonPoolParallelism() > 1);

返回的是commonParallelism这个字段，再往下找。

    public static int getCommonPoolParallelism() {return commonParallelism;}

发现只有一个地方对这个属性进行赋值，继续。

    static final int commonParallelism;

发现commonParallelism 由par决定，par来自common.config SMASK做与运算。SMASK定义为0xffff（65535），common.config由 makeCommonPool()得到。点进makeCommonPool()方法

...
static final ForkJoinPool common;
static {...common = java.security.AccessController.doPrivileged(new java.security.PrivilegedAction<ForkJoinPool>() {public ForkJoinPool run() {return makeCommonPool(); //common的config由此方法返回}});int par = common.config & SMASK; // report 1 even if threads disabledcommonParallelism = par > 0 ? par : 1;
}

我简化了下面源码，parallelism 初始化为 -1，若jvm启动参数有java.util.concurrent.ForkJoinPool.common那么parallelism将会被启动参数指定。Runtime.getRuntime().availableProcessors() 是获取虚拟机可使用的处理器数量。在jvm未定义参数的前提下，处理器数量若小于等于2，那么并行度parallelism就为1，反之则为 （处理器数量 - 1）。定义了jvm参数，若参数值大于MAX_CAP（32767），则重新赋值。即parallelism 总会大于0， 继续点进ForkJoinPool的构造方法。

    private static ForkJoinPool makeCommonPool() {...int parallelism = -1;try {  // ignore exceptions in accessing/parsing propertiesString pp = System.getProperty("java.util.concurrent.ForkJoinPool.common.parallelism");if (pp != null)parallelism = Integer.parseInt(pp);} catch (Exception ignore) {}if (parallelism < 0 && // default 1 less than #cores(parallelism = Runtime.getRuntime().availableProcessors() - 1) <= 0)parallelism = 1;if (parallelism > MAX_CAP)parallelism = MAX_CAP;return new ForkJoinPool(parallelism, factory, handler, LIFO_QUEUE, // 注意 LIFO_QUEUE等于0 "ForkJoinPool.commonPool-worker-");}

发现config也是作位运算，即config也会大于0，我们拿到这个config返回开始 par 赋值那一块。

    private ForkJoinPool(int parallelism,ForkJoinWorkerThreadFactory factory,UncaughtExceptionHandler handler,int mode,String workerNamePrefix) {this.workerNamePrefix = workerNamePrefix;this.factory = factory;this.ueh = handler;this.config = (parallelism & SMASK) | mode; // SMASK等于65535，mode等于0long np = (long)(-parallelism); // offset ctl countsthis.ctl = ((np << AC_SHIFT) & AC_MASK) | ((np << TC_SHIFT) & TC_MASK);}

总结就是并行度 parallelism（大于0） 与 65535（111111…） 做两次与运算,即本身。继续回到之前

...
static final ForkJoinPool common;
static {...common = java.security.AccessController.doPrivileged(new java.security.PrivilegedAction<ForkJoinPool>() {public ForkJoinPool run() {return makeCommonPool(); //common的config由此方法返回}});int par = common.config & SMASK; // report 1 even if threads disabledcommonParallelism = par > 0 ? par : 1;
}

这里判断，

• 无JVM参数前提下：
  • 若服务器的核心数小于等于2，commonParallelism 则为1，即useCommonPool 为false，new 一个线程池。
  • 若服务器的核心数大于2，commonParallelism 则为 核心数 - 1，即useCommonPool 为true，使用ForkJoinPool线程池。
• 有JVM参数，以设置参数为准。大于1小于等于32767。和上面判断一致。

    private static final Executor asyncPool = useCommonPool ?ForkJoinPool.commonPool() : new ThreadPerTaskExecutor();private static final boolean useCommonPool =(ForkJoinPool.getCommonPoolParallelism() > 1);public static int getCommonPoolParallelism() {return commonParallelism;}

在ThreadPerTaskExecutor 中 execute，他会为每个任务新开一个线程，而不是采用ForkJoinPool中的线程。

    static final class ThreadPerTaskExecutor implements Executor {public void execute(Runnable r) { new Thread(r).start(); }}

结论：jvm启动参数中 java.util.concurrent.ForkJoinPool.common 的值为 1或者服务器核心数小于等于2，都会导致不采用ForkJoinPool 中的线程，而是新起一个线程。

如果服务器只有两核，假如业务需要：现在起了20个completablefuture任务，若使用默认线程池，那么就会创建20个线程，20个线程并发执行在两个cpu上竞争稀缺的处理器和内存资源，浪费大量的时间在上下文切换上。

，