使用 Java 8 的 CompletableFuture 實(shí)現(xiàn)函數(shù)式的回調(diào)
最近,在準(zhǔn)備一個(gè)關(guān)于 Java 并行流相關(guān)的演講時(shí),我意識到“The Free Lunch is Over”(TFLiO)這篇經(jīng)典的文章已經(jīng)有超過十年的歷史了。對于大多數(shù)程序員來說,這篇文章的廣泛傳播使他們第一次認(rèn)識到持續(xù)四十年的處理器呈指數(shù)增長的趨勢將要終結(jié)——實(shí)際上,它已經(jīng)終結(jié)了。取而代之的是另外一種趨勢,那就是在每個(gè)芯片上增加處理器的數(shù)量,按照 Herb Sutter 的話來講,程序員必須要“從根本上轉(zhuǎn)向并發(fā)”。
在 TFLiO 這篇文章中,Sutter 觀察到絕大多數(shù)的程序員“并沒有深刻了解并發(fā)”,但是他接著說到“一旦了解之后,其實(shí)基于鎖的編程并不會比 OO 難太多”。毫無疑問,第一句話是完全正確的,但是十年來,基于鎖的并發(fā)體驗(yàn)并沒有證明第二句話的正確性。幸好,Java 程序員可以在很大程度上避免這樣的驗(yàn)證,因?yàn)?TFLiO 發(fā)布的時(shí)候,Java 5 也剛剛可用,它所提供的一些高層級的并發(fā)工具開始得到運(yùn)用。借助它們,能夠讓 Java 開發(fā)人員避免細(xì)粒度地分析同步功能和關(guān)鍵的代碼片段。
并發(fā)與并行
Java 5 并發(fā)庫主要關(guān)注于異步任務(wù)的處理,它采用了這樣一種模式,producer 線程創(chuàng)建任務(wù)并且利用阻塞隊(duì)列將其傳遞給任務(wù)的 consumer。這種模型在 Java 7 和 8 中進(jìn)一步發(fā)展,并且開始支持另外一種風(fēng)格的任務(wù)執(zhí)行,那就是將任務(wù)的數(shù)據(jù)集分解為子集,每個(gè)子集都可以由獨(dú)立且同質(zhì)的子任務(wù)來負(fù)責(zé)處理。
這種風(fēng)格的基礎(chǔ)庫也就是 fork/join 框架,它允許程序員規(guī)定數(shù)據(jù)集該如何進(jìn)行分割,并且支持將子任務(wù)提交到默認(rèn)的標(biāo)準(zhǔn)線程池中,也就是“通用的”ForkJoinPool
。(在本文中,非全限定的類和接口名指的都是 java.util.concurrent 包中的類型。)在 Java 8 中,fork/join 并行功能借助并行流的機(jī)制變得更加具有可用性。但是,不是所有的問題都適合這種風(fēng)格的并行處理:所處理的元素必須是獨(dú)立的,數(shù)據(jù)集要足夠大,并且在并行加速方面,每個(gè)元素的處理成本要足夠高,這樣才能補(bǔ)償建立 fork/join 框架所消耗的成本。
同時(shí),Java 8 在并行流方面的革新得到了廣泛的關(guān)注,這導(dǎo)致大家忽略了并發(fā)庫中一項(xiàng)新增的重要功能,那就是CompletableFuture<T>
類。本文將會探討CompletableFuture
類,有一些系統(tǒng)會依賴于不同類型的異步執(zhí)行任務(wù),本文將會闡述該類為什么會對這種類型的系統(tǒng)如此重要,并介紹了它是如何補(bǔ)充 fork/join 風(fēng)格的并行機(jī)制和并行流的。
頁面渲染器
我們的起始點(diǎn)將是“Java Concurrency in Practice”(JCiP)一書中的樣例,這個(gè)樣例非常經(jīng)典地闡述了 Java 5 中的并發(fā)工具類。在 JCiP 的第 6.3 節(jié)中,Brian Goetz 探討了如何開發(fā)一個(gè) Web 頁面的渲染器,對于每個(gè)頁面來說,它的任務(wù)就是渲染文本,并下載和渲染圖片。圖片的下載會耗費(fèi)較長的時(shí)間,在這段時(shí)間內(nèi) CPU 無事可做,只能等待。所以,在渲染頁面時(shí),一個(gè)很明顯的策略就是首先初始化所有圖片的下載,然后利用它們完成之前的這段時(shí)間渲染頁面文本,最后渲染下載的圖片。
在 JCiP 中,第一版本的頁面渲染器使用了Future
的理念,這個(gè)接口暴露了一些方法,允許客戶端監(jiān)控任務(wù)的執(zhí)行進(jìn)度,這里的任務(wù)是在一個(gè)不同的進(jìn)程中執(zhí)行的。在程序清單 1 中,Callable
代表了下載頁面中所有圖片的任務(wù),它被提交到了 Executor 中,然后返回一個(gè) Future 對象,通過它就能詢問下載任務(wù)的狀態(tài)。當(dāng)主線程渲染完頁面的文本后,會調(diào)用Future.get
方法,這個(gè)方法會一直阻塞直到所有下載的結(jié)果均可用為止,在本例中這個(gè)結(jié)果是以List<ImageData>
的形式來表示的。這種方式一個(gè)很明顯的缺點(diǎn)在于下載任務(wù)的粗粒度性,在所有的圖片下載完成之前,我們一張圖片也不能渲染。接下來,我們看一下如何緩解這個(gè)問題。
public void renderPage(CharSequence source) {
List<ImageInfo> info = scanForImageInfo(source);
// 創(chuàng)建 Callable,它代表了下載所有的圖片
final Callable<List<ImageData>> task = () ->
info.stream()
.map(ImageInfo::downloadImage)
.collect(Collectors.toList());
// 將下載任務(wù)提交到 executor
Future<List<ImageData>> images = executor.submit(task);
// renderText(source);
try {
// 獲得所有下載的圖片(在所有圖片可用之前會一直阻塞)
final List<ImageData> imageDatas = images.get();
// 渲染圖片
imageDatas.forEach(this::renderImage);
} catch (InterruptedException e) {
// 重新維護(hù)線程的中斷狀態(tài)
Thread.currentThread().interrupt();
// 我們不需要結(jié)果,所以取消任務(wù)
images.cancel(true);
} catch (ExecutionException e) {
throw launderThrowable(e.getCause()); }
}
程序清單 1:使用 Future 等待所有的圖片下載完成
為了讓這個(gè)樣例及其后面的變種易于管理,這里有一個(gè)前提條件:我們假設(shè)類型ImageInfo
(簡單來講,就是一個(gè) URL)和ImageData
(圖片的二進(jìn)制數(shù)據(jù))以及方法scanForImageInfo、downloadImage、renderText、renderImage、launderThrowable
和ImageInfo.downloadImage
都已經(jīng)存在了。實(shí)例變量executor
是通過ExecutorService
類型聲明的并進(jìn)行了恰當(dāng)?shù)某跏蓟T诒疚闹校覍?JCiP 中最初的樣例利用 Java 8 lambda 表達(dá)式和流進(jìn)行了現(xiàn)代化。
在這段代碼中,必須要等待所有下載都完成的原因在于,它使用Future
接口來代表下載任務(wù),作為異步執(zhí)行的任務(wù)模型,它有很大的局限性。Future
允許客戶端詢問任務(wù)執(zhí)行的結(jié)果,如果必要的話,將會產(chǎn)生阻塞,另外還可以詢問任務(wù)的狀態(tài),判斷它已經(jīng)完成還是被取消了。但是,Future
本身并不能提供回調(diào)方法,假設(shè)能夠這樣做的話,當(dāng)每個(gè)圖片下載完成的時(shí)候,就能通知頁面的渲染線程了。
程序清單 2 改善了之前樣例中粒度較粗的問題,它將頁面下載的任務(wù)提交到了CompletionService
類中,這個(gè)類的poll
和take
方法會產(chǎn)生對應(yīng)的Future
實(shí)例,這些實(shí)例是按照任務(wù)完成的順序排列的,而不是像程序清單 1 那樣任務(wù)是按照提交的順序處理的。在ExecutorCompletionService
接口的平臺實(shí)現(xiàn)中,為了實(shí)現(xiàn)該功能,每項(xiàng)任務(wù)都會包裝在一個(gè)FutureTask
中,FutureTask
是Future
的一個(gè)實(shí)現(xiàn),它允許提供完成時(shí)的回調(diào)。Future 的回調(diào)行為是在 ExecutorCompletionService 中創(chuàng)建的,完成的任務(wù)會封裝到一個(gè)隊(duì)列中,供客戶端詢問時(shí)使用。
public void renderPage(CharSequence source) {
List<ImageInfo> info = scanForImageInfo(source);
CompletionService<ImageData> completionService =
new ExecutorCompletionService<>(executor);
// 將每個(gè)下載任務(wù)提交到 completion service 中
info.forEach(imageInfo ->
completionService.submit(imageInfo::downloadImage));
renderText(source);
// 當(dāng)每個(gè) RunnableFuture 可用時(shí)(并且我們也準(zhǔn)備處理它的時(shí)候),
// 將它們檢索出來
for (int t = 0; t < info.size(); t++) {
Future<ImageData> imageFuture = completionService.take();
renderImage(imageFuture.get());
}
}
程序清單 2:借助CompletionService,當(dāng)圖片可用時(shí)立即將其渲染出來(為了保持簡潔性,省略掉了中斷和錯(cuò)誤處理的代碼)
CompletableFuture 簡介
程序清單 2 代表了 Java 5 所能達(dá)到的水準(zhǔn),不過 2014 年之后,在 Java 中,編寫異步系統(tǒng)的表現(xiàn)性得到了巨大的提升,這是通過引入CompletableFuture (CF)
類實(shí)現(xiàn)的。這個(gè)類是Future
的實(shí)現(xiàn),它能夠?qū)⒒卣{(diào)放到與任務(wù)不同的線程中執(zhí)行,也能將回調(diào)作為繼續(xù)執(zhí)行的同步函數(shù),在與任務(wù)相同的線程中執(zhí)行。它避免了傳統(tǒng)回調(diào)最大的問題,那就是能夠?qū)⒖刂屏鞣蛛x到不同的事件處理器中,而這是通過允許CF
實(shí)例與回調(diào)方法進(jìn)行組合形成新的CF
來實(shí)現(xiàn)的。
作為樣例,可以參考thenAccept
方法,它接受一個(gè)Consumer
(用戶提供的且沒有返回值的函數(shù))并返回一個(gè)新的CF
。這個(gè)新CF
所能達(dá)到的效果就是在最初CF
完成時(shí)所得到的結(jié)果上,運(yùn)用Consumer
。與很多其他的CF
方法類似,thenAccept
有兩個(gè)變種形式,在第一個(gè)中,Consumer
會由通用 fork/join 池中的某一個(gè)線程來執(zhí)行;在第二個(gè)中,它會由Executor
中的某一個(gè)線程來負(fù)責(zé)執(zhí)行,而Executor
是我們在調(diào)用時(shí)提供的。這形成了三種重載形式:同步運(yùn)行、在ForkJoinPool
中異步運(yùn)行以及在調(diào)用時(shí)所提供的線程池中異步運(yùn)行,CompletableFuture
中有近 60 個(gè)方法,上述的這三種重載形式占了絕大多數(shù)。
如下是thenAccept
的一個(gè)樣例,借助它重新實(shí)現(xiàn)了頁面渲染器的功能:
public void renderPage(CharSequence source) {
List<ImageInfo> info = scanForImageInfo(source);
info.forEach(imageInfo ->
CompletableFuture
.supplyAsync(imageInfo::downloadImage)
.thenAccept(this::renderImage));
renderText(source);
}
程序清單 3:使用CompletableFuture來實(shí)現(xiàn)頁面渲染功能
盡管程序清單 3 比前面的形式更加簡潔,但是我們需要練習(xí)一下才能更好地閱讀它。工廠方法supplyAsync
返回一個(gè)新的CF
,它會在通用的ForkJoinPool
中運(yùn)行指定的Supplier
,完成時(shí),Supplier
的結(jié)果將會作為CF
的結(jié)果。方法thenAccept
會返回一個(gè)新的CF
,它將會執(zhí)行指定的Consumer
,在本例中也就是渲染給定的圖片,即supplyAsync
方法所產(chǎn)生的CF
的結(jié)果。
需要澄清的是,thenAccept
并不是將CF
與函數(shù)組合起來的唯一方式。將CF
與函數(shù)組合起來可以接受如下的參數(shù):
-
應(yīng)用于
CF
操作結(jié)果的函數(shù)。此時(shí),可以采用的方法包括:thenCompose
:針對返回值為CompletableFuture
的函數(shù);thenApply
:針對返回值為其他類型的函數(shù);thenAccept
:針對返回值為 void 的函數(shù);
Runnable
。通過thenRun
方法,可以接受Runnable
參數(shù);-
函數(shù)在處理的過程中,可能正常結(jié)束也可能異常退出。
CF
能夠通過方法來分別組合這兩種情況:handle
,針對接受一個(gè)值和一個(gè) Throwable
,并有返回值的函數(shù);whenComplete
,針對接受一個(gè)值和一個(gè) Throwable
,并返回 void 的函數(shù)。
擴(kuò)展頁面渲染器
擴(kuò)展該樣例能夠闡述CompletableFuture
的其他特性。比如,當(dāng)圖片下載超時(shí)或失敗時(shí),我們想使用一個(gè)圖標(biāo)作為可見的指示器。CF
暴露了一個(gè)名為get(long, TimeUnit)
的方法,如果CF
在指定的時(shí)間內(nèi)沒有完成的話,將會拋出TimeoutException
異常。我們可以使用它來定義一個(gè)函數(shù),這個(gè)函數(shù)會將ImageInfo
轉(zhuǎn)換為ImageData
(程序清單 4)。
Function<ImageInfo, ImageData> infoToData = imageInfo -> {
CompletableFuture<ImageData> imageDataFuture =
CompletableFuture.supplyAsync(imageInfo::downloadImage, executor);
try {
return imageDataFuture.get(5, TimeUnit.SECONDS);
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
imageDataFuture.cancel(true);
return ImageData.createIcon(e);
} catch (ExecutionException e) {
throw launderThrowable(e.getCause());
} catch (TimeoutException e) {
return ImageData.createIcon(e);
}
}
程序清單 4:使用CompletableFuture.get來實(shí)現(xiàn)超時(shí)
現(xiàn)在,頁面可以通過連續(xù)調(diào)用infoToData
來進(jìn)行渲染。其中每個(gè)調(diào)用都會同步返回一個(gè)下載的圖片,所以要并行下載的話,需要為它們各自創(chuàng)建一個(gè)新的異步任務(wù)。要實(shí)現(xiàn)這一功能,合適的工廠方法是CompletableFuture.runAsync()
,它與supplyAsync
類似,但是接受的參數(shù)是Runnable
而不是Supplier
:
public void renderPage(CharSequence source) throws InterruptedException {
List<ImageInfo> info = scanForImageInfo(source);
info.forEach(imageInfo ->
CompletableFuture.runAsync(() ->
renderImage(infoToData.apply(imageInfo)), executor));
}
現(xiàn)在,我們考慮進(jìn)一步的需求,當(dāng)所有的請求完成或超時(shí)后,在頁面上顯示一個(gè)指示器,如果對應(yīng)的所有CompletableFuture
都從join
方法中返回,就能表示出現(xiàn)了這種場景。靜態(tài)方法allOf
就是為這種需求而提供的,它能夠創(chuàng)建一個(gè)返回值為空的CompletableFuture
,當(dāng)其所有的組件均完成時(shí),它也會達(dá)到完成狀態(tài)。(join
方法通常用來返回某個(gè)CF
的結(jié)果,為了查看allOf
方法所組合起來的所有CF
的結(jié)果,必須要對其進(jìn)行單獨(dú)地查詢。)
public void renderPage(CharSequence source) {
List<ImageInfo> info = scanForImageInfo(source);
CompletableFuture[] cfs = info.stream()
.map(ii -> CompletableFuture.runAsync(
() -> renderImage(mapper.apply(ii)), executor))
.toArray(CompletableFuture[]::new);
CompletableFuture.allOf(cfs).join();
renderImage(ImageData.createDoneIcon());
}
聯(lián)合多個(gè) CompletableFuture
另外一組方法允許將多個(gè)CF
聯(lián)合在一起。我們已經(jīng)看見過靜態(tài)方法allOf
,當(dāng)其所有的組件均完成時(shí),它就會處于完成狀態(tài),與之對應(yīng)的方法也就是anyOf
,返回值同樣是 void,當(dāng)其任意一個(gè)組件完成時(shí),它就會完成。除了這兩個(gè)方法以外,這個(gè)組中其他的方法都是實(shí)例方法,它們能夠?qū)?receiver 按照某種方式與另外一個(gè)CF
聯(lián)合在一起,然后將結(jié)果傳遞到給定的函數(shù)中。
為了展現(xiàn)它們是如何運(yùn)行的,我們擴(kuò)展一下 JCiP 中的另一個(gè)例子,這是一個(gè)旅行預(yù)訂的門戶,我們將互相關(guān)聯(lián)的訂購過程記錄在TripPlan
對象中,它包含了總價(jià)以及所使用服務(wù)供應(yīng)商的列表:
interface TripPlan {
List<ServiceSupplier> getSuppliers();
int getPrice();
TripPlan combine(TripPlan);
}
ServiceSupplier
(比如說某個(gè)航線或酒店)能夠創(chuàng)建一個(gè)TripPlan
:(當(dāng)然,在現(xiàn)實(shí)中,ServiceSupplier.createPlan
將會接受參數(shù),來反映對應(yīng)的目的地、旅行等級等信息。)
interface ServiceSupplier {
TripPlan createPlan();
String getAlliance(); // 稍后使用
}
為了選擇最佳的旅行計(jì)劃,需要查詢每個(gè)服務(wù)供應(yīng)商為我們的旅行所給定的規(guī)劃,然后使用Comparator
來對比每個(gè)規(guī)劃結(jié)果,這個(gè)Comparator
反映了我們的選擇標(biāo)準(zhǔn)(在本例中,只是簡單的選擇價(jià)格最低者):
TripPlan selectBestTripPlan(List<ServiceSupplier> serviceList) {
List<CompletableFuture<TripPlan>> tripPlanFutures = serviceList.stream()
.map(svc -> CompletableFuture.supplyAsync(svc::createPlan, executor))
.collect(toList());
return tripPlanFutures.stream()
.min(Comparator.comparing(cf -> cf.join().getPrice()))
.get().join();
}
請注意中間的collect
操作,在流處理里面,由于中間操作的延遲性(laziness of intermediate operation),它就變得非常必要了。如果沒有它的話,流的終止操作(terminal operation)將會是min
,它如果要執(zhí)行的話,首先需要針對tripPlanFutures
的每個(gè)元素執(zhí)行join
操作。如上述的代碼所示,我們并沒有這樣做,終止操作是collect
,它會將map
操作所形成的CF
值累積起來,這個(gè)過程中沒有阻塞,因此允許底層的任務(wù)并發(fā)執(zhí)行。
如果獲取航線和酒店最佳旅行計(jì)劃的任務(wù)是獨(dú)立的,那么我們會希望它們能夠同時(shí)初始化,就像前文所述的圖片下載一樣。要將兩個(gè)CF
按照這種方式聯(lián)合在一起,我們需要使用CompletableFuture.thenCombine
方法,它會并行地執(zhí)行 receiver 以及所提供的CF
,然后將它們的結(jié)果使用給定的函數(shù)組合起來(在這里,假設(shè)變量airlines
、hotels
和(稍后使用的)cars
都是以List<TravelService>
類型進(jìn)行聲明的,并且已經(jīng)進(jìn)行了恰當(dāng)?shù)某跏蓟?/p>
CompletableFuture
.supplyAsync(() -> selectBestTripPlan(airlines))
.thenCombine(
CompletableFuture.supplyAsync(() -> selectBestTripPlan(hotels)),
TripPlan::combine);
對這個(gè)樣例進(jìn)行擴(kuò)展,我們將會學(xué)到更多的內(nèi)容。假設(shè)每個(gè)服務(wù)供應(yīng)商都屬于某一個(gè)旅行聯(lián)盟(travel alliance),通過String
類型的屬性alliance
來表示。在獨(dú)立訂購?fù)旰骄€和酒店后,我們將會確定它們是否屬于同一個(gè)聯(lián)盟,如果是的話,那么只有屬于同一聯(lián)盟的租車服務(wù),才在我們的考慮范圍之內(nèi):
private TripPlan addCarHire(TripPlan p) {
List<String> alliances = p.getSuppliers().stream()
.map(ServiceSupplier::getAlliance)
.distinct()
.collect(toList());
if (alliances.size() == 1) {
return p.combine(selectBestTripPlan(cars, alliances.get(0)));
} else {
return p.combine(selectBestTripPlan(cars));
}
}
selectBestTripPlan
方法新的重載形式將會接受一個(gè)String
類型作為偏愛的聯(lián)盟,如果這個(gè)值存在的話,會使用它來過濾流中的服務(wù):
private TripPlan selectBestTripPlan(
List<ServiceSupplier> serviceList, String favoredAlliance) {
List<CompletableFuture<TripPlan>> tripPlanFutures = serviceList.stream()
.filter(ts ->
favoredAlliance == null || ts.getAlliance().equals(favoredAlliance))
.map(svc -> CompletableFuture.supplyAsync(svc::createPlan, executor))
.collect(toList());
...
}
在本例中,選擇租車服務(wù)的CF
要依賴于航班和酒店預(yù)訂任務(wù)組合所形成的CF
。只有航班和酒店都預(yù)訂之后,它才能完成。實(shí)現(xiàn)這種關(guān)聯(lián)關(guān)系的方法就是thenCompose
:
CompletableFuture.supplyAsync(() -> selectBestTripPlan(airlines))
.thenCombine(
CompletableFuture.supplyAsync(() -> selectBestTripPlan(hotels)),
TripPlan::combine)
.thenCompose(p -> CompletableFuture.supplyAsync(() -> addCarHire(p)));
預(yù)訂航班和酒店聯(lián)合形成的CF
會執(zhí)行,并且它的結(jié)果,也就是聯(lián)合后的TripPlan
,將會作為thenCompose
函數(shù)參數(shù)的輸入。結(jié)果形成的CF
非常簡潔地封裝了不同異步服務(wù)之間的依賴關(guān)系。這段代碼如此簡潔的原因在于,盡管thenCompose
聯(lián)合了兩個(gè)CF
,但是它所返回的并不是我們預(yù)期的CompletableFuture<CompletableFuture<TripPlan>>
,而是CompletableFuture<TripPlan>
。所以,不管在創(chuàng)建CF
的時(shí)候使用了多少層級的組合,它并不是嵌套的,而是扁平的,要獲取它的結(jié)果只需要一步操作。這是 monad“綁定(bind)”操作(這個(gè)名稱來源于 Haskell)的特性,CF
就是這種 monad,并且闡明了 monad 一些非常積極的特征:比如,在本例中,我們能夠按照函數(shù)式的形式進(jìn)行編寫,如果沒有這項(xiàng)功能的話,就需要在各個(gè)回調(diào)中非常繁瑣地顯式編寫任務(wù)定義。
thenCombine
方法只是將兩個(gè)CF
聯(lián)合起來的方法之一,其他的方法包括:
thenAcceptBoth
:與thenCombine
類似,但是它接受一個(gè)返回值為 void 的函數(shù);runAfterBoth
:接受一個(gè)Runnable
,在兩個(gè)CF
都完成后執(zhí)行;applyToEither
:接受一個(gè)一元函數(shù)(unary function),會將首先完成的 CF 的結(jié)果提供給它;acceptEither
:與 applyToEither 類似,接受一個(gè)一元函數(shù),但是結(jié)果為 void;runAfterEither
:接受一個(gè) Runnable,在其中一個(gè) CF 完成后就執(zhí)行。
結(jié)論
我們不可能在一篇短文中,完整地闡述像CompletableFuture
這樣的 API,但是我希望這里的樣例能夠讓你對它所能實(shí)現(xiàn)的并發(fā)編程形式有一個(gè)直觀印象。將CompletableFuture
與其他CompletableFuture
組合,以及與其他函數(shù)組合,能夠?yàn)槎囗?xiàng)任務(wù)構(gòu)建類似流水線的方案,這樣能夠控制同步和異步執(zhí)行以及它們之間的依賴。你想更加詳細(xì)了解的內(nèi)容可能會包括異常處理、選擇和配置 executor 的實(shí)際經(jīng)驗(yàn)以及設(shè)計(jì)異步 API 所面臨的挑戰(zhàn)。
我希望已經(jīng)解釋清楚了 Java 8 所提供的兩種異步編程風(fēng)格之間的聯(lián)系。在使用 fork/join 并行機(jī)制(包括并行流)的場景中,能夠非常高效的將工作內(nèi)容進(jìn)行跨核心分發(fā)。但是,它的適用條件卻非常有限:數(shù)據(jù)集很大并且能夠高效地分割,對某個(gè)數(shù)據(jù)元素的操作與其他元素是(相對)獨(dú)立的,這些操作的成本應(yīng)該是比較高昂的,并且應(yīng)該是 CPU 密集型的。如果這些條件無法滿足的話,尤其是如果你的任務(wù)會花費(fèi)很多時(shí)間阻塞在 I/O 或網(wǎng)絡(luò)請求上的話,那么CompletableFuture
是更好的替代方案。作為 Java 程序員,我們非常幸運(yùn)地有這樣一個(gè)平臺庫,它將這些補(bǔ)充的方式集成在了一起。
關(guān)于作者
Maurice Naftalin在軟件領(lǐng)域已經(jīng)工作了四十年,擔(dān)任過開發(fā)者、研究員、培訓(xùn)師以及圖書作者。他是一位 Java Champion,曾經(jīng)作為作者和合著者編寫過介紹 Java 5 和 Java 8 特性的圖書,并且是 2013 和 2014 年度的 JavaOne Rockstar。Maurice 對 Java Lambdas 的理解包含在了他的新書Mastering Lambdas - Java Programming in a Multicore World中。
查看英文原文:Functional-Style Callbacks Using Java 8's CompletableFuture