[项目总结 之四]刀尖上跳舞-NIO篇

项目中引入NIO纯属万不得已,因为这个问题在除NIO外似乎没有太好的解决方式了。


O(n)的问题
    我们的网关,在服务器看来其实就是一个一个客户端,服务器根本不知道网关的存在。而客户端与服务器连接的模型,是TCP的长连接,即客户端连接上服务器以 后,这个连接在客户端断线以前都是存在的。因此,网关也必须帮客户端保持这个连接,结果是,如果使用传统阻塞IO的方式的话,必须有至少新建一个线程用于 维护读的操作。那么,试想一下,如果有1000个用户登录上来的话,就必须新建1000个线程用于守护,这样的结果是不能忍受的。而且还会引出更大的问 题。


OutOfMemory
建立在上面的传统IO基础上,我们进行了一些测试,结果是不能令人满意的,在1000多用户的时候,出现了内存溢出:java.lang.OutOfMemoryError: unable to create new native thread.这里需要说一下,内存溢出不单只是在JVM耗尽了分配给他的内存时出现,换个角度想,线程是属于系统级的东西,所以,如果操作系统没有足够的内存来产生这个线程,也同样会造成内存溢出。上面这个内存溢出就属于系统的内存溢出。
   之前查资料的情况是,Windows和Linux一个进程内的线程数是有限制的,具体跟系统不用有所不同。我们在Windows下测试的情况是在5000~7000左右。同时,这么大的线程数,应用单调度的效率都会大大降低。这里还想说一个JVM的配置,-Xss。这个参数是配置JVM分配给一个线程的栈大小的,JDK5.0时,一个线程默认大小应该为1M,所以根据应用情况,把这个值改小的话,同样的内存将能生成更多的线程,同时减少JVM内存溢出的可能性。


O(1)的解决
上面的问题中,最大的问题就是需要一个进程维护被阻塞的“读”操作(PS:写操作是没有关系),因此只要能把“读”部分的阻赛线程化解掉即可。NIO用在这里,再合适不过了。通过NIO,这里的连接模型发生变化了。以前是:N个用户-N个线程-N个IO-N个处理逻辑(数据读取过来以后需要进行业务处理)  现在是 N个用户-k个线程(1个或多个NIO的selector)-N个IO-1个处理线程池。后者的连接部分、处理部分都要用户多少无关。线程池配置多大、使用多少个selector都可根据实际测试情况进行配置了,大大减少了线程数量。


NIO的困惑

  1. NIO是个好东东,不过要很好的驾驭还是一件很困难的事情。NIO最麻烦的地方就在传输消息的不完整性(个 人的说法),主要就是在消息量大的情况下NIO一次传输的消息可能是多次发送积累的结果,所以内容可能是多条消息,可能是某条消息的中间部分。我们的应用 因为一个用户一个Socket连接,所以消息量比较小,目前还没有发生这种情况,但是这里一直是一个隐患。解决方式也没有太好的办法,只能通过缓冲收到的消息,然后再通过关键字符或者内容长度的标准(如:HTTP中的Cotent-Length)进行内容划分
  2. 线 程数是上去了,但是连接数还受到限制。这还是一个操作系统的问题,Windows系统(XP)对TCP连接,默认情况下只能使用5000以下的端口。如果 要使用其他端口,需要修改一下注册表。其他操作系统不是很清楚,不过从查到的资料来看应该都有一些限制。Windows XP系统修改方法如下:查 找注册表项HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/Tcpip/ Parameters,在其中加入新值 MaxUserPort 类型为DWORD,此键标识最大允许的端口号,自己写一个就行,小于65535,重启电脑
  3. 连接未释放的问题。这个可以参考以前我写过的一篇:网络连接无法释放—— CLOSE_WAIT
  4. NIO方式常用于服务器端,因为服务器总会面临这种大压力的情况。但是对于我们网关,是客户端去连服务器的,NIO方式也同样适用于客户端的程序。连接方式与服务器端相同,SocketChannel连接上以后注册到相应的Selector即可。
  5. 两个小问题,费了我不少时间。ByteBuffer这个东西,不管读还是写,完了记着调用一下flip()方法,不然不是没读出来就是没写进去。只是这个方法可读性也太次了,老忘,ft。还有一个,使用NIO方式进行网络连接的时候(客户端连接服务器),除了调用channel的connect外,等连接上了(触发了Connect事件),记着还要调用一下SocketChannel的finishConnect()方法,以完成整个连接过程,否则会出现一些不知名的问题。。。


站在巨人肩上
    虽然自己写的东西目前用着还可以,但是说实话,写的太简陋了,所以指不定哪天就出现一些不知名的问题了,呵呵。所以下来又找了一些支持NIO的框架。


   --Grizzly :一个开源的NIO框架。GlassFish的HTTP服务器底层实现。同时Grizzly已经实现好了一个基于NIO的HTTP底层,所以如果是 HTTP协议的话,拿来就可以用了。个人还是比较看好这个的,毕竟Sun在支持。由于Grizzly的初衷是搭建一个基于NIO支持不用协议的框架,所以 在NIO之上它还提供了一些接口,用户自己实现这些接口,即可分割不同协议。HTTP只是其中的一种协议实现而已。
   --MINA :Apache的项目。MINA旨在提供一个高性能的网络传输框架。所以它对NIO的支持,主要在Socket一层进行封装,使得用户使用起了会比较方 便。个人用了一下,确实很简单。不过,MINA也就到此为止了,再往上就需要用户自己实现消息的分割,协议解析一些东西了。
   --QuickServer :这个东东主要是提供服务器端的支持,使用起来也是相当简单的。只是我们的应用是客户端的,所以用不上,写在这里,大家有兴趣可以研究一下。

 
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值