AIO

AIO是I/O模型里一个很高的层次，体现了大道至简的软件美学理念。与NIO相比，AIO的框架和使用方法相对简单很多。

AIO包括两大部分:AIO Files解决了文件的异步处理问题，AIO Sockets解决了Socket的异步处理问题。AIO的核心概念为应用发起非阻塞方式的IO操作，在I/O操作完成时通知应用，同时，应用程序的职责很明确，比如什么时候发起IO操作请求，在I/O操作完成时通知谁来处理。

下图给出了AIO Sockets对读请求的处理流程（写请求同理)，应用程序在有读请求时就向Kenel注册此请求，应用的线程就可以继续执行其他操作而无须等待。与此同时，Kernel在发现有数据到达Socket以后，就将数据从内核复制到应用程序的 Buffer里，在复制完成后，回调应用程序的通知接口，应用程序就可以处理此数据了。

架构解密从分布式到微服务：深入理解网络，AIO

在编写AIO Socket程序时，我们所要掌握的最关键的一个类是回调接口一CompletionHandler<V,A>，它包括两个方法:void completed(V result,A attachment); voidfailed(Throwable exc,attachment)。

其中，completed方法是异步请求完成时的通知接口，result是返回的结果;attachment则是应用程序捆绑在这个回调接口上的任意对象，可以记录客户端连接对象，或者用来保存Session会话的状态数据，例如已读取的字节信息等。failed方法则表明I/O事件异常，通常是不可恢复的故障.completed方法中的V与A具体是什么对象呢?这取决于调用者，比如在
AsynchronousServerSocketChannel对象中异步接收客户端连接请求的方法签名如下:

AsynchronousServerSocketChannel.accept (A attachment, CompletionHandlAsynchronousSocketChannel, ?super A> handler)

在上述方法中，attachment参数被作为CompletionHandler<V,A>的A参数传递到completed与 failed 回调方法中。下面的代码创建了一个
AsynchronousServerSocketChannel，并调用accept方法等待客户端异步连接建立完成:

listener = AsynchronousServerSocketChannel.open (asyncChannelGroup) .bind (newInetSocketAddress(port));
listener.accept (listener, new AioAcceptHandler());

AioAcceptHandler这个CompletionHandler的代码则如下:

架构解密从分布式到微服务：深入理解网络，AIO

在上述代码中，completed方法先调用
AsynchronousServerSocketChannel的 accept方法，注册下一次的异步连接请求。这个调用很重要，否则 AsynchronousServerSocketChannel就不会再接收新连接的请求了;随后调用startRead(socket)方法发起一个异步读取数据的请求。在说明这个方法之前，我们看看AsynchronousSocketChannel的异步读方法的签名:

read (ByteBuffer dst,Aattachment,CompletionHandler<Integer, ? super A> handler)

上述方法类似于之前分析的accept方法，attachment 参数被作为CompletionHandler<V.的A参数传递到completed 与 failed回调方法里，V参数则是一个整数，用于表明此次读到的字节总数。

下面是 startRead(socket)方法的逻辑，它调用了AioReadHandler来处理读到的数据，注意传递到AioReadHandler里的 Attachment是此次读到的数据——ByteBuffer，最多1024个字节;

架构解密从分布式到微服务：深入理解网络，AIO

AioReadHandler负责处理异步读响应事件，下面是其Complete方法的源码:

架构解密从分布式到微服务：深入理解网络，AIO

如上所示的代码的总体逻辑类似于accept 的处理逻辑，它针对每个客户端Socket 都使用了一个 ByteBuffer 作为 Session 级别的变量，用来保存客户端发送的数据，并且通过 Attachment变量传递到CompletionHandler的下一次读取事件上。

AIO异步写的操作类似于异步读的处理，这里不做分析。从 AIO 的代码来看，我们发现AIO也有类似于NIO 的一面，即如果还有I/O事件要操作，则仍然需要把它们“注册”到系统里。不同的是，在AIO框架下，客户端收到反馈事件时，数据已经准备好了，应用程序可以直接处理，在NIO框架下则还需要应用调用底层的读写API完成具体的IO操作。

AIO框架不仅仅止步于此，我们知道，在 JDK的NIO模型下，多路复用的Reactor模型及多线程的Reactor模型都不是官方JDK提供的，这也大大增加了应用编程的复杂度。AIO框架则将复杂的多线程处理机制融入JDK的AIO框架中，让我们可以轻松写出高级又优雅的AIO程序。

从之前的NIO经验来看，在处理很多个Socket 的IO事件时，多线程（线程池）成为必然的选择，很直观的推理就是CompletionHandler需要一个线程池来实现高性能并发回调机制，于是就有了AsynchronousChannelGroup对象，它内部包括一个线程池:

ExecutorService service = Executors.newFixedThreadPool(25);
AsynchronousChannelGroup channelGroup = AsynchronousChannelGroup.withThreadPool(service);

AsynchronousServerSocketChannel可以被绑定到某个ChannelGroup上，以便共用其线程池:

AsynchronousSocketChannel socketChannel = AsynchronousSocketChannel.open (channelGroup);

注意到ChannelGroup后面捆绑的线程池可以有多种选择，例如固定大小的线程池、弹性扩展的线程池、缓存的线程池等，于是编程的灵活性很大。此外，如果是每个CPU核心都对应一个ChannelGroup，这就接近多线程Reactor模型的设计了。

从上面的分析来看，JDK里的AIO框架设计的确很优雅，而且很妥善地解决了JDK里NIO框架没有考虑到的复杂问题。从诞生的那天开始，Java AIO 的一切看上去都很美，但是现在，“它美丽而晴朗的天空却被一朵乌云笼罩了”，这朵“乌云”就是Linux的AIO泥潭。

早在2003年，Linux kernel AIO项目就启动并且制定了设计方案。2004年，IBM觉得异步状态机的实现跟已存在的代码不协调并且太复杂，于是做出了Retry模型，但Retry模型的阻塞问题(block point)始终无法得到解决。Oracle负责OSS的部门接管了Retry模型，后来又觉得IBM的Retry模型有很多问题，发现Retry & Exit 在他们的一个产品上会有很大的性能问题，于是重起炉灶,开发了一个Syslet方案,却以失败告终。直到2016年5月,还有人发现在Linux 3.13内核里有AIO内存溢出的严重漏洞（Ubuntu Kylin 14.04 LTS版本就采用了这个内核)，Docker则要求使用AIO的宿主机所安装的版本不低于Linux 3.19(在这个版本里又有好几处AIO代码的修复)。

目前Linux 上的AIO实现主要有两种: Posix AIO与Kernel Native AIO，前者是以用户态实现的，而后者是以内核态实现的，所以Kernel Native AIO 的性能及前景要好于它的前辈PosixAIO。比较知名的软件如Nginx、MySQL、InnoDB等的高版本都支持Kernel Native AIO，但基本上都只将文件传输到Socket 中，即 AIO Files 的特性。Netty后来也实现了AIO,但又取消了，这个做法与Mycat的尝试过程殊途同归。其原因其实很简单，Linux 下 AIO的实现充斥着各种Bug，并且AIO Socket还不是真正的异步IO机制，性能的改进并不明显和可靠;而另外一种值得重视的观点是:AIO是为了未来的高带宽大数据传输而准备的技术，还不适应当前的硬件和软件环境。