1
前言
關(guān)于Java BIO、NIO、AIO的區(qū)別和原理,這樣的文章非常的多的,但主要還是在BIO和NIO這兩者之間討論,而關(guān)于AIO這樣的文章就少之又少了,很多只是介紹了一下概念和代碼示例。 在了解AIO時(shí),有注意到以下幾個(gè)現(xiàn)象:
1、 2011年Java 7發(fā)布,里面增加了AIO稱(chēng)之為異步IO的編程模型,但已經(jīng)過(guò)去了近12年,平時(shí)使用的開(kāi)發(fā)框架中間件,還是以NIO為主,例如網(wǎng)絡(luò)框架Netty、Mina,Web容器Tomcat、Undertow。
2、 Java AIO又稱(chēng)為NIO 2.0,難道它也是基于NIO來(lái)實(shí)現(xiàn)的?
3、 Netty舍去了AIO的支持。
4、 AIO看起來(lái)只是解決了有無(wú),發(fā)布了個(gè)寂寞。
這幾個(gè)現(xiàn)象不免會(huì)令很多人心存疑惑,所以決定寫(xiě)這篇文章時(shí),不想簡(jiǎn)單的把AIO的概念再?gòu)?fù)述一遍,而是要透過(guò)現(xiàn)象, 如何分析、思考和理解Java AIO的本質(zhì)。
2
什么是異步
2.1 我們所了解的異步
AIO的A是Asynchronous異步的意思,在了解AIO的原理之前,我們先理清一下“異步”到底是怎樣的一個(gè)概念。 說(shuō)起異步編程,在平時(shí)的開(kāi)發(fā)還是比較常見(jiàn),例如以下的代碼示例:
@Async public void create() { //TODO } public void build() { executor.execute(() -> build()); }
不管是用@Async注解,還是往線(xiàn)程池里提交任務(wù),他們最終都是同一個(gè)結(jié)果,就是把要執(zhí)行的任務(wù),交給另外一個(gè)線(xiàn)程來(lái)執(zhí)行。
這個(gè)時(shí)候,可以大致的認(rèn)為,所謂的“異步”,就是多線(xiàn)程,執(zhí)行任務(wù)。
2.2 Java BIO和NIO到底是同步還是異步?
Java BIO和NIO到底是同步還是異步,我們先按照異步這個(gè)思路,做異步編程。 2.2.1BIO示例
byte [] data = new byte[1024]; InputStream in = socket.getInputStream(); in.read(data); // 接收到數(shù)據(jù),異步處理 executor.execute(() -> handle(data)); public void handle(byte [] data) { // TODO }BIO在read()時(shí),雖然線(xiàn)程阻塞了,但在收到數(shù)據(jù)時(shí),可以異步啟動(dòng)一個(gè)線(xiàn)程去處理。 2.2.2NIO示例
selector.select(); Set同理,NIO雖然read()是非阻塞的,通過(guò)select()可以阻塞等待數(shù)據(jù),在有數(shù)據(jù)可讀的時(shí)候,異步啟動(dòng)一個(gè)線(xiàn)程,去讀取數(shù)據(jù)和處理數(shù)據(jù)。keys = selector.selectedKeys(); Iterator iterator = keys.iterator(); while (iterator.hasNext()) { SelectionKey key = iterator.next(); if (key.isReadable()) { SocketChannel channel = (SocketChannel) key.channel(); ByteBuffer byteBuffer = (ByteBuffer) key.attachment(); executor.execute(() -> { try { channel.read(byteBuffer); handle(byteBuffer); } catch (Exception e) { } }); } } public static void handle(ByteBuffer buffer) { // TODO }
2.2.3產(chǎn)生理解的偏差
此時(shí)我們信誓旦旦的說(shuō),Java的BIO和NIO是異步還是同步,取決你的心情,你高興給它個(gè)多線(xiàn)程,它就是異步的。 但果真如此么,在翻閱了大量博客文章之后,基本一致的闡明了,BIO和NIO是同步的。
那問(wèn)題點(diǎn)出在哪呢,是什么造成了我們理解上的偏差呢? 那就是參考系的問(wèn)題,以前學(xué)物理時(shí),公交車(chē)上的乘客是運(yùn)動(dòng)還是靜止,需要有參考系前提,如果以地面為參考,他是運(yùn)動(dòng)的,以公交車(chē)為參考,他是靜止的。
Java IO也是一樣,需要有個(gè)參考系,才能定義它是同步異步,既然我們討論的是IO是哪一種模式,那就是要針對(duì)IO讀寫(xiě)操作這件事來(lái)理解,而其他的啟動(dòng)另外一個(gè)線(xiàn)程去處理數(shù)據(jù),已經(jīng)是脫離IO讀寫(xiě)的范圍了,不應(yīng)該把他們扯進(jìn)來(lái)。
2.2.4嘗試定義異步
所以以IO讀寫(xiě)操作這事件作為參照,我們先嘗試的這樣定義,就是發(fā)起IO讀寫(xiě)的線(xiàn)程(調(diào)用read和write的線(xiàn)程),和實(shí)際操作IO讀寫(xiě)的線(xiàn)程,如果是同一個(gè)線(xiàn)程,就稱(chēng)之為同步,否則是異步。
顯然BIO只能是同步,調(diào)用in.read()當(dāng)前線(xiàn)程阻塞,有數(shù)據(jù)返回的時(shí)候,接收到數(shù)據(jù)的還是原來(lái)的線(xiàn)程。
而NIO也稱(chēng)之為同步,原因也是如此,調(diào)用channel.read()時(shí),線(xiàn)程雖然不會(huì)阻塞,但讀到數(shù)據(jù)的還是當(dāng)前線(xiàn)程。
按照這個(gè)思路,AIO應(yīng)該是發(fā)起IO讀寫(xiě)的線(xiàn)程,和實(shí)際收到數(shù)據(jù)的線(xiàn)程,可能不是同一個(gè)線(xiàn)程 是不是這樣呢,現(xiàn)在開(kāi)始上Java AIO的代碼。
2.3 Java AIO的程序示例
2.3.1 AIO服務(wù)端程序
public class AioServer { public static void main(String[] args) throws IOException { System.out.println(Thread.currentThread().getName() + " AioServer start"); AsynchronousServerSocketChannel serverChannel = AsynchronousServerSocketChannel.open() .bind(new InetSocketAddress("127.0.0.1", 8080)); serverChannel.accept(null, new CompletionHandler() { @Override public void completed(AsynchronousSocketChannel clientChannel, Void attachment) { System.out.println(Thread.currentThread().getName() + " client is connected"); ByteBuffer buffer = ByteBuffer.allocate(1024); clientChannel.read(buffer, buffer, new ClientHandler()); } @Override public void failed(Throwable exc, Void attachment) { System.out.println("accept fail"); } }); System.in.read(); } } public class ClientHandler implements CompletionHandler { @Override public void completed(Integer result, ByteBuffer buffer) { buffer.flip(); byte [] data = new byte[buffer.remaining()]; buffer.get(data); System.out.println(Thread.currentThread().getName() + " received:" + new String(data, StandardCharsets.UTF_8)); } @Override public void failed(Throwable exc, ByteBuffer buffer) { } }
2.3.2 AIO客戶(hù)端程序
public class AioClient { public static void main(String[] args) throws Exception { AsynchronousSocketChannel channel = AsynchronousSocketChannel.open(); channel.connect(new InetSocketAddress("127.0.0.1", 8080)); ByteBuffer buffer = ByteBuffer.allocate(1024); buffer.put("Java AIO".getBytes(StandardCharsets.UTF_8)); buffer.flip(); Thread.sleep(1000L); channel.write(buffer); } }
2.3.3 異步的定義猜想結(jié)論
分別運(yùn)行服務(wù)端和客戶(hù)端程序
在服務(wù)端運(yùn)行結(jié)果里, main線(xiàn)程發(fā)起serverChannel.accept的調(diào)用,添加了一個(gè)CompletionHandler監(jiān)聽(tīng)回調(diào),當(dāng)有客戶(hù)端連接過(guò)來(lái)時(shí),Thread-5線(xiàn)程執(zhí)行了accep的completed回調(diào)方法。 緊接著Thread-5又發(fā)起了clientChannel.read調(diào)用,也添加了個(gè)CompletionHandler監(jiān)聽(tīng)回調(diào),當(dāng)收到數(shù)據(jù)時(shí),是Thread-1的執(zhí)行了read的completed回調(diào)方法。
這個(gè)結(jié)論和上面異步猜想一致,發(fā)起IO操作(例如accept、read、write)調(diào)用的線(xiàn)程,和最終完成這個(gè)操作的線(xiàn)程不是同一個(gè),我們把這種IO模式稱(chēng)之AIO, 當(dāng)然了,這樣定義AIO只是為了方便我們理解,實(shí)際中對(duì)異步IO的定義可能更抽象一點(diǎn)。
3
AIO示例引發(fā)思考的問(wèn)題
1、 執(zhí)行completed()方法的這個(gè)線(xiàn)程是誰(shuí)創(chuàng)建的,什么時(shí)候創(chuàng)建的?
2、 AIO注冊(cè)事件監(jiān)聽(tīng)和執(zhí)行回調(diào)是如何實(shí)現(xiàn)的?
3、 監(jiān)聽(tīng)回調(diào)的本質(zhì)是什么?
3.1 問(wèn)題1:執(zhí)行completed()方法的這個(gè)線(xiàn)程是誰(shuí)創(chuàng)建的,什么時(shí)候創(chuàng)建的
一般,這樣的問(wèn)題,需要從程序的入口的開(kāi)始了解,但跟線(xiàn)程相關(guān),其實(shí)是可以從線(xiàn)程棧的運(yùn)行情況來(lái)定位線(xiàn)程是怎么運(yùn)行。 只運(yùn)行AIO服務(wù)端程序,客戶(hù)端不運(yùn)行,打印一下線(xiàn)程棧(備注:程序在Linux平臺(tái)上運(yùn)行,其他平臺(tái)略有差異)
分析線(xiàn)程棧,發(fā)現(xiàn),程序啟動(dòng)了那么幾個(gè)線(xiàn)程
1、 線(xiàn)程Thread-0阻塞在EPoll.wait()方法上
2、 線(xiàn)程Thread-1、Thread-2。。。Thread-n(n和CPU核心數(shù)量一致)從阻塞隊(duì)列里take()任務(wù),阻塞等待有任務(wù)返回。 此時(shí)可以暫定下一個(gè)結(jié)論: AIO服務(wù)端程序啟動(dòng)之后,就開(kāi)始創(chuàng)建了這些線(xiàn)程,且線(xiàn)程都處于阻塞等待狀態(tài)。
另外,發(fā)現(xiàn)這些線(xiàn)程的運(yùn)行都跟Epoll有關(guān)系,提到Epoll,我們印象中,Java NIO在Linux平臺(tái)底層就是用Epoll來(lái)實(shí)現(xiàn)的,難道Java AIO也是用Epoll來(lái)實(shí)現(xiàn)么?為了證實(shí)這個(gè)結(jié)論,我們從下一個(gè)問(wèn)題來(lái)展開(kāi)討論
3.2 問(wèn)題2:AIO注冊(cè)事件監(jiān)聽(tīng)和執(zhí)行回調(diào)是如何實(shí)現(xiàn)的
帶著這個(gè)問(wèn)題,去閱讀分析源碼時(shí),發(fā)現(xiàn)源碼特別的長(zhǎng),而源碼解析是一項(xiàng)枯燥乏味的過(guò)程,很容易把閱讀者給逼走勸退掉。
對(duì)于長(zhǎng)流程和邏輯復(fù)雜的代碼的理解,我們可以抓住它幾個(gè)脈絡(luò),找出哪幾個(gè)核心流程。
以注冊(cè)監(jiān)聽(tīng)read為例clientChannel.read(...),它主要的核心流程是: 1、注冊(cè)事件 -> 2、監(jiān)聽(tīng)事件 -> 3、處理事件
3.2.1 1、注冊(cè)事件
注冊(cè)事件調(diào)用EPoll.ctl(...)函數(shù),這個(gè)函數(shù)在最后的參數(shù)用于指定是一次性的,還是永久性。
上面代碼events | EPOLLONSHOT字面意思看來(lái),是一次性的。
3.2.2 2、監(jiān)聽(tīng)事件
3.2.3 3、處理事件
3.2.4 核心流程總結(jié)
在分析完上面的代碼流程后會(huì)發(fā)現(xiàn),每一次IO讀寫(xiě)都要經(jīng)歷的這三個(gè)事件是一次性的,也就是在處理事件完,本次流程就結(jié)束了,如果想繼續(xù)下一次的IO讀寫(xiě),就得從頭開(kāi)始再來(lái)一遍。這樣就會(huì)存在所謂的死亡回調(diào)(回調(diào)方法里再添加下一個(gè)回調(diào)方法),這對(duì)于編程的復(fù)雜度大大提高了。
3.3 問(wèn)題3: 監(jiān)聽(tīng)回調(diào)的本質(zhì)是什么?
先說(shuō)一下結(jié)論,所謂監(jiān)聽(tīng)回調(diào)的本質(zhì),就是用戶(hù)態(tài)線(xiàn)程,調(diào)用內(nèi)核態(tài)的函數(shù)(準(zhǔn)確的說(shuō)是API,例如read,write,epollWait),該函數(shù)還沒(méi)有返回時(shí),用戶(hù)線(xiàn)程被阻塞了。
當(dāng)函數(shù)返回時(shí),會(huì)喚醒阻塞的線(xiàn)程,執(zhí)行所謂回調(diào)函數(shù)。 對(duì)于這個(gè)結(jié)論的理解,要先引入幾個(gè)概念
3.3.1 系統(tǒng)調(diào)用與函數(shù)調(diào)用
函數(shù)調(diào)用: 找到某個(gè)函數(shù),并執(zhí)行函數(shù)里的相關(guān)命令 系統(tǒng)調(diào)用: 操作系統(tǒng)對(duì)用戶(hù)應(yīng)用程序提供了編程接口,所謂API。
系統(tǒng)調(diào)用執(zhí)行過(guò)程:
1.傳遞系統(tǒng)調(diào)用參數(shù)
2.執(zhí)行陷入指令,用用戶(hù)態(tài)切換到核心態(tài),這是因?yàn)橄到y(tǒng)調(diào)用一般都需要再核心態(tài)下執(zhí)行
3.執(zhí)行系統(tǒng)調(diào)用程序
4.返回用戶(hù)態(tài)
3.3.2 用戶(hù)態(tài)和內(nèi)核態(tài)之間的通信
用戶(hù)態(tài)->內(nèi)核態(tài),通過(guò)系統(tǒng)調(diào)用方式即可。 內(nèi)核態(tài)->用戶(hù)態(tài),內(nèi)核態(tài)根本不知道用戶(hù)態(tài)程序有什么函數(shù),參數(shù)是啥,地址在哪里。所以?xún)?nèi)核是不可能去調(diào)用用戶(hù)態(tài)的函數(shù),只能通過(guò)發(fā)送信號(hào),比如kill 命令關(guān)閉程序就是通過(guò)發(fā)信號(hào)讓用戶(hù)程序優(yōu)雅退出的。
既然內(nèi)核態(tài)是不可能主動(dòng)去調(diào)用用戶(hù)態(tài)的函數(shù),為什么還會(huì)有回調(diào)呢,只能說(shuō)這個(gè)所謂回調(diào)其實(shí)就是用戶(hù)態(tài)的自導(dǎo)自演。它既做了監(jiān)聽(tīng),又做了執(zhí)行回調(diào)函數(shù)。
3.3.3 用實(shí)際例子驗(yàn)證結(jié)論
為了驗(yàn)證這個(gè)結(jié)論是否有說(shuō)服力,舉個(gè)例子,平時(shí)開(kāi)發(fā)寫(xiě)代碼用的IntelliJ IDEA,它是如何監(jiān)聽(tīng)鼠標(biāo)、鍵盤(pán)事件和處理事件的。 按照慣例,先打印一下線(xiàn)程棧,會(huì)發(fā)現(xiàn)鼠標(biāo)、鍵盤(pán)等事件的監(jiān)聽(tīng)是由"AWT-XAWT"線(xiàn)程負(fù)責(zé)的,處理事件則是"AWT-EventQueue"線(xiàn)程負(fù)責(zé)。
定位到具體的代碼上,可以看到"AWT-XAWT"正在做while循環(huán),調(diào)用waitForEvents函數(shù)等待事件返回。如果沒(méi)有事件,線(xiàn)程就一直阻塞在那邊。
4
Java AIO的本質(zhì)是什么?
1、由于內(nèi)核態(tài)無(wú)法直接調(diào)用用戶(hù)態(tài)函數(shù),Java AIO的本質(zhì),就是只在用戶(hù)態(tài)實(shí)現(xiàn)異步。并沒(méi)有達(dá)到理想意義上的異步。
理想中的異步 何謂理想意義上的異步?這里舉個(gè)網(wǎng)購(gòu)的例子 兩個(gè)角色,消費(fèi)者A,快遞員B
A在網(wǎng)上購(gòu)物時(shí),填好家庭地址付款提交訂單,這個(gè)相當(dāng)于注冊(cè)監(jiān)聽(tīng)事件
商家發(fā)貨,B把東西送到A家門(mén)口,這個(gè)相當(dāng)于回調(diào)。
A在網(wǎng)上下完單,后續(xù)的發(fā)貨流程就不用他來(lái)操心了,可以繼續(xù)做其他事。B送貨也不關(guān)心A在不在家,反正就把貨扔到家門(mén)口就行了,兩個(gè)人互不依賴(lài),互不相干擾。 假設(shè)A購(gòu)物是用戶(hù)態(tài)來(lái)做,B送快遞是內(nèi)核態(tài)來(lái)做,這種程序運(yùn)行方式過(guò)于理想了,實(shí)際中實(shí)現(xiàn)不了。
現(xiàn)實(shí)中的異步 A住的是高檔小區(qū),不能隨意進(jìn)去,快遞只能送到小區(qū)門(mén)口。 A買(mǎi)了一件比較重的商品,比如一臺(tái)電視,因?yàn)锳要上班不在家里,所以找了一個(gè)好友C幫忙把電視搬到他家。 A出門(mén)上班前,跟門(mén)口的保安D打聲招呼,說(shuō)今天有一臺(tái)電視送過(guò)來(lái),送到小區(qū)門(mén)口時(shí),請(qǐng)電話(huà)聯(lián)系C,讓他過(guò)來(lái)拿。
此時(shí),A下單并跟D打招呼,相當(dāng)于注冊(cè)事件。在AIO中就是EPoll.ctl(...)注冊(cè)事件。
保安在門(mén)口蹲著相當(dāng)于監(jiān)聽(tīng)事件,在AIO中就是Thread-0線(xiàn)程,做EPoll.wait(..)
快遞員把電視送到門(mén)口,相當(dāng)于有IO事件到達(dá)。
保安通知C電視到了,C過(guò)來(lái)搬電視,相當(dāng)于處理事件。在AIO中就是Thread-0往任務(wù)隊(duì)列提交任務(wù),Thread-1 ~n去取數(shù)據(jù),并執(zhí)行回調(diào)方法。
整個(gè)過(guò)程中,保安D必須一直蹲著,寸步不能離開(kāi),否則電視送到門(mén)口,就被人偷了。 好友C也必須在A家待著,受人委托,東西到了,人卻不在現(xiàn)場(chǎng),這有點(diǎn)失信于人。
所以實(shí)際的異步和理想中的異步,在互不依賴(lài),互不干擾,這兩點(diǎn)相違背了。保安的作用最大,這是他人生的高光時(shí)刻。 異步過(guò)程中的注冊(cè)事件、監(jiān)聽(tīng)事件、處理事件,還有開(kāi)啟多線(xiàn)程,這些過(guò)程的發(fā)起者全是用戶(hù)態(tài)一手操辦,所以說(shuō)Java AIO只在用戶(hù)態(tài)實(shí)現(xiàn)了異步,這個(gè)和BIO、NIO先阻塞,阻塞喚醒后開(kāi)啟異步線(xiàn)程處理的本質(zhì)一致。
2、Java AIO跟NIO一樣,在各個(gè)平臺(tái)的底層實(shí)現(xiàn)方式也不同,在Linux是用EPoll,Windows是IOCP,Mac OS是KQueue。原理是大同小異,都是需要一個(gè)用戶(hù)線(xiàn)程阻塞等待IO事件,一個(gè)線(xiàn)程池從隊(duì)列里處理事件。
3、 Netty之所以移除掉AIO,很大的原因是在性能上AIO并沒(méi)有比NIO高。Linux雖然也有一套原生的AIO實(shí)現(xiàn)(類(lèi)似Windows上的IOCP),但Java AIO在Linux并沒(méi)有采用,而是用EPoll來(lái)實(shí)現(xiàn)。
4、 Java AIO不支持UDP
5、 AIO編程方式略顯復(fù)雜,比如“死亡回調(diào)”
審核編輯:劉清
-
Linux
+關(guān)注
關(guān)注
87文章
11304瀏覽量
209476 -
JAVA
+關(guān)注
關(guān)注
19文章
2967瀏覽量
104747 -
AIO
+關(guān)注
關(guān)注
1文章
61瀏覽量
9984 -
Thread
+關(guān)注
關(guān)注
2文章
83瀏覽量
25926
原文標(biāo)題:透過(guò)現(xiàn)象看Java AIO的本質(zhì)
文章出處:【微信號(hào):OSC開(kāi)源社區(qū),微信公眾號(hào):OSC開(kāi)源社區(qū)】歡迎添加關(guān)注!文章轉(zhuǎn)載請(qǐng)注明出處。
發(fā)布評(píng)論請(qǐng)先 登錄
相關(guān)推薦
評(píng)論