操作系统的IO控制
在整个IO控制方式的发展过程中，始终贯穿着这样一条宗旨：即尽量减少主机对IO控制的干预，把主机从繁杂的IO控制事务中解脱出来，以便更多地去完成数据处理任务。为了缓和高速CPU和IO设备低速间的矛盾，现代操作系统使用通道技术，SPOOLING技术，以及缓冲技术可以做到IO操作由特殊的IO处理器（通道）负责执行，只是在IO开始和结束时，调用CPU中断处理，从而使CPU资源不被IO占用，充分发挥了CPU使用效率。
所以下文要讨论的BIO和NIO，从操作系统对设备管理的角度来说，其CPU使用率都是相同的，因为相同操作系统对设备管理和IO控制是相同的。 只是NIO使用的线程少，所以占用的内存少，减轻了系统对上下文切换的开销。
参考：
什么是NIO
In computer science, asynchronous I/O, or non-blocking I/O is a form of input/output processing that permits
other processing to continue before thetransmission
has finished.
Input and output (I/O) operations on a computer can be extremely slow compared to the processing of data. An I/O device can incorporate mechanical devices that must physically move, such as a hard drive seeking a track to read or write; this is often orders
of magnitude slower than the switching of electric current. For example, during a disk operation that takes ten milliseconds to perform, a processor that is clocked at one gigahertz
could have performed ten million instruction-processing cycles.
参考：
为什么要NIO
为每个客户端分配一个线程进行IO操作的弊端
这种IO模型已经在了几十年了，这种策略下，read和write调用都是堵塞的。它最大的问题就是每个线程都要占用一个完整的栈帧，假设栈帧的空间为2M，那么1G的内存最多服务512个线程，显然和10K有不小差距。当然，由于硬件资源越来越便宜，线程的内存开销可能不会成为瓶颈。但多线程带来的进程切换的开销却有可能长期存在。
每个客户端一个线程
用一个线程服务所有客户端，后端采用NIO，此技术类似于通信的多路复用（Multiplexing） http://en.wikipedia.org/wiki/Multiplexing
所以NIO的主要优势是，其运用内核的IO线程，从而能够以较小的内存占用和较高的CPU使用效率支持大并发访问。此处需要注意的是并不是所有的操作系统就原生支持这种IO策略，例如*nix (Linux, Unix) 就不支持，所以其异步IO（AIO：Asynchronous IO) 其实是通过采用线程池与阻塞IO模拟异步IO，相反，在windows平台下的IOCP，它在某种程度上提供了理想的异步IO：调用异步方法，等待IO完成之后的通知，执行回调，用户无须考虑轮询。其背后原理依然是线程池，不同之处在于这些线程池由系统内核接受管理，所以占用内存小，上下文切换的代价也低。
异步IO带来的性能提升
就像前面关于NIO定义描述的，IO操作占据了程序运行中绝大部分时间，以数据访问所需要的开销为例（p48 NodeJS)，访问CPU一级缓存需要3个CPU时钟周期，访问内存需要250个，访问硬盘需要41000000个，而访问网络则需要240000000个时钟周期。
所以异步IO能够带来明显的性能提升，例如一个业务需要执行如下操作
//消费时间为M
getData ('from db')
//消费时间为N
doOperate('from remote API')
如果是同步阻塞IO，其所需时间为M+N， 如果是异步IO，其所需时间为Max(M, N)，可见其性能提升是很明显的。
异步IO带来的吞吐量提升
大家都知道建立TCP connection是比较耗时的，如果采用阻塞式的方式，势必会影响服务器的TPS，在我的下一遍关于BIO和NIO的性能分析中，有详细的测试报告，测试结果大概是BIO Accept一个TCP connection的时间大概是NIO的十倍。
我的观点
虽然最近Node和NIO很火，也不就意味着像Apache那种传统的Thread Per Request就到了世界末日了，至少eBay这么大流量的网站，并没有发现Apache Server是性能的瓶颈，瓶颈往往是在数据库上。特别是在Linux系统中，用线程池模拟异步IO，而系统内核又没有原生支持的情况下，我并没有发现其相比较于Apache有什么本质的提升， OK，Node的支持者，也许马上会反驳道，你刚刚不是说数据库是性能瓶颈吗，异步IO可以用异步的方式去访问数据库啊（上面的例子），可以将M+N的时间降低为Max（M,N），这不是性能提升么
事实果真是这样吗？不尽然，因为前后两次操作往往并不是独立的，而是有依赖关系的，也就是说doOperate必须等待getData的结果才能去做，在这种情况下，业务完成时间还是需要M+N。 不过对于网络服务器吞吐量提升和对于大并发的支持，这倒是不争的事实
NIO的缺点是编程过于复杂，如果处理不当，不但不能提高效率，反而会浪费系统资源，综合其优缺点，我个人觉得除非大并发真的变成系统瓶颈，否则最好谨慎使用NIO这把双刃剑
参考：
IO vs NIO: http://tutorials.jenkov.com/java-nio/nio-vs-io.html
IO vs NIO: http://tutorials.jenkov.com/java-nio/nio-vs-io.html
同步和异步IO，阻塞和非阻塞IO：http://www.360doc.com/content/12/0604/15/9579107_215831239.shtml
版权声明：本文为博主原创文章，未经博主允许不得转载。