上图体现了supplyAsync()的过程，对于调用者来说，只能接触到 stage 对象，并且调用者根本不知道 stage 对象何时能产生运行结果。对于实现来说，把 task 包装成一个 AsyncSupply 对象，另起线程执行 task，执行完毕后为 stage 对象赋值运行结果。

注意，stage 完成的标志，就是它的result成员非 null。

thenApply(thenApplyAsync)

在 supplyAsync 直接返回了个 CompletableFuture 对象后，主线程在这个对象上调用 thenApply 或 thenApplyAsync 将后续 stage 接续到前一个 stage 的后面。

    public <U> CompletableFuture<U> thenApply(
        Function<? super T,? extends U> fn) {
        return uniApplyStage(null, fn);
    }

    public <U> CompletableFuture<U> thenApplyAsync(
        Function<? super T,? extends U> fn) {
        return uniApplyStage(asyncPool, fn);
    }

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9

thenApply不会传入 Executor，因为它优先让当前线程（例子中是 main 线程）来执行后续 stage 的 task。具体的说：

• 当发现前一个 stage 已经执行完毕时，直接让当前线程来执行后续 stage 的 task。
• 当发现前一还没执行完毕时，则把当前 stage 包装成一个 UniApply 对象，放到前一个 stage 的栈中。执行前一个 stage 的线程，执行完毕后，接着执行后续 stage 的 task。
• 总之，要么是一个异步线程走到底，要么让当前线程来执行后续 stage（因为异步线程已经结束，而且你又没有给 Executor，那只好让当前线程来执行咯）。

thenApplyAsync会传入一个 Executor，因为它总是让 Executor 线程池里面的线程 来执行后续 stage 的 task。具体的说：

• 当发现前一个 stage 已经执行完毕时，直接让 Executor 来执行。
• 当发现前一个 stage 还没执行完毕时，则等到执行前一个 stage 的线程执行完毕后，再让 Executor 来执行。
• 总之，无论哪种情况，执行后一个 stage 的线程肯定不是当前添加后续 stage 的线程（例子中是 main 线程）了。

private <V> CompletableFuture<V> uniApplyStage(
    Executor e, Function<? super T,? extends V> f) {
    if (f == null) throw new NullPointerException();
    CompletableFuture<V> d =  new CompletableFuture<V>();
    //如果e不为null，说明当前stage是无论如何都需要被异步执行的。所以短路后面的d.uniApply。
    //如果e为null，说明当前stage是可以允许被同步执行的。所以需要尝试一下d.uniApply。
    if (e != null || !d.uniApply(this, f, null)) {
    	//进入此分支有两种情况：
    	//1. 要么e不为null，前一个stage不一定执行完毕。就算前一个stage已经执行完毕，还可以用e来执行当前stage
    	//2. 要么e为null，但前一个stage还没执行完毕。所以只能入栈等待
        UniApply<T,V> c = new UniApply<T,V>(e, d, this, f);
        push(c);
        //（考虑e为null）入栈后需要避免，入栈后刚好前一个stage已经执行完毕的情况。这种特殊情况，如果不执行c.tryFire(SYNC)，当前stage永远不会完成。
        //（考虑e不为null）入栈后需要避免，入栈前 前一个stage已经执行完毕的情况。
        //下面这句，有可能发现前一个stage已经执行完毕，然后马上执行当前stage
        c.tryFire(SYNC);
    }
    return d;
}

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19

• 从CompletableFuture d = new CompletableFuture()和 return d 来看，还是和之前一样，new 出来一个CompletableFuture对象后就尽快返回。
• 如果 Executor e 为 null（当前 stage 是可以允许被同步执行的），并且此时前一个 stage 已经结束了，这种情况应该让当前线程来同步执行当前 stage。但我们其实不知道前一个 stage 是否结束，所以通过d.uniApply(this, f, null)检测前一个 stage 是否已经结束。如果d.uniApply(this, f, null)返回 true，说明发现了前一个 stage 已经结束，并且当前线程执行完毕当前 stage，所以这种情况就会直接 return d。
  • d.uniApply(this, f, null)的第三个实参为 null，这代表与当前 stage 相关联的 Completion 对象还没有入栈（还没push©），即不可能有别的线程与当前线程来竞争执行当前 stage。这样d.uniApply(this, f, null)里面的逻辑就变简单了，要么发现前一个 stage 还没执行完，直接返回 false；要么发现前一个 stage 执行完毕，那么执行当前 stage 后，返回 true。

