Java NIO实例诠释

几个月前看过一篇博文：http://suhuanzheng7784877.iteye.com/blog/1122131

写的很棒，也很重口味。。。

十一闲着没事，又想起这篇文章来（印象挺深的）。想着想着就感觉这篇文章有一处问题，写出来希望大家分析分析是我想错了，还是原文本就有些许Bug。 首先申明：比较重口味，严谨者赶紧点击右上角

我认为NIO并不是“一个用户通过一跟可插拔管道连接容器”这样的

一个用户的大便请求本就是可阻塞 的， 因为大便不像小便一样“一泻而尽”，而是“a piece / a piece”的。将一个用户的可阻塞“大便”请求连接一个管道和坐便器上是不是有些不妥啊？

在这个例子中：

     大便请求【Socket】

     管子【SocketChannel】

     坐便器【Thread】

     坐便器分配器【Selector】

     公共厕所【APP】

    我感觉该例子并没有完全体现Selecor在非阻塞I/O中的作用，此例子中的Selector只是在用户请求时【蹲下】分配了坐便器【Thread】。 事实上在用户阻塞时 【你懂的】这个坐便器【Thread】会被系统回收的，防止线程因为Socket阻塞而阻塞嘛。

我的见解就是：

    用户向公共厕所（Application）发送大便请求（Socket）， 公共厕所会将此请求交给坐便器分配器（Selector），此Selector会给此用户分配一个坐便器（Thread），并且说“你拉不拉？ 不拉我就先把这个坐便器撤了，管道留你那”。如果此用户阻塞住了的话，则马上将此坐便器回收。然后坐便器分配器（Selector）会监视用户的阻塞情况（用户仍然处于可大便状态，只是阻塞了，排泄物正在从大肠向**发送）， 直到用户不阻塞时候（有东西可拉时）， 坐便器分配器便将一个空闲坐便器（Thread）挪过来，等到用户再次阻塞时，再将这个坐便器回收。以此类推，直到用户的大便请求结束。当然用户不会期望公共厕所给他的大便请求返回响应的。。。

NIO与IO的区别就是：

    IO为一个Socket请求提供一个线程，这个线程自始自终都被此Socket占用，无论是否阻塞！！！

    NIO高明之处就在于，它可以将处于阻塞状态中的Socket从线程中剥离出来（反正你Socket阻塞了，这个线程让给不阻塞的用）。从而提高效率

预先说好了啊，受不了重口味的不要看，看了的话就不要喷俺。感觉咱写的不错的顶个呗~~~~~~