这篇文章主要介绍“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学习的误解有哪些”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注创新互联网站，小编会继续努力为大家带来更多实用的文章！

新闻标题：JavaAIO学习的误解有哪些
地址分享：http://kswjz.com/article/picdeh.html