利用NIO和线程池极大提升网管通讯模块的消息吞吐量

传统模式：



NIO + 线程池模式：


优势：
1、 减少了接收的线程数。
2、 利用线程池技术控制了处理线程的数量。
3、 从测试数据来看，消息的吞吐量是极大的提升，从原来的1000条/秒提升到现在的10W条/秒。

注意点：
1、 线程池技术时，要自己写许多代码来控制并发安全。
2、 NIO有一些BUG，列举如下：
          1、 socketchannel.close()有时候关不掉socket，需要多次关闭
          2、 selector在注销和注册监听时，有时候不能立刻反映到程序中，需要自己在程序中适时的wakeup一下。


应裴小星的要求，把我以前写的一个用nio收发消息的demo传上来（见src.zip）：入口程序：com.talent.NioClient（直接运行这个类就可以了）

评论

12 楼 cwqcwqmax9 2015-02-07  

楼主    demo呢

11 楼 jjruanlili 2014-08-27  

亲，说好的demo呢……

10 楼 裴小星 2011-03-19  

tywo45 写道

to小星：
1、socketchannel.close()关不掉，用压力测试可以测出来，一般很难发现。
2、千万别用Selector.select()，而应该用Selector.select(timeout)，否则注册的事件有时体现不出来

谢谢。

9 楼 tywo45 2011-03-19  

to小星：
1、socketchannel.close()关不掉，用压力测试可以测出来，一般很难发现。
2、千万别用Selector.select()，而应该用Selector.select(timeout)，否则注册的事件有时体现不出来

8 楼 裴小星 2011-03-17  

感觉不太一样，wakeup只是跳出select吧。
现在并没有阻塞在select上，wakeup能不能解决问题？
我再试试看吧。谢谢。

7 楼 tywo45 2011-03-17  

裴小星 写道

还遇到过一个问题：
已经把ket的interest置为0了，结果仍然被select到几次。

这不就是我说的“2、 selector在注销和注册监听时，有时候不能立刻反映到程序中，需要自己在程序中适时的wakeup一下。
”吗？

6 楼 裴小星 2011-03-16  

还遇到过一个问题：
已经把ket的interest置为0了，结果仍然被select到几次。

5 楼 裴小星 2011-03-15  

谢谢博主的例子。写得很好。
最近有点忙，刚看到，抱歉了。


socketchannel.close()有时候关不掉socket，需要多次关闭
什么情况下会发生呢？好像还没遇到过。

selector在注销和注册监听时，有时候不能立刻反映到程序中，需要自己在程序中适时的wakeup一下

我猜测是这样的：
因为Selector.select()本身是阻塞的，可能那个key已经被检查过了，
wakup就会跳出select()，因为while(true){}循环的存在，
实际上就会重新执行select()，那个key的状态就被检查到了。
用selectNow()的话就是非阻塞的，但即使检索结果为0也会执行循环，实际上开销可能更大。

4 楼 tywo45 2011-02-09  

east_java 写道

你是如何测试的啊？

每收到一条消息AtomicLong++一下，然后log.info出来，日志是有时间信息的，取时间差，再相除，不就得出来了？

3 楼 tywo45 2011-02-09  

裴小星 写道

能不能结合实际例子谈谈？比如用jdk里的nio和concurrent包实现一个简单的socket server。

已上传原来的demo，不过此demo是没用线程池技术的，当初只是为了测试NIO的可行性

2 楼 east_java 2011-02-09  

你是如何测试的啊？

1 楼 裴小星 2011-02-09  

能不能结合实际例子谈谈？比如用jdk里的nio和concurrent包实现一个简单的socket server。