nio和io的服务器端比较

 1.) io:

传统的io,JDK1.4以前:
即当程序执行输入/输出操作后,在这些操作返回之前会一直阻塞该线程,
所以服务器必须为每个客户端都提供一条独立线程进行处理(否则无法继续运行),
当服务器需要同时处理大量客户端时,这种做法会导致性能下降.(比如在单核状态下,CPU同一时刻处理一个线程).

做为服务器端,其处理结构如下图所示:

 

假设如 [jdk1.4]socket举例--基于nio 中的Server程序,有4个client同时到达,Server端accept其中1个连接,建立一个线程(A为Server主线程,B为新建的线程).

A线程继续accept,并同上处理其他3个线程..这时,就新建了4个线程

B线程读取client输入(阻塞),假设这里等待了10秒,才接收到流,并处理.那么,这个线程B至少存在10秒..

我们假设程序的处理时间,接收流的时间以及创建线程的时间可以忽略不计,那么,A线程处理完全部4个请求的时间为10秒..

---

2.) nio

说到nio,就不得不提其的设计模式,反应器模式,其核心思想:

1).将事件多路分用
2).将事件分派到各自相应的事件处理程序

Selector 类是 Channel 的多路复用器。 Selector 类将传入客户机请求多路分用并将它们分派到各自的请求处理程序。

做为服务器端,其处理结构如下图所示:

 

假设如上文传统socket举例--基于io 中的Server程序,有4个client同时到达,Server端select其中1个连接,这里它并没有创建新的线程,而是

判断,当client有读/写操作时,在对应建立写/读操作..

好比4个人去食堂吃饭,饭菜好比流:

io做法是:4个人不停地问,我的菜好了没有(CPU的时间片)..

nio的做法是:委托另外一个人看着,当自己的好了通知自己就行(不通知自己的时候自己不做动作)..

长连接时和普通io差不多..

这样看来,nio在socket并发量大,且短连接的时候,有优势..

网上还有种说法,说nio在windows下的实现是iocp ,在linux下的实现是epoll..如果是这样,那么从底层实现来讲,nio的效率要好的多,不过我没有查阅native的c的源码..不知道这种说法是否属实,有兴趣的童鞋可以查阅下,然后给我留个言,这里先谢过了..