【总结】两种 NIO 实现:Selector 与 Epoll

时间2012-11-17 08:38:42 开源中国新闻原文  http://my.oschina.net/ielts0909/blog/89849

我想用这个话题小结下最近这一阶段的各种测试和开发。其实文章的内容主要还是想总结一下 NIO Socket ,以及两种不同操作系统实现 NIO 的方式, selector 和epoll 。

问题应该从服务器端开始说起。我们都写过net包下的socket,用socket的accept方法来等待客户端的请求,请求来了则处理,没有则一直等待,然后反复循环。这样的方式,类似于重用进程,要说线程也可以,始终就在这一条路上堵着。这样没有并发可言,我们想到了可以用多线程,用线程池的方式来解决这个问题。这样一般的小问题能解决了,100个初始化的线程,解决几千个连接应该没什么问题。可是,如果我做的是传输的项目呢,这100个线程还是阻塞的,第101个线程连接的时候,如果前面的100个都还在传输,那这第101个人还是在空等,而且他连个回音都不能收到。而且这样的方式实现起来并不怎么容易,虽然线程池有Exectors这样的类帮你生成,可是遇到共享变量和协同等问题还是很头疼。一个更好的做法是,模仿FTP一样,将指令与传输分开进行,一个端口负责简短的指令,尽可能的端连接,而其他端口处理业务。这样至少服务器能返回消息了。

第三种解决方案,多数情况下,也是最快的一种被提出来了,选择器selector。用一个线程来查询一组socket,找出已经准备好读写的,然后按顺序处理socket,当然这种实现方式的前提是IO必须使用通道和缓冲区而不是流。

用java来开发NIO socket的程序,最先要理解的还是各种概念。

通道channel,在NIO socket中使用到的通道有三个,SocketChannel、ServerSocketChannel、DatagramChannel。前两种基于TCP,最后一种一种用来实现UDP的通信。ServerSocketChannel不做任何数据上的处理,只是提供通道,负责连接。SocketChannel职责和net包下的socket类似,只不过这里是以通道的形势来对接。

缓冲区Buffer,这里最常用的还是ByteBuffer,在mina中使用的IoBuffer也是基于ByteBuffer实现的。它的好处是可以自己拼装去想到的数据。当然利用通道后数据切换的速度也会更快了。

要实现非阻塞IO最重要的还是选择器:

Selector 

The Selector class manages information about a set of registered channels and their readiness states. Channels are registered with selectors, and a selector can be asked to update the readiness states of the channels currently registered with it. When doing so, the invoking thread can optionally indicate that it would prefer to be suspended until one of the registered channels is ready.

SelectableChannel 

This abstract class provides the common methods needed to implement channel selectability. It‘s the superclass of all channel classes that support readiness selection. FileChannel objects are not selectable because they don‘t extend from SelectableChannel. All the socket channel classes are selectable, as well as the channels obtained from a Pipe object. SelectableChannel objects can be registered with Selector objects, along with an indication of which operations on that channel are of interest for that selector. A channel can be registered with multiple selectors, but only once per selector.

SelectionKey

A SelectionKey encapsulates the registration relationship between a specific channel and a specific selector. A SelectionKey object is returned from SelectableChannel.register( ) and serves as a token representing the registration. SelectionKey objects contain two bit sets (encoded as integers) indicating which channel operations the registrant has an interest in and which operations the channel is ready to perform.