进入分支有两种情况：

• 如果 e 不为 null：
  • 如果前一个 stage 已经执行完毕：当前线程在c.tryFire(SYNC)中把接管的当前 stage 转交给 e 执行。
  • 如果前一个 stage 还没执行完毕：当前线程会直接返回，等到执行前一个 stage 的线程来把当前 stage 转交给 e 执行。
• 如果 e 为 null：
  • 并且前一个 stage 还没执行完毕。
• 上面几种情况，最终都会入栈，不管 e 是否为 null，都有必要再尝试一下c.tryFire(SYNC)，避免此时前一个 stage 已经完成的情况。
• c.tryFire(SYNC)中也会执行类似d.uniApply(this, f, null)，而且你会发现两种调用环境，uniApply 成员函数的 this 对象是一样的（当前 stage），第一个实参是一样的（前一个 stage），第二个实参也是同一个函数式接口对象，只有第三个实参不一样。

UniApply内部类#tryFire

在讲 tryFire 之前，我们先看看 tryFire 有几处调用：

• uniApplyStage 中的同步调用，c.tryFire(SYNC)。
• 执行前一个stage的线程，在 run 的d.postComplete()中，会调用tryFire(NESTED)。
• 上面两处，tryFire 的 this 对象都是我们分析过程提到的当前 stage。并且，这说明 tryFire 可能会有多线程的竞争问题，来看看tryFire 是怎么解决的。
  • 多线程竞争，比如当前线程入栈后，执行前一个stage的线程刚完事，正要触发后续 stage（run的d.postComplete()中）。

	//src代表前一个stage, dep代表当前stage。  UniApply对象将两个stage组合在一起了。
    static final class UniApply<T,V> extends UniCompletion<T,V> {
        Function<? super T,? extends V> fn;
        UniApply(Executor executor, CompletableFuture<V> dep,
                 CompletableFuture<T> src,
                 Function<? super T,? extends V> fn) {
            super(executor, dep, src); this.fn = fn;
        }
        final CompletableFuture<V> tryFire(int mode) {
            CompletableFuture<V> d; CompletableFuture<T> a;
            //1. 如果dep为null，说明当前stage已经被执行过了
            //2. 如果uniApply返回false，说明当前线程无法执行当前stage。返回false有可能是因为
            //     1. 前一个stage没执行完呢
            //     2. 前一个stage执行完了，但当前stage已经被别的线程执行了。如果提供了线程池，那么肯定属于被别的线程执行了。   
            if ((d = dep) == null ||
                !d.uniApply(a = src, fn, mode > 0 ? null : this))
                return null;
            //执行到这里，说明dep不为null，而且uniApply返回true，说明当前线程执行了当前stage
            dep = null; src = null; fn = null;
            return d.postFire(a, mode);
        }
    }

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19
• 20
• 21
• 22

看来这个竞争关系体现到了d.uniApply(a = src, fn, mode > 0 ? null : this)，分析上面两种情况，发现mode > 0 ? null : this必然不成立，而this指的是 UniApply 对象（在CompletableFuture#uniApplyStage中创建的）。现在好了，上面两种情况第三个实参都是同一个 UniApply 对象（竞争处理的关键，之后讲），即两种情况对CompletableFuture#uniApply调用情况一模一样，竞争在这里面处理。

注意，(d = dep) == null已经起到了一定的防止竞争的作用，让线程提前返回。但也有可能起不到作用，因为两个线程刚好都执行到了d.uniApply(a = src, fn, mode > 0 ? null : this)。

CompletableFuture#uniApply

