前言
从JDK 7版本开始，Java新加入的文件和网络io特性称为nio2(new io 2, 因为jdk1.4中已经有过一个NIO了)，包含了众多性能和功能上的改进，其中最重要的部分，就是对异步io的支持，称为Java AIO(asynchronous IO)。
因为AIO的实施需充分调用OS参与，IO需要操作系统支持、并发也同样需要操作系统的支持，所以性能方面不同操作系统差异会比较明显。
BIO,NIO,AIO 三种IO处理模型
BIO:也即是传统的同步阻塞IO,服务器实现模式为一个连接一个线程，即客户端有连接请求时服务器端就需要启动一个线程进行处理，即使该连接不做任何事，或者使用频率很少都会造成服务器的线程开销，当线程数达到操作系统的限制，可能会延迟或者拒绝新的连接请求。其read方法自己阻塞自己等待有数据可读为止，所以说是同步阻塞。
NIO:JDK1.4提出的同步非阻塞IO，服务器实现模式为一个请求一个线程，客户端发送的连接请求都会注册到多路复用器上，多路复用器轮询到连接有I/O请求时才启动一个线程进行处理。NIO基于Reactor模式，其select底层调用操作系统的select/poll模型(Linux2.6采用epoll)不断的轮询，直到有数据可操作为止，这其实就是一种同步IO，当发现有数据操作之后进行的IO操作将不会被阻塞，即是非阻塞IO。另外在这种模型下，从通知应用程序有数据可读，到read调用把外部数据加载至内核空间，然后再从内核空间拷贝至用户空间需要一定时间间隔，这也会降低整体数据吞吐量。
AIO:JDK1.7提出的异步非阻塞IO，服务器实现模式为一个有效请求一个线程，客户端的I/O请求都是由OS先完成了再通知服务器应用去启动线程进行处理。与NIO不同，AIO基于Proactor模式当进行读写操作时，只须直接调用API的read或write方法即可。这两种方法均为异步的，对于读操作而言，当有流可读取时，操作系统会将可读的流传入read方法的缓冲区，并通知应用程序；对于写操作而言，当操作系统将write方法传递的流写入完毕时，操作系统主动通知应用程序。在这种情况下，操作系统会负责将可读取的数据从内核空间转移至用户空间之后，才主动通知应用程序，应用程序不但不需要不停的轮询，并且数据的读取过程也更加快捷。
BIO、NIO、AIO适用场景:
- BIO方式适用于连接数目比较小且固定的架构，这种方式对服务器资源要求比较高，并发局限于应用中，JDK1.4以前的唯一选择，但程序直观简单易理解。
- NIO方式适用于连接数目多且连接比较短（轻操作）的架构，比如聊天服务器，并发局限于应用中，编程比较复杂，JDK1.4开始支持。
- AIO方式使用于连接数目多且连接比较长（重操作）的架构，比如相册服务器，充分调用OS参与并发操作，编程比较复杂，JDK7开始支持
AIO实现原理
我们知道在Linux 2.6以后，java NIO的实现，Linux是通过epoll来实现的，Windows是通过较低效的select/poll实现的，这点可以通过jdk的源代码发现。而对于AIO，在windows上是通过IOCP实现的，在Linux上还是通过epoll来实现的。
AIO新增的API主要有如下：
- AsynchronousSocketChannel
- AsynchronousServerSocketChannel
- AsynchronousFileChannel
- AsynchronousDatagramChannel
- CompletionHandler
异步channel API提供了两种方式监控/控制异步操作(connect,accept, read，write等)。第一种方式是返回java.util.concurrent.Future对象， 检查Future的状态可以得到操作是否完成还是失败，还是进行中， future.get阻塞当前进程。
第二种方式为操作提供一个回调参数java.nio.channels.CompletionHandler，这个回调类包含completed,failed两个方法。
channel的每个I/O操作都为这两种方式提供了相应的方法， 你可以根据自己的需要选择合适的方式编程。
参考文章：http://www.ibm.com/developerworks/cn/linux/l-async/