Selector 管理被注册的通道的集合的信息和其就绪状态,同时也更新通道的就绪状态。并且一个通道可以被注册到多个选择器上,而对于同一个选择器则只能被注册一次。

  1. import java.io.IOException;
  2. import java.net.InetSocketAddress;
  3. import java.net.ServerSocket;
  4. import java.nio.ByteBuffer;
  5. import java.nio.channels.SelectableChannel;
  6. import java.nio.channels.SelectionKey;
  7. import java.nio.channels.Selector;
  8. import java.nio.channels.ServerSocketChannel;
  9. import java.nio.channels.SocketChannel;
  10. import java.util.Iterator;
  11.  
  12. public class SelectSockets {
  13. private static final int PORT = 8082;
  14.  
  15. private ByteBuffer buffer = ByteBuffer.allocate(1024);
  16.  
  17. public static void main(String[] args) throws IOException {
  18.  
  19. SelectSockets ss = new SelectSockets();
  20.  
  21. ss.go();
  22. }
  23.  
  24. public void go() throws IOException {
  25.  
  26. System.out.println("listening on port:" + PORT);
  27.  
  28. ServerSocketChannel ssc = ServerSocketChannel.open();
  29.  
  30. ServerSocket ss = ssc.socket();
  31.  
  32. Selector selector = Selector.open();
  33.  
  34. ss.bind(new InetSocketAddress(PORT));
  35.  
  36. ssc.configureBlocking(false);
  37.  
  38. ssc.register(selector, SelectionKey.OP_ACCEPT);
  39.  
  40. while (true) {
  41. int n = selector.select();
  42.  
  43. if (n == 0) {
  44. continue;
  45. }
  46.  
  47. Iterator<SelectionKey> iter = selector.selectedKeys().iterator();
  48.  
  49. while (iter.hasNext()) {
  50. SelectionKey key = iter.next();
  51. if (key.isAcceptable()) {
  52. ServerSocketChannel server = (ServerSocketChannel) key
  53. .channel();
  54. SocketChannel client = server.accept();
  55. register(selector, client, SelectionKey.OP_READ);
  56. System.out.println("Accept client:" + client);
  57. acceptClient(client);
  58. }
  59. if (key.isReadable()) {
  60. readData(key);
  61. }
  62. iter.remove();
  63. }
  64. }
  65. }
  66.  
  67. protected void register(Selector selector, SelectableChannel channel,
  68. int ops) throws IOException {
  69. if (channel == null) {
  70. return;
  71. }
  72. channel.configureBlocking(false);
  73.  
  74. channel.register(selector, ops);
  75.  
  76. }
  77.  
  78. protected void readData(SelectionKey key) throws IOException {
  79. SocketChannel socketChannel = (SocketChannel) key.channel();
  80. int count;
  81. while ((count = socketChannel.read(buffer)) > 0) {
  82. buffer.flip();
  83.  
  84. while (buffer.hasRemaining()) {
  85. socketChannel.write(buffer);
  86. }
  87.  
  88. buffer.clear();
  89.  
  90. if (count < 0) {
  91. socketChannel.close();
  92. }
  93. }
  94. }
  95.  
  96. private void acceptClient(SocketChannel channel) throws IOException {
  97. buffer.clear();
  98. buffer.put("you have already connected server!".getBytes());
  99. buffer.flip();
  100.  
  101. channel.write(buffer);
  102. }
  103.  
  104. }

上面的代码就是一般的 NIO 服务器端实现的过程。 当然对于一个企业级的应用这样的代码肯定是太单薄了,仅仅就 selector 而言, 我们是不是能共通过用多线程的方式来增强他的处理能力?是不是只有一个线程在跑 selector ,让这一个线程处理那么多的连接有点儿过意不去。答案并不是和你想的一样 :

For the first scenario, in which you want to bring more threads into play to service channels, resist the urge to use multiple selectors . Performing readiness selection on large numbers of channels is not expensive; most of the work is done by the underlying operating system . Maintaining multiple selectors and randomly assigning channels to one of them is not a satisfactory solution to this problem. It simply makes smaller versions of the same scenario.

如果您想要将更多的线程来为通道提供服务,请抵抗住使用多个选择器的欲望。在大量通道上执行就绪选择并不会有很大的开销,大多数工作是由底层操作系统完成的。管理多个选择器并随机地将通道分派给它们当中的一个并不是这个问题的合理的解决方案。这只会形成这个场景的一个更小的版本。

一个更好的方案就是,让一个线程处理selector,让其他线程去处理就绪通道的业务。

