透過現象看Java AIO的本質 | 得物技術

語言: CN / TW / HK

1.前言

關於Java BIO、NIO、AIO的區別和原理,這樣的文章非常的多的,但主要還是在BIO和NIO這兩者之間討論,而關於AIO這樣的文章就少之又少了,很多隻是介紹了一下概念和代碼示例。

在瞭解AIO時,有注意到以下幾個現象:

1、 2011年Java 7發佈,裏面增加了AIO稱之為異步IO的編程模型,但已經過去了近12年,平時使用的開發框架中間件,還是以NIO為主,例如網絡框架Netty、Mina,Web容器Tomcat、Undertow。

2、 Java AIO又稱為NIO 2.0,難道它也是基於NIO來實現的?

3、 Netty捨去了AIO的支持。https://github.com/netty/netty/issues/2515

4、 AIO看起來只是解決了有無,發佈了個寂寞。
這幾個現象不免會令很多人心存疑惑,所以決定寫這篇文章時,不想簡單的把AIO的概念再複述一遍,而是要透過現象, 如何分析、思考和理解Java AIO的本質。

2.什麼是異步

2.1 我們所瞭解的異步

AIO的A是Asynchronous異步的意思,在瞭解AIO的原理之前,我們先理清一下“異步”到底是怎樣的一個概念。
説起異步編程,在平時的開發還是比較常見,例如以下的代碼示例:

@Async
public void create() {
    //TODO
}
​
public void build() {
    executor.execute(() -> build());
}

不管是用@Async註解,還是往線程池裏提交任務,他們最終都是同一個結果,就是把要執行的任務,交給另外一個線程來執行。
這個時候,可以大致的認為,所謂的“異步”,就是多線程,執行任務。

2.2 Java BIO和NIO到底是同步還是異步?

Java BIO和NIO到底是同步還是異步,我們先按照異步這個思路,做異步編程。

2.2.1 BIO示例

byte [] data = new byte[1024];
InputStream in = socket.getInputStream();
in.read(data);
// 接收到數據,異步處理
executor.execute(() -> handle(data));
​
public void handle(byte [] data) {
    // TODO
}

BIO在read()時,雖然線程阻塞了,但在收到數據時,可以異步啟動一個線程去處理。

2.2.2 NIO示例

selector.select();
Set<SelectionKey> keys = selector.selectedKeys();
Iterator<SelectionKey> 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
}

同理,NIO雖然read()是非阻塞的,通過select()可以阻塞等待數據,在有數據可讀的時候,異步啟動一個線程,去讀取數據和處理數據。

2.2.3 產生理解的偏差

此時我們信誓旦旦的説,Java的BIO和NIO是異步還是同步,取決你的心情,你高興給它個多線程,它就是異步的。

但果真如此麼,在翻閲了大量博客文章之後,基本一致的闡明瞭,BIO和NIO是同步的。

那問題點出在哪呢,是什麼造成了我們理解上的偏差呢?

那就是參考系的問題,以前學物理時,公交車上的乘客是運動還是靜止,需要有參考系前提,如果以地面為參考,他是運動的,以公交車為參考,他是靜止的。

Java IO也是一樣,需要有個參考系,才能定義它是同步異步,既然我們討論的是IO是哪一種模式,那就是要針對IO讀寫操作這件事來理解,而其他的啟動另外一個線程去處理數據,已經是脱離IO讀寫的範圍了,不應該把他們扯進來。

2.2.4 嘗試定義異步

所以以IO讀寫操作這事件作為參照,我們先嚐試的這樣定義,就是發起IO讀寫的線程(調用read和write的線程),和實際操作IO讀寫的線程,如果是同一個線程,就稱之為同步,否則是異步

  • 顯然BIO只能是同步,調用in.read()當前線程阻塞,有數據返回的時候,接收到數據的還是原來的線程。

  • 而NIO也稱之為同步,原因也是如此,調用channel.read()時,線程雖然不會阻塞,但讀到數據的還是當前線程。

按照這個思路,AIO應該是發起IO讀寫的線程,和實際收到數據的線程,可能不是同一個線程
是不是這樣呢,現在開始上Java AIO的代碼。

2.3 Java AIO的程序示例

