Java AIO學習的誤解有哪些

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

誤解一

通過上表的比較可以看出 AIO 的性價比應該是優于 NIO 的，而實際情況卻是大多數人更偏愛與 NIO，準確的說應該是偏愛 NIO  通信框架：Netty。這本無可厚非，Netty 確實是一款非常優秀的項目，可是很多人錯誤的解讀了 Netty 在 Github 上關于不支持 AIO  的理由，這更加遏制了 AIO 的發展。

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

這句話表達的本意應該是：NIO 和 AIO 在 unix 系統上使用的都是 epoll 模式，本質都是一樣的。但Not faster than  NIO在一定程度上會讓人誤解為 AIO 沒 NIO 快。 這里可以采用假設的方式來論證這個觀點是不成立的。

假設：

epoll 表現的性能為 x=100;

通信框架因為要解決并發調度與資源分配問題，對 epoll 進行封裝后會存在一定的性能損耗，以 y 表示。

最終性能表現結果應該是 r=x-y。

論證：

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

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

結論：

以底層模型是 kqueue、epoll、select 還是 IOCP 來比較 NIO 和 AIO  的性能是不嚴謹的，決定權在于框架實現能挖掘出多少基礎能力。否則同樣采用 NIO 技術，為什么不同的框架還是會有高低之分。

誤解二

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

這是個很奇怪的現象，似乎曾經不支持 AIO 就覺得永遠不支持，曾經出現的 bug 就永遠存在。正如 JAVA NIO 的空輪訓 bug ，如今都已經發展到  Java 13 了，依舊還有人堅信這個 bug 一直在。坦白的講，我沒有去驗證過 Java AIO 在 Linux 環境下是否是真正意義的 AIO，也沒有復現出  NIO 的空輪訓 bug。但如果因為某種原因放棄持續學習，那對于事物的認知和見識就只能停留在過去。

所以”Linux 系統的 AIO 還不成熟“也不會成為我拋棄 AIO 的理由。

誤解三

需要為每一個連接預先分配讀緩存。這個確實是客觀存在的情況，AIO  的使用方式是調用讀寫接口將ByteBuffer對象注冊進去，當事件完成后以回調的形式觸發CompletionHandler，所以必須要事先分配好緩存空間。

但是有一個細節可能會被大家忽略掉，即便采用  NIO，當遇到半包/粘包的的情況，還是需要有一個緩存對象來暫存這份不完整的數據。尤其在高并發場景下，半包/粘包現象很容易加劇，此時 NIO 需要分配的緩存并不比  AIO 節省多少。

即使假設理想狀態下并不存在半包/粘包問題，AIO 通信的預分配形式又能額外消耗多少內存。為每個連接分配 1024  字節的讀緩存，在1萬個并發連接的條件下也才消耗不到 10MB 內存，試問現實場景下一臺 Java  應用服務器需要同時支撐多少個并發，1萬?5萬?10萬?。

目前已知的通信框架通常會配備內存池，在這種前提下 AIO 也只是將內存池中的資源提前利用起來而已。在同等的內存池配置，相同的并發壓力下，如果 AIO  暴露出內存方面的問題，我們再來做 AIO 和 NIO 的選擇。

到此，關于“Java AIO學習的誤解有哪些”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！