模式就和上图上描述的一样,但是我的疑问来了,这样和线程池下的服务端连接好像看起来并没有多少大的优势。同样还是要启那么多的线程去处理这些业务。这也是我最近一直想从 mina 源码中找到的答案,可是还是没有发现我想要的,它也是通过 IoSession 用原型模型的方式来实现并发的。不过我估计 Mina 应该是有异步的实现,这样也会对性能上有影响。具体还有待研究。

最后要说的就是客户端了,最近其实也的客户端比较多,版本一个接一个,写了不下七八个,各种方式,各种测试,其实有几点心得可以分享:

l  如果是做大文件的传输,切分的性价比其实比连续传的性价比高不了多少,虽然像迅雷这样可以分好多块传输,但那毕竟是 P2P 的结构,文件本来就松散的。考虑到切分再校验再重组,这样还不如切大块,然后顺序传。

l  尽量将指令和传输分开,指令可以加密,然后更具协议,返回端口和地址让服务器端做到分布式的处理。

l  还有就是客户端是否要用非阻塞模式,客户端如果不是做出 P2P 模式的,而且能用多线程解决问题的,就没必要用非阻塞的模式,因为非阻塞模式的发送和接收的时机很难控制,特别是用原生的 NIO 写的 socket 。

l  在做两端通信的时候,特别是不同语言写的程序和不同操作系统下,要注意字节序(高有效和低有效)和进制的问题。

l  Mina 这样的框架很好,如果再配上 protobuf 这样的多平台序列化工具,可以很好的实现自定义协议的通信。自己订协议的好处就是安全,而且能做应答机制。

Epoll是Linux下多路复用IO接口select/poll的增强版本,它能显著提高程序在大量并发连接中只有少量活跃的情况下的系统CPU利用率,因为它会复用文件描述符集合来传递结果而不用迫使开发者每次等待事件之前都必须重新准备要被侦听的文件描述符集合,另一点原因就是获取事件的时候,它无须遍历整个被侦听的描述符集,只要遍历那些被内核IO事件异步唤醒而加入Ready队列的描述符集合就行了。epoll除了提供select/poll那种IO事件的电平触发(Level Triggered)外,还提供了边沿触发(Edge Triggered),这就使得用户空间程序有可能缓存IO状态,减少epoll_wait/epoll_pwait的调用,提高应用程序效率。

在linux下,NIO可以采用epoll来实现非阻塞,注意,是在linux下:

-Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.EPollSelectorProvider

--------------------------------------------------------------------

下周就要开始弄kafka了,其实网络方面的测试还没有找到最好的解决方案,虽然测了很多东西,但是真的是没有时间去做更多更复杂的东西。接下来赶紧把mina的源码看完,再看看netty就要把重心放在kafka上了。其实网络编程还是很有必要的,好多分布式的通信方案都可以建立在一套比较完整的消息机制上。

原文地址:https://www.cnblogs.com/fengff/p/9397183.html

时间: 2024-10-18 00:31:37

【总结】两种 NIO 实现:Selector 与 Epoll的相关文章

QF——OC中把方法当做参数传递的两种形式(@selector和block)