2.3.1 AIO服務端程序

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<AsynchronousSocketChannel, Void>() {
​
            @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<Integer, ByteBuffer> {
    @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客户端程序

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 異步的定義猜想結論

分別運行服務端和客户端程序

640.png

在服務端運行結果裏,

main線程發起serverChannel.accept的調用,添加了一個CompletionHandler監聽回調,當有客户端連接過來時,Thread-5線程執行了accep的completed回調方法。

緊接着Thread-5又發起了clientChannel.read調用,也添加了個CompletionHandler監聽回調,當收到數據時,是Thread-1的執行了read的completed回調方法。

這個結論和上面異步猜想一致,發起IO操作(例如accept、read、write)調用的線程,和最終完成這個操作的線程不是同一個,我們把這種IO模式稱之AIO

當然了,這樣定義AIO只是為了方便我們理解,實際中對異步IO的定義可能更抽象一點。

3.AIO示例引發思考的問題

1、 執行completed()方法的這個線程是誰創建的,什麼時候創建的?

2、 AIO註冊事件監聽和執行回調是如何實現的?

3、 監聽回調的本質是什麼?

3.1 問題1:執行completed()方法的這個線程是誰創建的,什麼時候創建的

一般,這樣的問題,需要從程序的入口的開始瞭解,但跟線程相關,其實是可以從線程棧的運行情況來定位線程是怎麼運行。

只運行AIO服務端程序,客户端不運行,打印一下線程棧(備註:程序在Linux平台上運行,其他平台略有差異)

6401.png

分析線程棧,發現,程序啟動了那麼幾個線程

1、 線程Thread-0阻塞在EPoll.wait()方法上

2、 線程Thread-1、Thread-2。。。Thread-n(n和CPU核心數量一致)從阻塞隊列裏take()任務,阻塞等待有任務返回。

此時可以暫定下一個結論:

AIO服務端程序啟動之後,就開始創建了這些線程,且線程都處於阻塞等待狀態。

另外,發現這些線程的運行都跟Epoll有關係,提到Epoll,我們印象中,Java NIO在Linux平台底層就是用Epoll來實現的,難道Java AIO也是用Epoll來實現麼?為了證實這個結論,我們從下一個問題來展開討論

3.2 問題2:AIO註冊事件監聽和執行回調是如何實現的

帶着這個問題,去閲讀分析源碼時,發現源碼特別的長,而源碼解析是一項枯燥乏味的過程,很容易把閲讀者給逼走勸退掉。

對於長流程和邏輯複雜的代碼的理解,我們可以抓住它幾個脈絡,找出哪幾個核心流程。

以註冊監聽read為例clientChannel.read(…),它主要的核心流程是:

1、註冊事件 -> 2、監聽事件 -> 3、處理事件

3.2.1 1、註冊事件

6402.png

註冊事件調用EPoll.ctl(…)函數,這個函數在最後的參數用於指定是一次性的,還是永久性。上面代碼events | EPOLLONSHOT字面意思看來,是一次性的。

3.2.2 2、監聽事件

6408.png

3.2.3 3、處理事件

6409.png

64010.png

64011.png

3.2.4 核心流程總結

64012.png

在分析完上面的代碼流程後會發現,每一次IO讀寫都要經歷的這三個事件是一次性的,也就是在處理事件完,本次流程就結束了,如果想繼續下一次的IO讀寫,就得從頭開始再來一遍。這樣就會存在所謂的死亡回調(回調方法裏再添加下一個回調方法),這對於編程的複雜度大大提高了。

3.3 問題3: 監聽回調的本質是什麼?

先説一下結論,所謂監聽回調的本質,就是用户態線程,調用內核態的函數(準確的説是API,例如read,write,epollWait),該函數還沒有返回時,用户線程被阻塞了。當函數返回時,會喚醒阻塞的線程,執行所謂回調函數

對於這個結論的理解,要先引入幾個概念

3.3.1 系統調用與函數調用

函數調用:

找到某個函數,並執行函數裏的相關命令

系統調用:

操作系統對用户應用程序提供了編程接口,所謂API。

系統調用執行過程:

1.傳遞系統調用參數

2.執行陷入指令,用用户態切換到核心態,這是因為系統調用一般都需要再核心態下執行

3.執行系統調用程序

4.返回用户態

3.3.2 用户態和內核態之間的通信

用户態->內核態,通過系統調用方式即可。

內核態->用户態,內核態根本不知道用户態程序有什麼函數,參數是啥,地址在哪裏。所以內核是不可能去調用用户態的函數,只能通過發送信號,比如kill 命令關閉程序就是通過發信號讓用户程序優雅退出的。

既然內核態是不可能主動去調用用户態的函數,為什麼還會有回調呢,只能説這個所謂回調其實就是用户態的自導自演。它既做了監聽,又做了執行回調函數。

3.3.3 用實際例子驗證結論

為了驗證這個結論是否有説服力,舉個例子,平時開發寫代碼用的IntelliJ IDEA,它是如何監聽鼠標、鍵盤事件和處理事件的。

按照慣例,先打印一下線程棧,會發現鼠標、鍵盤等事件的監聽是由"AWT-XAWT"線程負責的,處理事件則是"AWT-EventQueue"線程負責。

64013.png

定位到具體的代碼上,可以看到"AWT-XAWT"正在做while循環,調用waitForEvents函數等待事件返回。如果沒有事件,線程就一直阻塞在那邊。

64014.png

4.Java AIO的本質是什麼?

1、由於內核態無法直接調用用户態函數,Java AIO的本質,就是隻在用户態實現異步。並沒有達到理想意義上的異步。

理想中的異步

何謂理想意義上的異步?這裏舉個網購的例子

兩個角色,消費者A,快遞員B

  • A在網上購物時,填好家庭地址付款提交訂單,這個相當於註冊監聽事件

  • 商家發貨,B把東西送到A家門口,這個相當於回調。

A在網上下完單,後續的發貨流程就不用他來操心了,可以繼續做其他事。B送貨也不關心A在不在家,反正就把貨扔到家門口就行了,兩個人互不依賴,互不相干擾

假設A購物是用户態來做,B送快遞是內核態來做,這種程序運行方式過於理想了,實際中實現不了。

現實中的異步

A住的是高檔小區,不能隨意進去,快遞只能送到小區門口。

A買了一件比較重的商品,比如一台電視,因為A要上班不在家裏,所以找了一個好友C幫忙把電視搬到他家。
A出門上班前,跟門口的保安D打聲招呼,説今天有一台電視送過來,送到小區門口時,請電話聯繫C,讓他過來拿。

  • 此時,A下單並跟D打招呼,相當於註冊事件。在AIO中就是EPoll.ctl(…)註冊事件。

  • 保安在門口蹲着相當於監聽事件,在AIO中就是Thread-0線程,做EPoll.wait(…)

  • 快遞員把電視送到門口,相當於有IO事件到達。

  • 保安通知C電視到了,C過來搬電視,相當於處理事件。

在AIO中就是Thread-0往任務隊列提交任務,

Thread-1 ~n去取數據,並執行回調方法。

整個過程中,保安D必須一直蹲着,寸步不能離開,否則電視送到門口,就被人偷了。

好友C也必須在A家待着,受人委託,東西到了,人卻不在現場,這有點失信於人。

所以實際的異步和理想中的異步,在互不依賴,互不干擾,這兩點相違背了。保安的作用最大,這是他人生的高光時刻。

異步過程中的註冊事件、監聽事件、處理事件,還有開啟多線程,這些過程的發起者全是用户態一手操辦,所以説Java AIO只在用户態實現了異步,這個和BIO、NIO先阻塞,阻塞喚醒後開啟異步線程處理的本質一致。

2、Java AIO跟NIO一樣,在各個平台的底層實現方式也不同,在Linux是用EPoll,Windows是IOCP,Mac OS是KQueue。原理是大同小異,都是需要一個用户線程阻塞等待IO事件,一個線程池從隊列裏處理事件。

3、 Netty之所以移除掉AIO,很大的原因是在性能上AIO並沒有比NIO高。Linux雖然也有一套原生的AIO實現(類似Windows上的IOCP),但Java AIO在Linux並沒有採用,而是用EPoll來實現。

4、 Java AIO不支持UDP

5、 AIO編程方式略顯複雜,比如“死亡回調”