为什么说 AIO 受”误解“，虽然这个”误解“被打上了双引号，但还是不得不承认它的发展状况并不好。AIO 是 Java 7 开始提供的新特性，而这个”新特性“到如今都成了陈年老酒还鲜有人去品味它。要知道 Java 7 可是在 2011年7月份发布的，市面上基于 AIO 实现的通信框架竟然寥寥无几，关于这项技术的介绍文章也普遍比较粗略。通过阅读那些介绍 AIO 的文章，似乎从学术层面大家就不怎么待见这项技术。
作为 AIO 的学习者、受益者，我觉得有必要先对网上的一些 ”偏见“ 表达一下自己的观点。如果能有幸在认知上搭成共识，之后的学习交流会更加顺畅一点。通常偏见源于比较，AIO 与 BIO、NIO 的对比明细如表所示。
误解一
通过上表的比较可以看出 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 的选择。
总结
本文并不是要将 NIO 和 AIO 对立起来，这两项技术都非常吸引人，喜欢技术的朋友可以在这方面钻研很久。个人推荐纯粹出于学习优先考虑 NIO，因为难度更高，更具挑战性，将要面临和需要解决的问题更多。在学习的过程中如果遇到困惑，可以再去翻一下 AIO 的源码，里面有很多值得借鉴的设计。