@selector(): 可以理解@selector()就是取类方法的编号,他的基本行为等同于C语言中的函数指针(指向函数的指针).它们通过传递方法的地址(或编号)来实现把方法当做参数的效果. 不过在C语言中,可以直接把一个函数名赋给一个函数指针,但是在OC中不行,而是要通过@selector语法来取.它的括号里传入的是方法名,返回结果是 SEL类型,该类型本质上就是方法的编号(地址). block: block,名为代码块.它和函数很相似,有返回值,有名称,有参数列表. 格式: 返回值类型 (

简易版聊天系统实现 Socket VS NIO两种实现方式

说是简单聊天系统,压根不能算是一个系统,顶多算个雏形.本文重点不在聊天系统设计和实现上,而是通过实现类似效果,展示下NIO 和Socket两种编程方式的差异性.说是Socket与NIO的编程方式,不太严谨,因为NIO的底层也是通过Socket实现的,但又想不出非常好的题目,就这样吧. 主要内容 Socket方式实现简易聊天效果 NIO方式实现简易聊天效果 两种方式的性能对比 前言 预期效果,是客户端之间进行"广播"式聊天,类似于QQ群聊天.希望以后有机会,以此简易版为基础,不断演进,演

Java NIO 选择器(Selector)的内部实现(poll epoll)

http://blog.csdn.net/hsuxu/article/details/9876983 之前强调这么多关于linux内核的poll及epoll,无非是想让大家先有个认识: Java NIO中的选择器依赖操作系统内核的这些系统调用,我们这里只讲解与linux内核相关的NIO实现,当然,windows或其他操作系统实现大体上是类似的,相信大家也可以触类旁通. 那么,本文从这里将从简到难,一步一步为大家讲解选择器的点点滴滴吧. 选择器的宏观理解“有这么一种检查员,她工作在养鸡场,每天的工

epoll的两种触发模式

epoll有两种模式,Edge Triggered(简称ET) 和 Level Triggered(简称LT).在采用这两种模式时要注意的是,如果采用ET模式,那么仅当状态发生变化时才会通知,而采用LT模式类似于原来的select/poll操作,只要还有没有处理的事件就会一直通知. 以代码来说明问题: 首先给出server的代码,需要说明的是每次accept的连接,加入可读集的时候采用的都是ET模式,而且接收缓冲区是5字节的,也就是每次只接收5字节的数据: Java代码   #include <

epoll的两种工作模式

epoll有两种模式,Edge Triggered(简称ET) 和 Level Triggered(简称LT).在采用这两种模式时要注意的是,如果采用ET模式,那么仅当状态发生变化时才会通知,而采用LT模式类似于原来的select/poll操作,只要还有没有处理的事件就会一直通知. 以代码来说明问题: 首先给出server的代码,需要说明的是每次accept的连接,加入可读集的时候采用的都是ET模式,而且接收缓冲区是5字节的,也就是每次只接收5字节的数据: Java代码   #include <

Java NIO类库Selector机制解析--转

一.  前言 自从J2SE 1.4版本以来,JDK发布了全新的I/O类库,简称NIO,其不但引入了全新的高效的I/O机制,同时,也引入了多路复用的异步模式.NIO的包中主要包含了这样几种抽象数据类型: Buffer:包含数据且用于读写的线形表结构.其中还提供了一个特殊类用于内存映射文件的I/O操作. Charset:它提供Unicode字符串影射到字节序列以及逆映射的操作. Channels:包含socket,file和pipe三种管道,都是全双工的通道. Selector:多个异步I/O操作集

两种高性能I/O设计模式(Reactor/Proactor)的比较

综述 这篇文章探讨并比较两种用于TCP服务器的高性能设计模式. 除了介绍现有的解决方案,还提出了一种更具伸缩性,只需要维护一份代码并且跨平台的解决方案(含代码示例),以及其在不同平台上的微调. 此文还比较了java.c#.c++对各自现有以及提到的解决方案的实现性能. 系统I/O 可分为阻塞型, 非阻塞同步型以及非阻塞异步型[1.2]. 阻塞型I/O意味着控制权只到调用操作结束了才会回到调用者手里. 结果调用者被阻塞了, 这段时间了做不了任何其它事情. 更郁闷的是,在等待IO结果的时间里,调用者

Kubernetes 集群的两种部署过程(daemon部署和容器化部署)以及glusterfs的应用!

ClusterIp:通过VIP来访问, NodePort: 需要自己搭建负载据衡器 LoadBalancer:仅仅用于特定的云提供商 和 Google Container Engine https://www.nginx.com/blog/load-balancing-kubernetes-services-nginx-plus/ port:相当于服务端口(对及集群内客户访问) targetPort: 相当于pods端口 nodePort: 宿主机端口(也是服务端口,只不过是对集群外客户访问)

第九章 两种模式的比较

#include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <arpa/inet.h> #include <assert.h> #include <stdio.h> #include <unistd.h> #include <errno.h> #include <string.h> #include