一 、認識異步編程

通常Java開發(fā)人員喜歡使用同步代碼編寫程序,因為這種請求(request)/響應(response)的方式比較簡單，并且比較符合編程人員的思維習慣;這種做法很好，直到系統(tǒng)出現(xiàn)性能瓶頸；在同步編程方式時由于每個線程同時只能發(fā)起一個請求并同步等待返回，所以為了提高系統(tǒng)性能，此時我們就需要引入更多的線程來實現(xiàn)并行化處理；但是多線程下對共享資源進行訪問時，不可避免會引入資源爭用和并發(fā)問題；另外操作系統(tǒng)層面對線程的個數(shù)是有限制的，不可能通過無限的增加線程數(shù)來提供系統(tǒng)性能；最后使用同步阻塞的編程方式還會導致浪費資源，比如發(fā)起網(wǎng)絡(luò)IO請求時候，調(diào)用線程就會處于同步阻塞等待響應結(jié)果的狀態(tài)，而這時候調(diào)用線程明明可以去做其他事情，等網(wǎng)絡(luò)IO響應結(jié)果返回后在對結(jié)果進行處理。

可見通過增加單機系統(tǒng)線程個數(shù)的并行編程方式并不是靈丹妙藥；通過編寫異步、非阻塞的代碼，則可以使用相同的底層資源將執(zhí)行切換到另一個活動任務，然后在異步處理完成后在返回到當前線程進行繼續(xù)處理，從而提高系統(tǒng)性能。

異步編程是可以讓程序并行運行的一種手段，其可以讓程序中的一個工作單元與主應用程序線程分開獨立運行，并且等工作單元運行結(jié)束后通知主應用程序線程它的運行結(jié)果或者失敗原因。使用它有許多好處，例如可以提高應用程序的性能和響應能力。

比如當調(diào)用線程使用異步方式發(fā)起網(wǎng)絡(luò)IO請求后，調(diào)用線程就不會同步阻塞等待響應結(jié)果，而是在內(nèi)存保存請求上下文后，會馬上返回后做其他事情，等網(wǎng)絡(luò)IO響應結(jié)果返回后在使用IO線程通知業(yè)務線程響應結(jié)果已經(jīng)返回，然后業(yè)務線程在對結(jié)果進行處理。可知異步調(diào)用方式提高了線程的利用率，讓系統(tǒng)有更多的線程資源來處理更多的請求。

比如在移動應用程序中，在用戶操作移動設(shè)備屏幕發(fā)起請求后，如果是同步等待后臺服務器返回結(jié)果，則當后臺服務操作非常耗時時，就會造成用戶看到移動設(shè)備屏幕凍結(jié)（一直處理請求處理中），在結(jié)果返回前，用戶不能操作移動設(shè)備的其他功能，這對用戶體驗非常不好。而使用異步編程則當發(fā)起請求后，調(diào)用線程會馬上返回，具體返回結(jié)果則會通過UI線程異步進行渲染，而在這期間用戶可以使用移動設(shè)備的其他功能。

二、 異步編程場景概述

在日常開發(fā)中我們經(jīng)常會遇到這樣的情況，就是需要異步的處理一些事情，而不需要知道異步任務的結(jié)果；比如在調(diào)用線程里面異步打日志，為了不讓日志打印阻塞調(diào)用線程，會把日志設(shè)置為異步方式。如下圖1-2-1日志異步化打印，使用一個內(nèi)存隊列把日志打印異步化，使用單一線程來消費隊列里面日志事件執(zhí)行具體的日志落盤操作（本質(zhì)是一個多生產(chǎn)單消費模型），這種情況下調(diào)用線程把日志任務放入隊列后就繼續(xù)去干自己的事情了，而不再關(guān)心日志任務具體是什么時候入盤的；

圖 1-2-1 日志異步打印

在Java中每當我們需要執(zhí)行異步任務的時候我們可以直接開啟一個線程來實現(xiàn)，也可以把異步任務封裝為任務對象投遞到線程池里面來執(zhí)行，在Spring框架中則提供了@Async注解把一個任務異步化來進行處理，這些內(nèi)容會在后面章節(jié)具體講解。