这个函数的逻辑之前讲过简单的一版，即当第三个实参为 null 时的情况。所以这里，重点关注第三个实参不为 null 的情况。

	//this永远是当前stage，a参数永远是前一个stage
    final <S> boolean uniApply(CompletableFuture<S> a,
                               Function<? super S,? extends T> f,
                               UniApply<S,T> c) {
        Object r; Throwable x;
        //前后两个条件只是优雅的避免空指针异常，实际不可能发生。
        //如果 前一个stage的result为null，说明前一个stage还没执行完毕
        if (a == null || (r = a.result) == null || f == null)
            return false;
        //执行到这里，说明前一个stage执行完毕

		//如果this即当前stage的result不为null，说当前stage还没执行。
        tryComplete: if (result == null) {  //一定程度防止了竞争
        	//如果前一个stage的执行结果为null或者抛出异常
            if (r instanceof AltResult) {
                if ((x = ((AltResult)r).ex) != null) {
                	//如果前一个stage抛出异常，那么直接让当前stage的执行结果也为这个异常，都不用执行Function了
                    completeThrowable(x, r);
                    break tryComplete;
                }
                //如果前一个stage的执行结果为null
                r = null;//那么让r变成null
            }
            try {
            	//1. c为null，这说明c还没有入栈，没有线程竞争。直接执行当前stage即f.apply(s)
            	//2. c不为null，这说明c已经入栈了，有线程竞争执行当前stage。
                if (c != null && !c.claim())
                	//claim返回了false，说明当前线程不允许执行当前stage，直接返回
                    return false;
                    //claim返回了true，说明当前线程允许接下来执行当前stage
                @SuppressWarnings("unchecked") S s = (S) r;
                    completeValue(f.apply(s));
            } catch (Throwable ex) {
                completeThrowable(ex);
            }
        }
        //如果this即当前stage的result不为null，说当前stage已经执行完毕，那么直接返回true
        return true;
    }

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19
• 20
• 21
• 22
• 23
• 24
• 25
• 26
• 27
• 28
• 29
• 30
• 31
• 32
• 33
• 34
• 35
• 36
• 37
• 38
• 39

• if ((x = ((AltResult)r).ex) != null)判断中，如果发现前一个 stage 执行完是因为抛出了异常，那么当前 stage 也不能正常执行了，直接把这个异常赋值给当前 stage 的 result 成员。
  • break tryComplete后，uniApply函数会马上返回 true，然后回到tryFire函数，紧接着马上执行dep = null（这代表当前 stage 已经执行完毕）。这样可以使得某种特殊时序下，执行前一个 stage 的线程不会通过tryFire函数中的(d = dep) == null的检查，进而直接返回null不去执行d.postFire(a, mode)。总之，这是为了避免对同一个 CompletableFuture 对象调用它的成员函数 postComplete。
  • 但貌似上面说的这种防止线程竞争的手段不是完全有效的，因为 “紧接着马上执行 dep = null ” 不是原子性，两个线程的执行顺序也有可能穿插执行，有可能当前线程还没来得及 “执行 dep = null ”，执行前一个stage的线程就开始执行tryFire函数了。
• if (c != null && !c.claim())是用来保护函数式接口只被执行一次的。claim 函数返回 true 代表函数式接口接下来可以被当前线程同步执行。

        final boolean claim() {
            Executor e = executor;
            //如果该Completion包含有Executor，那么此函数每次都会返回false。
            //  CAS保证函数式接口只被提交一次给Executor
            //如果该Completion没有Executor，那么此函数第一次返回true，之后每次返回false。
            //  CAS保证函数式接口只被同步执行一次
            if (compareAndSetForkJoinTaskTag((short)0, (short)1)) {
                if (e == null)
                    return true;
                executor = null; // disable
                e.execute(this);
            }
            return false;
        }

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14

• 竞争关系，全部在claim()函数中处理掉。经过CAS的保护，这个函数式接口能够保证只被执行一次（可能是同步执行、或者提交给 Executor 异步执行）。
• CompletableFuture#uniApply的返回值含义：
  • 返回 false，代表前一个 stage 还没完成。也可代表，当前 stage 的函数式接口已经被别的线程执行了。
  • 返回 true，代表前一个 stage 已经完成，并且当前 stage 的函数式接口被当前线程执行了。
  • 函数返回后，回到tryFire，将执行d.postFire(a, mode)，因为执行完毕了当前 stage 的函数式接口，当前线程就得处理当前 stage 的后续任务。

梳理到这里，例子中的驱动关系就更加明白了：

谁执行了当前 stage，谁负责处理后续 stage

在tryFire函数中，如果d.uniApply(a = src, fn, mode > 0 ? null : this)返回了 true，说明当前线程执行了当前 stage 的函数式接口（这说明没有提供线程池，当前线程同步执行了 stage），自然接下来会去处理后续 stage（d.postFire(a, mode)）。

