深刻理解Java NIO

初识NIO：

    在 JDK 1. 4 中 新 加入 了 NIO( New Input/ Output) 类, 引入了一种基于通道和缓冲区的 I/O 方式，它可使用 Native 函数库直接分配堆外内存，而后经过一个存储在 Java 堆的 DirectByteBuffer 对象做为这块内存的引用进行操做，避免了在 Java 堆和 Native 堆中来回复制数据。

    NIO 是一种同步非阻塞的 IO 模型。同步是指线程不断轮询 IO 事件是否就绪，非阻塞是指线程在等待 IO 的时候，能够同时作其余任务。同步的核心就是 Selector，Selector 代替了线程自己轮询 IO 事件，避免了阻塞同时减小了没必要要的线程消耗；非阻塞的核心就是通道和缓冲区，当 IO 事件就绪时，能够经过写道缓冲区，保证 IO 的成功，而无需线程阻塞式地等待。

Buffer：

    为何说NIO是基于缓冲区的IO方式呢？由于，当一个连接创建完成后，IO的数据未必会立刻到达，为了当数据到达时可以正确完成IO操做，在BIO（阻塞IO）中，等待IO的线程必须被阻塞，以全天候地执行IO操做。为了解决这种IO方式低效的问题，引入了缓冲区的概念，当数据到达时，能够预先被写入缓冲区，再由缓冲区交给线程，所以线程无需阻塞地等待IO。

通道：

    当执行：SocketChannel.write(Buffer)，便将一个 buffer 写到了一个通道中。若是说缓冲区还好理解，通道相对来讲就更加抽象。网上博客不免有写不严谨的地方，容易使初学者感到难以理解。

    引用 Java NIO 中权威的说法：通道是 I/O 传输发生时经过的入口，而缓冲区是这些数 据传输的来源或目标。对于离开缓冲区的传输，您想传递出去的数据被置于一个缓冲区，被传送到通道。对于传回缓冲区的传输，一个通道将数据放置在您所提供的缓冲区中。

    例如 有一个服务器通道 ServerSocketChannel serverChannel，一个客户端通道 SocketChannel clientChannel；服务器缓冲区：serverBuffer，客户端缓冲区：clientBuffer。

    当服务器想向客户端发送数据时，须要调用：clientChannel.write(serverBuffer)。当客户端要读时，调用 clientChannel.read(clientBuffer)

    当客户端想向服务器发送数据时，须要调用：serverChannel.write(clientBuffer)。当服务器要读时，调用 serverChannel.read(serverBuffer)

    这样，通道和缓冲区的关系彷佛更好理解了。在实践中，未必会出现这种双向链接的蠢事（然而这确实存在的，后面的内容还会涉及），可是能够理解为在NIO中：若是想将Data发到目标端，则须要将存储该Data的Buffer，写入到目标端的Channel中，而后再从Channel中读取数据到目标端的Buffer中。

Selector：

    通道和缓冲区的机制，使得线程无需阻塞地等待IO事件的就绪，可是老是要有人来监管这些IO事件。这个工做就交给了selector来完成，这就是所谓的同步。

    Selector容许单线程处理多个 Channel。若是你的应用打开了多个链接（通道），但每一个链接的流量都很低，使用Selector就会很方便。

    要使用Selector，得向Selector注册Channel，而后调用它的select()方法。这个方法会一直阻塞到某个注册的通道有事件就绪，这就是所说的轮询。一旦这个方法返回，线程就能够处理这些事件。

    Selector中注册的感兴趣事件有：

• OP_ACCEPT

• OP_CONNECT 

• OP_READ 

• OP_WRITE

优化：

    一种优化方式是：将Selector进一步分解为Reactor，将不一样的感兴趣事件分开，每个Reactor只负责一种感兴趣的事件。这样作的好处是：一、分离阻塞级别，减小了轮询的时间；二、线程无需遍历set以找到本身感兴趣的事件，由于获得的set中仅包含本身感兴趣的事件。

NIO和epoll：

    epoll是Linux内核的IO模型。我想必定有人想问，AIO听起来比NIO更加高大上，为何不使用AIO？AIO其实也有应用，可是有一个问题就是，Linux是不支持AIO的，所以基于AIO的程序运行在Linux上的效率相比NIO反而更低。而Linux是最主要的服务器OS，所以相比AIO，目前NIO的应用更加普遍。

    说到这里，可能你已经明白了，epoll必定和NIO有着很深的因缘。没错，若是仔细研究epoll的技术内幕，你会发现它确实和NIO很是类似，都是基于“通道”和缓冲区的，也有selector，只是在epoll中，通道其实是操做系统的“管道”。和NIO不一样的是，NIO中，解放了线程，可是须要由selector阻塞式地轮询IO事件的就绪；而epoll中，IO事件就绪后，会自动发送消息，通知selector：“我已经就绪了。”能够认为，Linux的epoll是一种效率更高的NIO。

NIO轶事：

    一篇有意思的博客，讲的 Java selector.open() 的时候，会建立一个本身和本身的连接（windows上是tcp，linux上是通道）

    这么作的缘由：能够从 Apache Mina 中窥探。在 Mina 中，有以下机制：

1. Mina框架会建立一个Work对象的线程。

2. Work对象的线程的run()方法会从一个队列中拿出一堆Channel，而后使用Selector.select()方法来侦听是否有数据能够读/写。

3. 最关键的是，在select的时候，若是队列有新的Channel加入，那么，Selector.select()会被唤醒，而后从新select最新的Channel集合。

4. 要唤醒select方法，只须要调用Selector的wakeup()方法。

    而一个阻塞在select上的线程有如下三种方式能够被唤醒：

1. 有数据可读/写，或出现异常。

2. 阻塞时间到，即time out。

3. 收到一个non-block的信号。可由kill或pthread_kill发出。

    首先 2 能够排除，而第三种方式，只在linux中存在。所以，Java NIO为何要建立一个本身和本身的连接：就是若是想要唤醒select，只须要朝着本身的这个loopback链接发点数据过去，因而，就能够唤醒阻塞在select上的线程了。