這篇文章主要介紹“Java AIO學(xué)習(xí)的誤解有哪些”，在日常操作中，相信很多人在Java AIO學(xué)習(xí)的誤解有哪些問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對(duì)大家解答”Java AIO學(xué)習(xí)的誤解有哪些”的疑惑有所幫助！接下來，請(qǐng)跟著小編一起來學(xué)習(xí)吧！

創(chuàng)新互聯(lián)建站是一家專業(yè)從事成都網(wǎng)站制作、成都網(wǎng)站設(shè)計(jì)、外貿(mào)營銷網(wǎng)站建設(shè)的網(wǎng)絡(luò)公司。作為專業(yè)的建站公司,創(chuàng)新互聯(lián)建站依托的技術(shù)實(shí)力、以及多年的網(wǎng)站運(yùn)營經(jīng)驗(yàn),為您提供專業(yè)的成都網(wǎng)站建設(shè)、全網(wǎng)營銷推廣及網(wǎng)站設(shè)計(jì)開發(fā)服務(wù)！

誤解一

通過上表的比較可以看出 AIO 的性價(jià)比應(yīng)該是優(yōu)于 NIO 的，而實(shí)際情況卻是大多數(shù)人更偏愛與 NIO，準(zhǔn)確的說應(yīng)該是偏愛 NIO  通信框架：Netty。這本無可厚非，Netty 確實(shí)是一款非常優(yōu)秀的項(xiàng)目，可是很多人錯(cuò)誤的解讀了 Netty 在 Github 上關(guān)于不支持 AIO  的理由，這更加遏制了 AIO 的發(fā)展。

Not faster than NIO (epoll) on unix systems (which is true)

這句話表達(dá)的本意應(yīng)該是：NIO 和 AIO 在 unix 系統(tǒng)上使用的都是 epoll 模式，本質(zhì)都是一樣的。但Not faster than  NIO在一定程度上會(huì)讓人誤解為 AIO 沒 NIO 快。 這里可以采用假設(shè)的方式來論證這個(gè)觀點(diǎn)是不成立的。

假設(shè)：

epoll 表現(xiàn)的性能為 x=100;

通信框架因?yàn)橐鉀Q并發(fā)調(diào)度與資源分配問題，對(duì) epoll 進(jìn)行封裝后會(huì)存在一定的性能損耗，以 y 表示。

最終性能表現(xiàn)結(jié)果應(yīng)該是 r=x-y。

論證：

某款 NIO 框架基于 epoll 封裝后的性能損耗值：y=5，則它所發(fā)揮的最終性能為：x-y=95。

如果有一款 AIO 框架能將性能損耗值控制在：y=(0,5) ,那最終性能便高于 NIO 框架。如 y>5，則性能低于 NIO 框架。

結(jié)論：

以底層模型是 kqueue、epoll、select 還是 IOCP 來比較 NIO 和 AIO  的性能是不嚴(yán)謹(jǐn)?shù)?，決定權(quán)在于框架實(shí)現(xiàn)能挖掘出多少基礎(chǔ)能力。否則同樣采用 NIO 技術(shù)，為什么不同的框架還是會(huì)有高低之分。

誤解二

Linux 系統(tǒng)的 AIO  還不成熟。如果是這個(gè)原因的話，不妨先看下：http://lse.sourceforge.net/io/aio.html，其中核心的一句話：Support for  kernel AIO has been included in the 2.6 Linux kernel.請(qǐng)注意，Linux 內(nèi)核自 2.6  版本起已支持AIO模式。

這是個(gè)很奇怪的現(xiàn)象，似乎曾經(jīng)不支持 AIO 就覺得永遠(yuǎn)不支持，曾經(jīng)出現(xiàn)的 bug 就永遠(yuǎn)存在。正如 JAVA NIO 的空輪訓(xùn) bug ，如今都已經(jīng)發(fā)展到  Java 13 了，依舊還有人堅(jiān)信這個(gè) bug 一直在。坦白的講，我沒有去驗(yàn)證過 Java AIO 在 Linux 環(huán)境下是否是真正意義的 AIO，也沒有復(fù)現(xiàn)出  NIO 的空輪訓(xùn) bug。但如果因?yàn)槟撤N原因放棄持續(xù)學(xué)習(xí)，那對(duì)于事物的認(rèn)知和見識(shí)就只能停留在過去。

所以”Linux 系統(tǒng)的 AIO 還不成熟“也不會(huì)成為我拋棄 AIO 的理由。

誤解三

需要為每一個(gè)連接預(yù)先分配讀緩存。這個(gè)確實(shí)是客觀存在的情況，AIO  的使用方式是調(diào)用讀寫接口將ByteBuffer對(duì)象注冊(cè)進(jìn)去，當(dāng)事件完成后以回調(diào)的形式觸發(fā)CompletionHandler，所以必須要事先分配好緩存空間。

但是有一個(gè)細(xì)節(jié)可能會(huì)被大家忽略掉，即便采用  NIO，當(dāng)遇到半包/粘包的的情況，還是需要有一個(gè)緩存對(duì)象來暫存這份不完整的數(shù)據(jù)。尤其在高并發(fā)場景下，半包/粘包現(xiàn)象很容易加劇，此時(shí) NIO 需要分配的緩存并不比  AIO 節(jié)省多少。

即使假設(shè)理想狀態(tài)下并不存在半包/粘包問題，AIO 通信的預(yù)分配形式又能額外消耗多少內(nèi)存。為每個(gè)連接分配 1024  字節(jié)的讀緩存，在1萬個(gè)并發(fā)連接的條件下也才消耗不到 10MB 內(nèi)存，試問現(xiàn)實(shí)場景下一臺(tái) Java  應(yīng)用服務(wù)器需要同時(shí)支撐多少個(gè)并發(fā)，1萬?5萬?10萬?。

目前已知的通信框架通常會(huì)配備內(nèi)存池，在這種前提下 AIO 也只是將內(nèi)存池中的資源提前利用起來而已。在同等的內(nèi)存池配置，相同的并發(fā)壓力下，如果 AIO  暴露出內(nèi)存方面的問題，我們?cè)賮碜?AIO 和 NIO 的選擇。

到此，關(guān)于“Java AIO學(xué)習(xí)的誤解有哪些”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識(shí)，請(qǐng)繼續(xù)關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編會(huì)繼續(xù)努力為大家?guī)砀鄬?shí)用的文章！