Java NIO实例诠释

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

 

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

 

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

 

suhuanzheng7784877 写道

异步 I/O 是一种 没有阻塞地读写数据的方法。通常，在代码进行 read() 调用时，代码会阻塞直至有可供读取的数据。同样， write() 调用将会阻塞直至数据能够写入。异步 I/O 调用不会阻塞。相反，您将注册对特定 I/O 事件的兴趣 ― 可读的数据的到达、新的套接字连接，等等，而在发生这样的事件时，系统将会告诉您。异步 I/O 的一个优势在于，它允许您同时根据大量的输入和输出执行 I/O。同步程序常常要求助于轮询，或者创建许许多多的线程以处理大量的连接。使用异步 I/O，您可以监听任何数量的通道上的事件，不用轮询，也不用额外的线程。还是举上公共厕所例子，虽然这个例子有点臭臭的。您现在有“便便”的需求了，不用那么麻烦，看看公共厕所是否有人占领，也不用给您另起个新坑位，您就拿一根我们服务端定制的容器和一个很粗管子，这个坐便器的大小因您那个地方的尺寸而定，坐便器往您的那个地方一放，再将坐便器和管子一连接，OK，您就敞开了“爽”吧。不用担心，这个管子自然会连接到相应的肥料厂家，将您的排泄物有效回收加以利用的。您完了事，擦擦屁股，关上管子该干嘛还干嘛就行了。另一个人也有这个需求，没问题，每个要我们提供服务的人都用这根管子，和自己的坐便器就行了，管子很粗，谁来连这个管子都行，有多少都行啊。

 

我认为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阻塞了，这个线程让给不阻塞的用）。从而提高效率

 

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