在提供了线程池的情况下，且前一个stage没有抛出异常正常执行完的情况下，tryFire 函数中的d.uniApply(a = src, fn, mode > 0 ? null : this)必然会返回 false，因为它把 uniApply 对象提交给了线程池来执行。当前线程将不会去处理后续 stage了（d.postFire(a, mode)）。

提交给线程池后，因为 uniApply 对象也是一个 Runnable 对象，它的 run 函数为：

        public final void run()                { tryFire(ASYNC); }

• 1

线程池将提供一个线程来执行tryFire(ASYNC)，之后d.uniApply(a = src, fn, mode > 0 ? null : this)将会直接执行当前 stage 的函数式接口，返回 true 后，再去处理后续 stage（d.postFire(a, mode)）。

Async 任务的执行过程

1. 执行前一个 stage 的线程来执行 UniApply 内部类对象的tryFire(NESTED)。
2. 接着执行当前stage.uniApply()。
3. 执行 UniApply 内部类对象的claim方法。
4. 由于提供了线程池，claim会把任务提交给线程池（e.execute(this)），把保存的线程池清理掉（executor = null），然后返回 false。执行前一个 stage 的线程接着层层返回，最终tryFire(NESTED)返回 null。
5. 线程池选择一个线程，开始对同一个 UniApply 内部类对象执行tryFire(ASYNC)。
6. 接着执行当前stage.uniApply(a = src, fn, ASYNC > 0 ? null : this)，第三个实参肯定为 null。ASYN C为 1.
7. if (c != null && !c.claim())不会执行，因为第三个参数为 null。
8. 这个线程以“同步”的方式来执行了任务。但它对于执行前一个 stage 的线程来说是异步的。

CompletableFuture#postFire

在前面的分析可知，UniApply#tryFire成功执行了这个 UniApply 对象的当前 stage 后，将会调用当前 stage 的postFire。

    final CompletableFuture<T> postFire(CompletableFuture<?> a, int mode) {
    	//前一个stage的后续任务还没做完
        if (a != null && a.stack != null) {
            //1. mode为NESTED。说明就是postComplete调用过来的，那么只清理一下栈中无效节点即可。
            //2. mode为SYNC或ASYNC，但前一个stage还没执行完。不知道何时发生，因为调用postFire的前提就是前一个stage已经执行完
            if (mode < 0 || a.result == null)
                a.cleanStack();
            //3. mode为SYNC或ASYNC，但前一个stage已经执行完了。特殊时序可能发生的，那么帮忙完成前一个stage的的后续任务
            else
                a.postComplete();
        }
        //当前stage的后续任务还没做完
        if (result != null && stack != null) {
            if (mode < 0)//mode为NESTED。说明就是postComplete调用过来的.
                return this;
            else         //mode为SYNC或ASYNC，那么调用postComplete
                postComplete();
        }
        return null;
        
    }

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19
• 20
• 21

简单说下 allOf 原理

allOf 使用了一种递归分治的方法，虽然任务可能有很多个，但最终它们都能拆分为 1 个或者 2 个。从最底层两两合并，弄成一个树形结构，最终这个树形结构的根节点就是我们想要的 CompletableFuture，它们代表了所有任务都完成的时机。

    public static CompletableFuture<Void> allOf(CompletableFuture<?>... cfs) {
        return andTree(cfs, 0, cfs.length - 1);
    }

• 1
• 2
• 3

从CompletableFuture的返回类型可知，allOf方法返回的 CompletableFuture 对象只是代表一种时机，这个时机就是 cfs 里面的 CompletableFuture 都已经执行完毕。当我们在allOf方法返回的 CompletableFuture 对象上添加后续任务时，能保证后续任务是这个特殊时机后才会触发的。

总结

• CompletableFuture 通过异步回调来处理执行结果，解决了 FutureTask 对执行结果获取的痛点。
• 用户只能接触到 CompletableFuture 对象，靠 Completion 对象来驱动 CompletableFuture 对象。注意，Completion 是实现了 Runnable 的。
• 个人认为，CompletableFuture 这种工具类我们会用就 ok，并且简单理解他的原理就好。说实话，我觉得研究 ThreadPoolExecutor 或者 ForkJoinPool 源码比深入 CompletableFuture 更有意义！