Java8 CompletableFuture詳解。本站提示廣大學習愛好者：（Java8 CompletableFuture詳解）文章只能為提供參考，不一定能成為您想要的結果。以下是Java8 CompletableFuture詳解正文
本文以實例具體剖析了Java中重載與重寫的差別，感興致的同伙可以參考一下。
1、重載(Overloading)：
（1） 辦法重載是讓類以同一的方法處置分歧類型數據的一種手腕。多個同名函數同時存在，具有分歧的參數個數/類型。
重載Overloading是一個類中多態性的一種表示。
（2）Java的辦法重載，就是在類中可以創立多個辦法，它們具有雷同的名字，但具有分歧的參數和分歧的界說。
挪用辦法時經由過程傳遞給它們的分歧參數個數和參數類型來決議詳細應用哪一個辦法, 這就是多態性。
（3） 重載的時刻，辦法名要一樣，然則參數類型和個數紛歧樣，前往值類型可以雷同也能夠不雷同。沒法以前往型別作為重載函數的辨別尺度。
上面是重載的例子：
package c04.answer;//這是包名
//這是這個法式的第一種編程辦法，在main辦法中先創立一個Dog類實例，然後在Dog類的結構辦法中應用this症結字挪用分歧的bark辦法。
分歧的重載辦法bark是依據其參數類型的分歧而辨別的。
//留意：除結構器之外，編譯器制止在其他任何處所中挪用結構器。
package c04.answer;
public class Dog {
Dog()
{
this.bark();
}
void bark()//bark()辦法是重載辦法
{
System.out.println(\"no barking!\");
this.bark(\"female\", 3.4);
}
void bark(String m,double l)//留意：重載的辦法的前往值都是一樣的，
{
System.out.println(\"a barking dog!\");
this.bark(5, \"China\");
}
void bark(int a,String n)//不克不及以前往值辨別重載辦法，而只能以“參數類型”和“類名”來辨別
{
System.out.println(\"a howling dog\");
}
public static void main(String[] args)
{
Dog dog = new Dog();
//dog.bark(); [Page]
//dog.bark(\"male\", \"yellow\");
//dog.bark(5, \"China\");
2、重寫（Overriding）
（1） 父類與子類之間的多態性，對父類的函數停止從新界說。假如在子類中界說某辦法與其父類有雷同的稱號和參數，我們說該辦法被重寫 (Overriding)。在中，子類可繼續父類中的辦法，而不須要從新編寫雷同的辦法。
但有時子類其實不想原封不動地繼續父類的辦法，而是想作必定的修正，這就須要采取辦法的重寫。
辦法重寫又稱辦法籠罩。
（2）若子類中的辦法與父類中的某一辦法具有雷同的辦法名、前往類型和參數表，則新辦法將籠罩原本的辦法。
如需父類華夏有的辦法，可以使用super症結字，該症結字援用了以後類的父類。
（3）子類函數的拜訪潤飾權限不克不及少於父類的；
上面是重寫的例子：
概念：即挪用對象辦法的機制。
靜態綁定的內情：
1、編譯器檢討對象聲明的類型和辦法名，從而獲得一切候選辦法。試著把上例Base類的test正文失落，這時候再編譯就沒法經由過程。
2、重載決議計劃：編譯器檢討辦法挪用的參數類型，從上述候選辦法選出獨一的那一個（其間會有隱含類型轉化）。
假如編譯器找到多於一個或許沒找到，此時編譯器就會報錯。試著把上例Base類的test(byte b)正文失落，這時候運轉成果是1 1。
3、若辦法類型為priavte static final ，java采取靜態編譯，編譯器會精確曉得該挪用哪
個辦法。
4、當法式運轉而且應用靜態綁定來挪用一個辦法時，那末虛擬機必需挪用對象的現實類型相婚配的辦法版本。
在例子中，b所指向的現實類型是TestOverriding，所以b.test(0)挪用子類的test。
然則，子類並沒有重寫test(byte b)，所以b.test((byte)0)挪用的是父類的test(byte b)。
假如把父類的(byte b)正文失落，則經由過程第二步隱含類型轉化為int,終究挪用的是子類的test(int i)。
3、進修總結：
多態性是面向對象編程的一種特征，和辦法有關，
簡略說，就是異樣的一個辦法可以或許依據輸出數據的分歧，做出分歧的處置，即辦法的
重載——有分歧的參數列表（靜態多態性）
而當子類繼續自父類的雷同辦法，輸出數據一樣，但要做出有別於父類的呼應時，你就要籠罩父類辦法，
即在子類中重寫該辦法——雷同參數，分歧完成（靜態多態性）
OOP三年夜特征：繼續，多態，封裝。
public class Base
{
void test(int i)
{
System.out.print(i);
}
void test(byte b)
{
System.out.print(b);
}
}
public class TestOverriding extends Base
{
void test(int i)
{
i++;
System.out.println(i);
}
public static void main(String[]agrs)
{
Base b=new TestOverriding();
b.test(0)
b.test((byte)0)
}
}
這時候的輸入成果是1 0，這是運轉時靜態綁定的成果。
重寫的重要長處是可以或許界說某個子類獨有的特點：
publicclassFather{
publicvoidspeak(){
System.out.println(Father);
}
}
publicclassSonextendsFather{
publicvoidspeak(){
System.out.println("son");
}
}
這也叫做多態性，重寫辦法只能存在於具有繼續關系中，重寫辦法只能重寫父類非公有的辦法。
當上例中Father類speak()辦法被private時，Son類不克不及重寫出Father類speak()辦法，此時Son類speak()辦法相當與在Son類中界說的一個speak()辦法。
Father類speak()辦法一但被final時，不管該辦法被public,protected及默許所潤飾時，Son類基本不克不及重寫Father類speak()辦法，
試圖編譯代碼時，編譯器會報錯。例：
publicclassFather{
finalpublicvoidspeak(){
System.out.println("Father");
}
}
publicclassSonextendsFather{
publicvoidspeak(){
System.out.println("son");
}
}//編譯器會報錯；
Father類speak()辦法被默許潤飾時，只能在統一包中，被其子類被重寫，假如不在統一包則不克不及重寫。
Father類speak()辦法被protoeted時，不只在統一包中，被其子類被重寫，還可以分歧包的子類重寫。
重寫辦法的規矩：
1、參數列表必需完整與被重寫的辦法雷同，不然不克不及稱其為重寫而是重載。
2、前往的類型必需一向與被重寫的辦法的前往類型雷同，不然不克不及稱其為重寫而是重載。
3、拜訪潤飾符的限制必定要年夜於被重寫辦法的拜訪潤飾符（public>protected>default>private）
4、重寫辦法必定不克不及拋出新的檢討異常或許比被重寫辦法聲名加倍廣泛的檢討型異常。例如：
父類的一個辦法聲名了一個檢討異常IOException，在重寫這個辦法是就不克不及拋出Exception,只能拋出IOException的子類異常，可以拋出非檢討異常。
而重載的規矩：
1、必需具有分歧的參數列表；
2、可以有不叱罵的前往類型，只需參數列表分歧便可以了；
3、可以有分歧的拜訪潤飾符；
4、可以拋出分歧的異常；
重寫與重載的差別在於：
重寫多態性起感化，對換用被重載過的辦法可以年夜年夜削減代碼的輸出量，統一個辦法名只需往外面傳遞分歧的參數便可以具有分歧的功效或前往值。
用好重寫和重載可以設計一個構造清楚而簡練的類，可以說重寫和重載在編寫代碼進程中的感化非統一般.
這裡，你會看到一個序列的轉換，從String到Integer再到Double。但最主要的是，這些轉換既不立刻履行也一直止。這些轉換既不立刻履行也��直止。他們只是記得，當原始f1完成他們所履行的法式。假如某些轉換異常耗時，你可以供給你本身的Executor來異步地運轉他們。留意,此操作相當於Scala中的一元map。
4、運轉完成的代碼（thenAccept/thenRun）
CompletableFuture<Void> thenAccept(Consumer<? super T> block);
CompletableFuture<Void> thenRun(Runnable action);
在future的管道裡有兩種典范的“終究”階段辦法。他們在你應用future的值的時刻做好預備，當 thenAccept()供給終究的值時，thenRun履行 Runnable，這乃至沒無方法去盤算值。例如：
future.thenAcceptAsync(dbl -> log.debug("Result: {}", dbl), executor);
log.debug("Continuing");
…Async變量也可用兩種辦法，隱式和顯式履行器，我不會過量強調這個辦法。
thenAccept()/thenRun()辦法並沒有產生壅塞（即便沒有明白的executor)。它們像一個事宜偵聽器/處置法式，你銜接到一個future時，這將履行一段時光。”Continuing”新聞將立刻湧現，雖然future乃至沒有完成。
5、單個CompletableFuture的毛病處置
到今朝為止，我們只評論辯論盤算的成果。那末異常呢？我們可以異步地處置它們嗎？固然！
CompletableFuture<String> safe =
future.exceptionally(ex -> "We have a problem: " + ex.getMessage());
exceptionally()接收一個函數時，將挪用原始future來拋出一個異常。我們會無機會將此異常轉換為和Future類型的兼容的一些值來停止恢復。safe進一步的轉換將不再發生一個異常而是從供給功效的函數前往一個String值。
一個加倍靈巧的辦法是handle()接收一個函數，它吸收准確的成果或異常：
CompletableFuture<Integer> safe = future.handle((ok, ex) -> {
if (ok != null) {
return Integer.parseInt(ok);
} else {
log.warn("Problem", ex);
return -1;
}
});
handle()老是被挪用，成果和異常都非空，這是個一站式全方位的戰略。
6、一路聯合兩個CompletableFuture
異步處置進程之一的CompletableFuture異常不錯然則當多個如許的futures以各類方法組合在一路時確切顯示了它的壯大。
7、聯合（鏈接）這兩個futures（thenCompose()）
有時你想運轉一些future的值（當它預備好了），但這個函數也前往了future。CompletableFuture足夠靈巧地明確我們的函數成果如今應當作為頂級的future，比較CompletableFuture<CompletableFuture>。辦法 thenCompose()相當於Scala的flatMap：
<U> CompletableFuture<U> thenCompose(Function<? super T,CompletableFuture<U>> fn);
…Async變更也是可用的，鄙人面的事例中，細心不雅察thenApply()(map)和thenCompose()（flatMap）的類型和差別，當運用calculateRelevance()辦法前往CompletableFuture：
CompletableFuture<Document> docFuture = //...
CompletableFuture<CompletableFuture<Double>> f =
docFuture.thenApply(this::calculateRelevance);
CompletableFuture<Double> relevanceFuture =
docFuture.thenCompose(this::calculateRelevance);
//...
private CompletableFuture<Double> calculateRelevance(Document doc) //...
thenCompose()是一個主要的辦法許可構建硬朗的和異步的管道，沒有壅塞和期待的中央步調。
8、兩個futures的轉換值(thenCombine())
當thenCompose()用於鏈接一個future時依附另外一個thenCombine，當他們都完成以後就聯合兩個自力的futures：
<U,V> CompletableFuture<V> thenCombine(CompletableFuture<? extends U> other, BiFunction<? super T,? super U,? extends V> fn)
…Async變量也是可用的，假定你有兩個CompletableFuture，一個加載Customer另外一個加載比來的Shop。他們彼此完整自力，然則當他們完成時，您想要應用它們的值來盤算Route。這是一個可褫奪的例子：
CompletableFuture<Customer> customerFuture = loadCustomerDetails(123);
CompletableFuture<Shop> shopFuture = closestShop();
CompletableFuture<Route> routeFuture =
customerFuture.thenCombine(shopFuture, (cust, shop) -> findRoute(cust, shop));
//...
private Route findRoute(Customer customer, Shop shop) //...
請留意，在Java 8中可以用(cust, shop) -> findRoute(cust, shop)簡略地取代this::findRoute辦法的援用：
customerFuture.thenCombine(shopFuture, this::findRoute);
你也曉得，我們有customerFuture 和 shopFuture。那末routeFuture包裝它們然後“期待”它們完成。當他們預備好了，它會運轉我們供給的函數來聯合一切的成果(findRoute())。當兩個根本的futures完成而且 findRoute()也完成時，如許routeFuture將會完成。
9、期待一切的 CompletableFutures 完成
假如不是發生新的CompletableFuture銜接這兩個成果，我們只是願望當完成時獲得告訴，我們可使用thenAcceptBoth()/runAfterBoth()系列的辦法，（…Async 變量也是可用的）。它們的任務方法與thenAccept() 和 thenRun()相似，然則是期待兩個futures而不是一個：
<U> CompletableFuture<Void> thenAcceptBoth(CompletableFuture<? extends U> other, BiConsumer<? super T,? super U> block)
CompletableFuture<Void> runAfterBoth(CompletableFuture<?> other, Runnable action)
想象一下下面的例子，這不是發生新的 CompletableFuture，你只是想要連忙發送一些事宜或刷新GUI。這可以很輕易地完成：thenAcceptBoth():
customerFuture.thenAcceptBoth(shopFuture, (cust, shop) -> {
final Route route = findRoute(cust, shop);
//refresh GUI with route
});
我願望我是錯的，但或許有些人會問本身一個成績：為何我不克不及簡略地壅塞這兩個futures呢？ 就像：
Future<Customer> customerFuture = loadCustomerDetails(123);
Future<Shop> shopFuture = closestShop();
findRoute(customerFuture.get(), shopFuture.get());
好了，你固然可以這麼做。然則最症結的一點是CompletableFuture是許可異步的，它是事宜驅動的編程模子而不是壅塞並迫切地期待著成果。所以在功效上，下面兩部門代碼是等價的，但後者沒有需要占用一個線程來履行。
10、期待第一個 CompletableFuture 來完成義務
另外一個風趣的事是CompletableFutureAPI可以期待第一個（與一切相反）完成的future。當你有兩個雷同類型義務的成果時就顯得異常便利，你只需關懷呼應時光就好了，沒有哪一個義務是優先的。API辦法(…Async變量也是可用的）：
CompletableFuture<Void> acceptEither(CompletableFuture<? extends T> other, Consumer<? super T> block)
CompletableFuture<Void> runAfterEither(CompletableFuture<?> other, Runnable action)
作為一個例子，你有兩個體系可以集成。一個具有較小的均勻呼應時光然則具有高的尺度差，另外一個普通情形下較慢，然則加倍輕易猜測。為了分身其美（機能和可猜測性）你可以在統一時光挪用兩個體系並等著誰先完成。平日這會是第一個體系，然則在進度變得遲緩時，第二個體系便可以在可接收的時光內完成：
CompletableFuture<String> fast = fetchFast();
CompletableFuture<String> predictable = fetchPredictably();
fast.acceptEither(predictable, s -> {
System.out.println("Result: " + s);
});
s代表了從fetchFast()或是fetchPredictably()獲得的String。我們不用曉得也無需關懷。
11、完全地轉換第一個體系
applyToEither()算是 acceptEither()的先輩了。當兩個futures將近完成時，後者只是簡略地挪用一些代碼片斷，applyToEither()將會前往一個新的future。當這兩個最後的futures完成時，新的future也會完成。API有點相似於(…Async 變量也是可用的)：
<U> CompletableFuture<U> applyToEither(CompletableFuture<? extends T> other, Function<? super T,U> fn)
這個額定的fn功效在第一個future被挪用時能完成。我不肯定這個專業化辦法的目標是甚麼，究竟一小我可以簡略地應用：fast.applyToEither(predictable).thenApply(fn)。由於我們保持用這個API，但我們切實其實不須要額定功效的運用法式，我會簡略地應用Function.identity()占位符：
CompletableFuture<String> fast = fetchFast();
CompletableFuture<String> predictable = fetchPredictably();
CompletableFuture<String> firstDone =
fast.applyToEither(predictable, Function.<String>identity());
第一個完成的future可以經由過程運轉。請留意，從客戶的角度來看，兩個futures現實上是在firstDone的前面而隱蔽的。客戶端只是期待著future來完成而且經由過程applyToEither()使適合最早的兩個義務完成時告訴客戶端。
12、多種聯合的CompletableFuture
我們如今曉得若何期待兩個future來完成（應用thenCombine()）並第一個完成(applyToEither())。但它可以擴大就任意數目的futures嗎？切實其實，應用static幫助辦法：
static CompletableFuture<Void< allOf(CompletableFuture<?<... cfs)
static CompletableFuture<Object< anyOf(CompletableFuture<?<... cfs)
allOf()當一切的潛伏futures完成時，應用了一個futures數組而且前往一個future（期待一切的妨礙）。另外一方面anyOf()將會期待最快的潛伏futures，請看一下前往futures的普通類型，這不是你所希冀的嗎？我們會在接上去的文章中存眷一下這個成績。
總結
我們摸索了全部CompletableFuture API。我確信如許就可以望風披靡了，所以鄙人一篇文章中我們將研討另外一個簡略的web爬蟲法式的完成，應用CompletableFuture辦法和Java 8 lambda表達式，我們也會看看CompletableFuture的