另外有時候我們還需要在主線程等待異步任務的執(zhí)行結(jié)果，這時候Future就排上用場了；比如調(diào)用線程要等執(zhí)行任務A執(zhí)行完畢后在順序執(zhí)行任務B，并且把兩者結(jié)果拼接起來作為前端展示使用，如果調(diào)用線程是同步調(diào)用兩次查詢（如下圖1-2-2同步調(diào)用），則整個過程耗時時間為執(zhí)行任務A的耗時加上執(zhí)行任務B的耗時。

圖1-2-2 同步調(diào)用

如果使用異步編程（如下圖1-2-3）則可以在調(diào)用線程內(nèi)開啟一個異步運行單元來執(zhí)行任務A，開啟異步運行單元后調(diào)用線程會馬上返回一個Future對象（futureB），然后調(diào)用線程本身來執(zhí)行任務B，等任務B執(zhí)行完畢后，調(diào)用線程可以調(diào)用futureB的get（）方法獲取任務A的執(zhí)行結(jié)果，最后在拼接兩者結(jié)果。這時由于任務A和任務B是并行運行的，所以整個過程耗時為max(調(diào)用線程執(zhí)行任務B耗時，異步運行單元執(zhí)行任務A耗時）。

圖1-2-3 異步調(diào)用

可見整個過程耗時有顯著縮短，對于用戶來說頁面響應時間會更短，對用戶體驗會更好，其中異步單元的執(zhí)行一般是線程池中的線程。

使用Future確實可以獲取異步任務的執(zhí)行結(jié)果，但是獲取其結(jié)果還是會阻塞調(diào)用線程的，并沒有實現(xiàn)完全異步化處理，在JDK8中提供了CompletableFuture來彌補了其缺點。CompletableFuture類允許以非阻塞方式和基于通知的方式處理結(jié)果，其通過設(shè)置回調(diào)函數(shù)方式，讓主線程徹底解放出來，做自己的事情，實現(xiàn)了實際意義上的異步處理；

如下圖1-2-4使用CompletableFuture時候當異步單元返回futureB后，調(diào)用線程可以在其上調(diào)用whenComplete方法設(shè)置一個回調(diào)函數(shù)action,然后調(diào)用線程就會馬上返回了，等異步任務執(zhí)行完畢后會使用異步線程來執(zhí)行回調(diào)函數(shù)action，而無需調(diào)用線程干預，如果你對CompletableFuture不了解，沒關(guān)系，后面章節(jié)我們會詳細講解，這里你只需要知道其解決了傳統(tǒng)Future的缺陷就可以了。

圖1-2-4 CompletableFuture異步執(zhí)行

JDK8還引入了Stream，它旨在有效地處理數(shù)據(jù)流（包括原始類型），其使用聲明式編程讓我們可以寫出可讀性、可維護性很強的代碼，并且結(jié)合CompletableFuture可以完美的實現(xiàn)異步編程。但是它產(chǎn)生的流只能使用一次，并且缺少與時間相關(guān)的操作（例如RxJava中的基于時間窗口的緩存元素），雖然可以執(zhí)行并行計算，但無法指定要使用的線程池。并且它還沒有設(shè)計用于處理延遲的操作（例如RxJava中的defer操作）；而Reactor或RxJava等Reactive API就是為了解決這些問題而生的。

Reactor或RxJava等反應式API也提供Java 8 Stream的運算符，但它們更適用于任何流序列（不僅僅是集合），并允許定義一個轉(zhuǎn)換操作的管道，該管道將應用于通過它的數(shù)據(jù)，這要歸功于方便的流暢API和Lambda表達式的使用。Reactive旨在處理同步或異步操作，并允許您緩沖（buffer）、合并（merge）、連接(join) 元素等對元素做各種轉(zhuǎn)換。

上面我們講解了單JVM內(nèi)的異步編程，那么對于跨網(wǎng)絡(luò)的交互是否也存在異步編程范疇那？對于網(wǎng)絡(luò)請求來說，同步調(diào)用時比較直截了當?shù)?#xff0c;比如我們在一個線程A中通過RPC請求獲取服務B和服務C的數(shù)據(jù)，然后基于兩者結(jié)果做一些事情。在同步調(diào)用情況下，線程A需要調(diào)用服務B，然后需要同步等待服務B結(jié)果返回后，才可以對服務C發(fā)起調(diào)用，然后等服務C結(jié)果返回后才可以結(jié)合服務B和C的結(jié)果做一件事,如下圖1-2-5：

圖1-2-5 同步RPC調(diào)用

