回顧一下Unix的5種I/O模型
1、阻塞I/O
2、非阻塞I/O
3、I/O復(fù)用（select、poll、linux 2.6種改進(jìn)的epoll）
4、信號(hào)驅(qū)動(dòng)IO（SIGIO）
5、異步I/O（POSIX的aio_系列函數(shù)）
同步I/O和異步IO
POSIX把這兩個(gè)術(shù)語(yǔ)定義如下：
同步I/O操作導(dǎo)致請(qǐng)求進(jìn)程阻塞，直至操作完成
異步I/O操作不導(dǎo)致請(qǐng)求阻塞。
根據(jù)上述定義，前四種I/O模型都是同步I/O，第5種才是異步I/O。
select不允許多于一個(gè)的線程在同一個(gè)描述符集上等待。這使得反應(yīng)式模型不適用于高性能應(yīng)用，因?yàn)樗鼪]有有效地利用硬件的并行性。
異步I/O通常能夠提高更好的性能，windows的iocp通過(guò)內(nèi)核線程調(diào)度，也能提供很好的并發(fā)性能，但不是真正的異步。
Java nio和多路復(fù)用
java 1.4 nio提供的select，這是一種多路復(fù)用I/O（multiplexed non-blocking I/O）模型，底層是使用select或者poll。I/O復(fù)用就是，阻塞在select或者poll系統(tǒng)調(diào)用的某一個(gè)之上，而不是阻塞在真正的I/O系統(tǒng)調(diào)用之上。JDK 5.0 update 9和JDK 6.0在linux下支持使用epoll，可以提高并發(fā)idle connection的性能（
http://blogs.sun.com/alanb/entry/epoll）。
以前看到有人猜測(cè)Windows下nio使用了IOCP，那應(yīng)該是錯(cuò)的，畢竟IOCP不是多路復(fù)用I/O模型。從JavaOne 2006的幻燈片來(lái)看，aio才會(huì)使用IOCP來(lái)實(shí)現(xiàn)的。
Java aio和JSR 203
2003年，就有了JSR 203（
http://jcp.org/en/jsr/detail?id=203），但是一直沒有實(shí)現(xiàn)。
終于，JSR 203的spec lead說(shuō)，將會(huì)在Java SE 7.0中完成JSR 203，Java SE 6.0已經(jīng)是RC，很快正式版就會(huì)發(fā)布，然后就是Java SE 7.0，估計(jì)我們不需要等太久了。
http://blogs.sun.com/alanb/entry/what_is_happening_with_jsrasynchronous I/O對(duì)于Java的影響，將不會(huì)低于當(dāng)年JDK 1.4 nio引入multiplexed non-blocking I/O的影響，很多的Java應(yīng)用都會(huì)重寫。如同Linux 2.6支持AIO，DB2、Oracle數(shù)據(jù)庫(kù)都會(huì)發(fā)布新版本，說(shuō)支持使用AIO，性能提高多少多少云云（主要是AIO的文件操作部分）。
對(duì)asynchronous I/O的支持，Java程序就能夠支撐大并發(fā)網(wǎng)絡(luò)應(yīng)用了，在IO模型方面，對(duì)于C/C++等語(yǔ)言不再存在“C/C++能做，但是Java不能做的事情”。
這個(gè)是Java One 2006上的幻燈片。
http://blogs.sun.com/roller/resources/alanb/bof0895.pdf提到了：
需要新的channel types支持異步I/O模型
使用Native機(jī)制，例如Windows IO Completion ports。