java NIO 学习笔记1

jdon看到的一篇帖子。现记录如下。

 

问题：

很简单 100个请求过来了，每个请求都会有三个事件 ，accept,read write ,如果只有一个主线程轮询，每遍历到一个事件都得线性的去处理他，等处理完了再处理第二个事件，如果有个write的写操作要写很多数据，那也得等这个 write写完了再处理下一个， 要改善这种情况，还得用一个新线程去处理，或是线程池任务队列之类的处理也好，这样就不至于非得等到上一个事件处理完，那这样又回到了之前的阻塞 socket多线程处理用户请求的模式了，
非阻塞，非阻塞其实就是channel的write和read不会阻塞，读不到或是写不出去方法会马上返回，但是如果你能读有能写，但是得花时间读写呢，我想这样其实和单线程处理所有请求的情况一样了吧 。

 

 

评论1：

Threaded vs Evented Servers

在服务器端，目前共有两种方法处理并发请求：
（1）Threaded线程类服务器是使用多个并行线程来处理请求，每个线程处理一个客户端请求，典型的是J2EE或JavaEE服务器。

（2）Evented事件类服务器则是循环运行一个事件，用来处理所有连接客户端信息。

线程类服务器受限于CPU和线程界限，而事件类服务器并不受限于线程方面约束，因为它只用一个线程，只是受限于CPU能力。

文章对多个情况下两种模式性能比较，当我们需要执行一个后台服务，有高延迟high-latency(无高一致性要求场合)，那么事件类服务器模式的性能要好些。

最后一个测试情况是long polling客户端，客户端发出长时间拉请求，也就是通常的AJAX发出的异步请求，事件类服务器模式要更好些。

转贴这篇文章想说明的是：jdonframework的domain events采取的是Evented事件类服务器模式，这种模式非常适合AJAX发出的轮询或高延迟的异步请求，这种模式对CPU负载低，不象传统同步多线程模式会Block堵塞住CPU。

适合事件类服务器模式是一些无需分享状态的应用，或者对状态的一致性要求比较低的应用，或者可以说对状态高一致性要求的避免使用事件类服务器模式。

 

 

评论2：

>>非阻塞，非阻塞其实就是channel的write和read不会阻塞，读不到或是写不出去方法会马上返回，但是如果你能读有能写，但是得花时间读写呢，我想这样其实和单线程处理所有请求的情况一样了吧 。

首先如果有读有写，还得花时间读写呢？这个是同步IO和异步IO的问题，异步IO可以不让应用程序关心怎么读写数据，只需要传递内存缓存区给内核就OK了，内核负责读取，但是目前JAVA的IO都是同步IO,NIO属于同步非阻塞IO。


至于非阻塞IO肯定是有好处，比如在使用同步阻塞IO的时候，因为线程是一种很昂贵的资源，如果每一个请求过来，都分配一个线程处理的话，就会因为某些任务的阻塞，而使得线程处于阻塞状态，而如果有一个线程专门负责轮训的话，这样所有真正实现读写操作的线程就不会阻塞，每次都是可读或者可写的时候，才会真正的将channel与线程关联，从而不会占用宝贵的系统资源而啥都不干，这样线程花的时间都是真正读取和写入数据的时间了，而取消了阻塞的时间，这样在系统资源一定的情况下，会更好的榨取CPU的性能。


另外JAVA7好像要支持异步IO，而异步非阻塞IO，更本不用应用关系如何读取数据，有内核来完成，但是这也需要操作系统从底层支持异步IO，不过我们可以通过Proactor来模拟异步IO的实现。

 

评论3：

NIO解决的问题
线程过多时，对系统资源的过度占用比单线程循环处理的代价更高时的一种权衡
不是NIO就比IO好，存在一个临界值
1、响应时间
2、资源点用
3、变量控制
三个指标的权衡，找到临界值，选择处理方式

 

评论4：

设想一下没有NIO之前，数千、数万个客户端来连你的服务器，你的服务器会怎么个死法。
这么简单的道理，自己多想一想。