请谈谈NIO scoket适用的与不适用的场景

1 0

请谈谈NIO scoket适用的与不适用的场景10

我个人的理解，由于“NIO socket”的实现主体上一般为一个线性的处理过程。
所以只适合做 “请求 —— 响应 ”式的网络连接。
也就是说客户端必须向服务器发送一个请求，服务器才能响应给客户端数据。这种场景比较典型就是web服务器。

但对于由服务器主动发起的信息的服务则无从下手，比如说一个在线游戏服务器。服务器端常常需要向所有在线用户发送同步数据信息。类似此种服务只能由传统的 “多线程IO socket” 来实现。

不知道我这种理解是否正确，是否因为知识的有限对NIO有些误解，望朋友帮我解惑。谢谢。
问题补充：
类似一楼朋友的文章我已经看过很多。所以才会有我的疑问。

这么说吧，假如是一个聊天室。A B C 三个玩家分别连入。

A发言。那么我们只能在服务器端得A事件，并返回给A。B C如何才能再次注册一个写事件。并得到A的发言。
如果A对B发送密语。服务如何开启B的写事件，并发送A的话给B。
服务器如果每个小时为用户报时一次，现在是几点整。又该如何注册所有人的写事件，并发送信息。

也就是说类似这种server push的事情在nio中竟然无法实现。

设计模式

2009年3月17日 09:33

maoxiaolu2000
17
0 0 1

2个答案按时间排序按投票排序

1 0

NIO非堵塞应用通常适用用在I/O读写等方面，系统运行的性能瓶颈通常在I/O读写，包括对端口和文件的操作上，过去，在打开一个I/O通道后，read()将一直等待在端口一边读取字节内容，如果没有内容进来，read()也是傻傻的等，这会影响我们程序继续做其他事情，那么改进做法就是开设线程，让线程去等待，但是这样做也是相当耗费资源的。

Java NIO非堵塞技术实际是采取Reactor模式，或者说是Observer模式为我们监察I/O端口，如果有内容进来，会自动通知我们，这样，我们就不必开启多个线程死等，从外界看，实现了流畅的I/O读写，不堵塞了。

NIO 有一个主要的类Selector,这个类似一个观察者，只要我们把需要探知的socketchannel告诉Selector,我们接着做别的事情，当有事件发生时，他会通知我们，传回一组SelectionKey,我们读取这些Key,就会获得我们刚刚注册过的socketchannel,然后，我们从这个Channel中读取数据，放心，包准能够读到，接着我们可以处理这些数据。

Selector内部原理实际是在做一个对所注册的channel的轮询访问，不断的轮询(目前就这一个算法)，一旦轮询到一个channel有所注册的事情发生，比如数据来了，他就会站起来报告，交出一把钥匙，让我们通过这把钥匙来读取这个channel的内容。

在传统的网络编程中，我们通常使用一个专用线程（Thread）来处理一个Socket连接，通过使用NIO，一个或者很少几个Socket线程就可以处理成千上万个活动的Socket连接。

NIO可以提高性能。每个客户端连接之后，会有一个独立的SocketChannel与它通信，这个 SocketChannel会在用户的整个生存周期中存在。用户假如断开连接，服务器会得到-1，并且会抛出Connection reset异常，通过捕捉这两个特征，可以在用户意外断开连接后清理相关的资源。由于NIO是异步通信的，所以没有复杂的线程治理。

2009年3月17日 09:52