如上圖1-2-5線程A同步獲取服務B結(jié)果后，在同步調(diào)用服務C獲取結(jié)果，可見在同步調(diào)用情況下業(yè)務執(zhí)行語義比較清晰，線程A順序的對多個服務請求進行調(diào)用；但是同步調(diào)用意味著當前發(fā)起請求的調(diào)用線程在遠端機器返回結(jié)果前必須阻塞等待，這明顯很浪費資源。好的做法應該是發(fā)起請求的調(diào)用線程發(fā)起請求后，注冊一個回調(diào)函數(shù)，然后馬上返回去做其他事情，當遠端把結(jié)果返回后在使用IO線程執(zhí)行回調(diào)函數(shù)。

那么如何實現(xiàn)異步調(diào)用？在Java中NIO的出現(xiàn)讓實現(xiàn)上面的功能變得簡單，而高性能異步、基于事件驅(qū)動的網(wǎng)絡(luò)編程框架Netty的出現(xiàn)讓我們從編寫繁雜的Java NIO程序出解放出來了，現(xiàn)在的RPC框架比如Dubbo底層網(wǎng)絡(luò)通信就是基于Netty實現(xiàn)的;Netty框架將網(wǎng)絡(luò)編程邏輯與業(yè)務邏輯處理分離開來，其內(nèi)部幫我們自動處理好網(wǎng)絡(luò)與異步處理邏輯，讓我們專心寫自己的業(yè)務處理邏輯，Netty的異步非阻塞能力與CompletableFuture結(jié)合就可以輕松的實現(xiàn)網(wǎng)絡(luò)請求的異步調(diào)用。

在執(zhí)行RPC(遠程過程調(diào)用)調(diào)用時候，使用異步編程可以提高系統(tǒng)的性能；如下圖1-2-6，在異步調(diào)用情況下，當線程A調(diào)用服務B后，馬上會返回一個異步的futureB對象，然后線程A可以在futureB上設(shè)置一個回調(diào)函數(shù)；然后線程A可以繼續(xù)訪問服務C，也會馬上返回一個futureC對象，然后線程A可以在futureC上設(shè)置一個回調(diào)函數(shù)：

圖1-2-6 RPC異步調(diào)用

如上圖1-2-6可知異步調(diào)用情況下線程A可以并發(fā)的調(diào)用服務B和服務C，而不再是順序的，由于服務B和服務C是并發(fā)運行，所以相比線程A同步調(diào)用，線程A獲取到服務B和服務C結(jié)果的時間會縮短很多（同步調(diào)用情況下耗時時間為服務B和服務C返回結(jié)果耗時的和，異步調(diào)用時候耗時為max(服務B耗時，服務C耗時））；另外這里可以借助CompletableFuture的能力等兩次RPC調(diào)用都異步返回結(jié)果后做一件事情，這時候調(diào)用流程如下圖圖1-2-7：

圖1-2-7 合并Rpc調(diào)用結(jié)果

如上圖圖1-2-7調(diào)用線程A首先發(fā)起服務B的遠程調(diào)用，然后馬上返回一個futureB對象，然后發(fā)起服務C的遠程調(diào)用，然后馬上返回一個futureC對象，最后調(diào)用線程A使用代碼futureB.thenCombine(futureC,action)等futureB和futureC結(jié)果可用時候執(zhí)行回調(diào)函數(shù)action；這里我們只是簡單的概述下基于Netty的異步非阻塞能力以及CompletableFuture的可編排能力，我們可以實現(xiàn)功能很強大的異步編程能力，后面章節(jié)我們會以Dubbo框架為例講解其借助Netty的非阻塞異步API實現(xiàn)了服務消費端的異步調(diào)用。

其實有了CompletableFuture實現(xiàn)異步編程，我們可以很自然的使用適配器來實現(xiàn)Reactive風格的編程，當我們使用RxJava API時候我們只需要使用Flowable的一些函數(shù)轉(zhuǎn)換CompletableFuture為Flowable對象即可，這個我們在后面章節(jié)也會講述。

上節(jié)講解了網(wǎng)絡(luò)請求中的RPC框架的異步請求，其實還有一類，也就是Web請求，在Web應用中Servlet占有一席之地。在Servlet3.0規(guī)范前，Servlet容器對Servlet的處理都是每個請求對應一個線程這種1：1的模式進行處理的（如下圖1-2-8），每當來一個請求時候都會開啟一個Servlet容器內(nèi)的線程來進行處理，如果Servlet內(nèi)處理比較耗時，則會把Servlet容器內(nèi)線程使用耗盡，然后容器就不能再處理新的請求。

圖1-2-8 Servlet的阻塞處理模型

Servlet3.0規(guī)范中則提供了異步處理的能力，讓Servlet容器中的線程可以及時釋放，具體Servlet業(yè)務處理邏輯是在業(yè)務自己線程池內(nèi)來處理；雖然Servlet3.0規(guī)范讓Servlet的執(zhí)行變?yōu)榱水惒?#xff0c;但是其IO還是阻塞式的，IO阻塞是說在Servlet處理請求時候從ServletInputStream中讀取請求體時候是阻塞的，而我們想要的是當數(shù)據(jù)已經(jīng)就緒時候通知我們?nèi)プx取就可以了，因為這可以避免占用我們自己的線程來進行阻塞讀取，Servlet3.1規(guī)范則提供了非阻塞IO來解決這個問題。

