摘要：內(nèi)部類，用于對(duì)和異常進(jìn)行包裝，從而保證對(duì)進(jìn)行只有一次成功。是取消異常，轉(zhuǎn)換后拋出。判斷是否使用的線程池，在中持有該線程池的引用。

近期作者對(duì)響應(yīng)式編程越發(fā)感興趣，在內(nèi)部分享"JAVA9-12"新特性過(guò)程中，有兩處特性讓作者深感興趣：
1.JAVA9中的JEP266對(duì)并發(fā)編程工具的更新，包含發(fā)布訂閱框架Flow和CompletableFuture加強(qiáng)，其中發(fā)布訂閱框架以java.base模塊下的java.util.concurrent.Flow及其中的幾個(gè)內(nèi)部類/接口為組成部分，它們的名稱和作用如下，摘自JAVA12的Flow api文檔。

2.JAVA9中孵化，JAVA11中標(biāo)準(zhǔn)化的HttpClient，在之前分享的JAVA9-12新特性一文中曾引用摘自網(wǎng)絡(luò)的HttpClient代碼片段：
片段1：

HttpClient client = HttpClient.newHttpClient();
HttpRequest request = HttpRequest.newBuilder()
    .uri(URI.create(uri))
    .build();

return client.sendAsync(request, HttpResponse.BodyHandlers.ofString())
    .thenApply(HttpResponse::body);
}

片段2：

HttpClient client = HttpClient.newHttpClient();
List urls = List.of("http://www.baidu.com","http://www.alibaba.com/","http://www.tencent.com");
List requests = urls.stream()
    .map(url -> HttpRequest.newBuilder(URI.create(url)))
    .map(reqBuilder -> reqBuilder.build())
    .collect(Collectors.toList());

List>> futures = requests.stream()
    .map(request -> client.sendAsync(request, HttpResponse.BodyHandlers.ofString()))
    .collect(Collectors.toList());
futures.stream()
    .forEach(e -> e.whenComplete((resp,err) -> {
        if(err != null){
            err.printStackTrace();
        }else{
            System.out.println(resp.body());
            System.out.println(resp.statusCode());
        }
    }));
CompletableFuture.allOf(futures
    .toArray(CompletableFuture[]::new))
    .join();
}

在片段1中，thenApply方法是CompletableFuture的成員，client.sendAsync返回的是一個(gè)CompletableFuture。這兩段代碼很好閱讀，甚至說(shuō)猜出其中的意義。片段2可以說(shuō)對(duì)于作者目前的書寫習(xí)慣是一個(gè)全面的顛覆，顯然我們可以預(yù)先定義響應(yīng)行為，而行為的執(zhí)行時(shí)間則由前一個(gè)階段的實(shí)際完成時(shí)間決定。片段2中的whenComplete方法很好理解，最后一行用allOf生成一個(gè)類似樹的依賴結(jié)構(gòu)，在當(dāng)前方法中等待所有CompletableFuture執(zhí)行完成。

簡(jiǎn)單看這兩段代碼，響應(yīng)式編程的魅力可見一斑，甚至可以說(shuō)是美妙不可言。
那么，作為JAVA9中額外照顧增強(qiáng)，HttpClient賴以實(shí)現(xiàn)的CompletableFuture，它是何方神圣呢？

CompletionStage是什么？不妨賣個(gè)關(guān)子先。
作者目前使用的JDK版本為8，盡管它不包含9之后的增強(qiáng)，萬(wàn)幸CompletionStage是從JDK8引入，因此足以用以了解這一偉大神器了。近期作者在公司使用的一些開源框架中，發(fā)現(xiàn)至處間接對(duì)它的使用：
1.持久化框架Redission。它內(nèi)部使用一個(gè)RedissonExecutorService(實(shí)現(xiàn)ScheduledExecutorService）和PromiseDelegator（實(shí)現(xiàn)CompletionStage，而CompletableFuture同樣也實(shí)現(xiàn)了CompletionStage）來(lái)異步地執(zhí)行task。
2.apollo配置中心。它提供了配置變更的異步通知機(jī)制，而這依賴于spring web-mvc提供的DeferredResult，而在異步處理return value時(shí)，DeferredResult的setResult同樣也是相應(yīng)的CompletionStage執(zhí)行。

//例：阿波羅NotificationControllerV2拉取通知接口
@GetMapping
public DeferredResult>>     pollNotification(
  @RequestParam(value = "appId") String appId,
  @RequestParam(value = "cluster") String cluster,
  @RequestParam(value = "notifications") String notificationsAsString,
  @RequestParam(value = "dataCenter", required = false) String dataCenter,
  @RequestParam(value = "ip", required = false) String clientIp) {
List notifications = null;
//省略無(wú)關(guān)代碼
//DeferredResultWrapper是apollo作者包裝的spring DeferredResult
DeferredResultWrapper deferredResultWrapper = new DeferredResultWrapper();
//省略無(wú)關(guān)代碼
if (!CollectionUtils.isEmpty(newNotifications)) {
  deferredResultWrapper.setResult(newNotifications);
} else {
  deferredResultWrapper
      .onTimeout(() -> logWatchedKeys(watchedKeys, "Apollo.LongPoll.TimeOutKeys"));
 
  deferredResultWrapper.onCompletion(() -> {
    //unregister all keys
    for (String key : watchedKeys) {
      deferredResults.remove(key, deferredResultWrapper);
    }
    logWatchedKeys(watchedKeys, "Apollo.LongPoll.CompletedKeys");
  });
 
  //省略
return deferredResultWrapper.getResult();
}

在spring的CompletionStageReturnValueHandler的handleReturnValue（）方法中，如下異步地處理響應(yīng)結(jié)果：

@Override
public void handleReturnValue(Object returnValue, MethodParameter returnType,
        ModelAndViewContainer mavContainer, NativeWebRequest webRequest) throws Exception {
 
    if (returnValue == null) {
        mavContainer.setRequestHandled(true);
        return;
    }
 
    final DeferredResult