雖然Servlet技術(shù)棧的不斷發(fā)展實現(xiàn)了異步處理與非阻塞IO，但是其異步是不徹底的，因為受制于Servlet規(guī)范本身，比如其規(guī)范是同步的（Filter，Servlet）或阻塞（getParameter，getPart）。所以新的使用少量線程和較少的硬件資源來處理并發(fā)的非阻塞Web技術(shù)棧應運而生-WebFlux,其是與Servlet技術(shù)棧并行存在的一種新的技術(shù)，其基于JDK8函數(shù)式編程與Netty實現(xiàn)天然的異步、非阻塞處理，這些我們在后面章節(jié)會具體介紹。

另外為了更好的處理異步編程，降低我們異步編程的成本，一些框架也應運而生，比如高性能線程間消息傳遞庫Disruptor，其通過為事件（events）預先分配內(nèi)存、無鎖CAS算法、緩沖行填充、兩階段協(xié)議提交來實現(xiàn)多線程并發(fā)的處理不同的元素，從而實現(xiàn)高性能的異步處理；比如Akka其基于Actor模式實現(xiàn)了天然支持分布式的使用消息進行異步處理的服務；比如高性能分布式消息中間件Apache RocketMetaQ用來實現(xiàn)應用間的異步解耦、流量削峰。

一些新興的語言對異步處理的支持能力讓我們?nèi)滩蛔》Q贊，GoLang就是其中之一，其通過語言層面內(nèi)置的goroutine與channel可以輕松的實現(xiàn)復雜的異步處理能力。

《Java異步編程實戰(zhàn)》)，一書則是根據(jù)上述介紹的次序，把內(nèi)容劃分了若干章節(jié)，每章則具體展開討論相應的異步編程技術(shù)。

三、 為何寫作本書

異步編程是可以讓程序并行運行的一種手段，其可以讓程序中的一個工作單元與主應用程序線程分開獨立運行，使用它有許多好處，例如可以提高應用程序的性能和響應能力。

雖然Java中不同技術(shù)域提供了相應的異步編程技術(shù)，但是對異步編程技術(shù)的描述散落到了不同技術(shù)域的技術(shù)文檔中，并沒有一個統(tǒng)一的地方對這些技術(shù)進行梳理歸納。另外這些技術(shù)之間是什么關(guān)系，各自的出現(xiàn)都是為了解決什么問題，我們也很難找到資料來解釋。

本書的出現(xiàn)則是為了打破這種局面，本書旨在把Java中相關(guān)的異步編程技術(shù)進行歸納分類總結(jié)，然后呈現(xiàn)給大家，讓大家可以有一個統(tǒng)一的地方來查看與探究。

四、本書特色

本書涵蓋了Java中常見的異步編程場景，這包含單JVM內(nèi)的異步編程、以及跨主機通過網(wǎng)絡(luò)通訊的遠程過程調(diào)用的異步調(diào)用與異步處理、以及Web請求的異步處理等等。

本書在講解Java中每種異步編程技術(shù)時都附有案例，以便理論與實踐進行結(jié)合。

本書在講解每種異步編程技術(shù)時大多都會對其實現(xiàn)原理進行講解，以便讓讀者知其然也知其所以然。

本書對最近比較火的反應式編程以及WebFlux的使用與原理解析有一定深入的探索。

五、 業(yè)界推薦

原文鏈接
本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的认识Java异步编程的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。