IO复用
Posted cynchanpin
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了IO复用相关的知识,希望对你有一定的参考价值。
IO复用简单介绍
- client程序要同一时候处理多个socket。
- client程序要同一时候处理用户输入和网络连接。
- TCPserver同一时候处理监听socket和连接socket。
- server要同一时候处理TCP请求和UDP请求。
select系统调用
select API
#include <sys/select.h> #include <sys/time.h> int select(int maxfd, fd_set *readfds, fd_set *writefds, fe_set *exceptfds, const struct timeval *timeout);
select调用返回时。内核将改动它们来通知应用程序哪些文件描写叙述符已经就绪。
这3个參数是fd_set结构体指针类型。
因为位操作过于繁琐。我们应该使用以下的一系列宏来訪问fd_set结构体中的位:
void FD_CLR(int fd, fd_set *fdset) /* 清除fdse全部位.*/ int FD_ISSET(int fd, fd_set *fdset) /* 測试fdset的位fd是否被设置 */ void FD_SET(int fd, fd_set *fdset) /* 设置fdset的位fd */ void FD_ZERO(fd_set *fdset) /* 清除fdset的位fd */
它是一个timeval结构类型的指针,採用指针參数是由于内核将改动它以告诉程序select等待了多久。只是我们不能全然信任select调用返回后的timeout值,比方调用失败时timeout值是不确定的。timeout结构体的定义例如以下:
struct timeval { long tv_sec; // seconds long tv_usec; // and microseconds };
假设给timeout传递NULL,则select将一直堵塞,直到某个文件描写叙述符就绪。
假设在超时时间内没有不论什么文件描写叙述符就绪,select将返回0.select失败时返回-1并设置errno。
假设在select等待期间。程序收到信号,则select马上返回-1,并设置errno为EINTR。
文件描写叙述符就绪条件
- socket内核接收缓存区中的字节数大于或等于其低水位标记SO_RCVLOWAT。此时我们能够无堵塞地读该socket,而且读操作返回的字节数大于0.
- socket通信的对方关闭连接。
此时对改socket的读操作将返回0.
- 监听socket上有新的连接请求。
- socket上有未处理的错误。此时我们能够使用getsockopt来读取和清除该错误。
- socket内核发送缓存区中的可用字节数大于或等于其低水位标记SO_SNDLOWAT。
此时我们能够无堵塞地写该socket,而且写操作返回的字节数大于0.
- socket的写操作被关闭。对写操作被关闭的socket运行写操作将触发一个SIGPIPE信号。
- socket使用非堵塞connect连接成功或者失败(超时)之后。
- socket上有未处理的错误。此时我们能够使用getsockopt来读取和清除该错误。
poll系统调用
#include <poll.h> int poll(struct pollfd *fd, nfds_t nfds, int timeout);
1)fds參数是一个pollfd结构类型的数组,它指定全部我们感兴趣的文件描写叙述符上发生的可读、可写和异常等事件。
pollfd结构体的定义例如以下:
struct pollfd { int fd; /* 文件描写叙述符 */ short events; /* 等待的事件 */ short revents; /* 实际发生了的事件 */ };
当中,fd成员指定文件描写叙述符。events成员告诉poll监听fd上的哪些事件。它是一系列事件的按位或。revents成员则由内核改动。以通知应用程序fd上实际发生了哪些事件。
POLLRDNORM 有普通数据可读。
POLLRDBAND 有优先数据可读。
POLLPRI 有紧迫数据可读。
POLLOUT 写数据不会导致堵塞。
POLLWRNORM 写普通数据不会导致堵塞。
POLLWRBAND 写优先数据不会导致堵塞。
POLLMSGSIGPOLL 消息可用。
此外,revents域中还可能返回下列事件:
POLLER 指定的文件描写叙述符错误发生。
POLLHUP 指定的文件描写叙述符挂起事件。
POLLNVAL 指定的文件描写叙述符非法。
这些事件在events域中无意义,由于它们在合适的时候总是会从revents中返回。
typedef unsigned long int nfds_t;
3)timeout參数指定poll的超时值,单位是毫秒。当timeout为-1时,poll调用将永久堵塞,直到某个事件发生。当timeout为0时。poll调用将马上返回。
epoll系列系统调用
内核事件表
它在实现和使用上与select、poll有非常大差异。首先,epoll使用一组函数来完毕任务。而不是单个函数。
其次、epoll把用户关心的文件描写叙述符上的事件放在内核里的一个事件表中,从而无须像select和poll那样每次调用都要反复传入文件描写叙述符集或事件集。
但epoll须要使用一个额外的文件描写叙述符,来唯一标识内核中的这个事件表。这个文件描写叙述符使用例如以下epoll_reate函数来创建:
#include<sys/epoll.h> int epoll_create(int size);
size參数如今并不 起作用,仅仅是给内核一个提示。告诉它事件表须要多大。
该函数返回的文件描写叙述符将用作其它全部epoll系统调用的第一个參数,以指定要訪问的内核事件表。
#include <sys/epoll.h> int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event)
fd參数是要操作的文件描写叙述符,op參数则指定操作类型。
操作类型有例如以下3种:
- EPOLL_CTL_ADD,往事件表中注冊fd上的事件。
- EPOLL_CTL_MOD。改动fd上的注冊事件。
- EPOLL_CTL_DEL,删除fd上的注冊事件。
epoll_event的定义例如以下:
struct epoll_event { __uint32_t events; /* Epoll events */ epoll_data_t data; /* User data variable */ };
当中events成员描写叙述事件类型。
epoll支持的事件类型和poll基本同样。表示epoll事件类型的宏是在poll相应的宏前加上“E”,比方epoll的数据可读事件是EPOLLIN。但epoll有两个额外的事件类型——EPOLLET和EPOLLONESHOT。它们对于epoll的高效运作很关键,我们将在后面讨论它们。data成员用于存储用户数据。
epoll_wait函数
#include <sys/epoll.h> int epoll_wait(int epfd,struct epoll_event * events,int maxevents,int timeout);
该函数成功时返回就绪的文件描写叙述符的个数,失败时返回-1并设置errno。
timeout參数的含义与poll接口的timeout參数同样。
maxevents參数指定最多监听多少个事件,它必须大于0.
这个数组仅仅用于输出epoll_wait检測到的就绪事件。而不像select和poll的数组參数那样既用于传入用户注冊的事件,又用于输出内核检測到的就绪事件。这就极大地提高了应用程序索引就绪文件描写叙述符的效率。
LT和ET模式
当往epoll内核事件表中注冊一个文件描写叙述符上的EPOLLET事件时。epoll将以ET模式来操作该文件描写叙述符。ET模式是epoll的高效工作模式。
而对于採用ET工作模式的文件描写叙述符,当epoll_wait检測到其上有事件发生并将此事件通知应用程序后。应用程序必须马上处理该事件,由于后序的epoll_wait调用将不再想应用程序通知这一事件。可见,ET模式在非常大程度上减少了同一个epoll事件被反复触发的次数,因此效率要比LT模式高。
EPOLLONESHOT事件
即使我们使用ET模式。一个socket上的某个事件还是可能被触发多次。这在并发程序中就会引发一个问题。比方一个线程(或进程。下同)在读取完某个socket上的数据后開始处理这些数据,而在数据的处理过程中该socket上又有新数据可读(EPOLLIN再次被触发),此时另外一个线程被唤醒来读取这些新的数据。于是就出现了两个线程同一时候操作一个socket的局面。
这当然不是我们期望的。
我们期望的是一个socket连接在随意时刻都仅仅能被一个线程处理。这一点能够使用epoll的EPOLLONESHOT事件来实现。
epoll的长处
1)支持一个进程打开大数目的socket描写叙述符(FD)select 最不能忍受的是一个进程所打开的FD是有一定限制的,由FD_SETSIZE设置。 默认值是2048。
对于那些须要支持上万连接数目的IMserver来说显然太少了。这时候你一是能够选择改动这个宏然后又一次编译内核,只是资料也同一时候指出这样 会带来网络效率的下降;二是能够选择多进程的解决方式(传统的Apache方案)。只是尽管linux上面创建进程的代价比較小,但仍旧是不可忽视的,加 上进程间数据同步远比不上线程间同步高效。所以这也不是一种完美的方案。
只是epoll 没有这个限制。它所支持的FD上限是最大能够打开文件的数目,这个数字一般远大于select
所支持的2048。举个样例,在1GB内存的机器上大约是10万左右。详细数目能够cat /proc/sys/fs/file-max察看,一般来说这个数目和系统内存关系非常大。
2)IO效率不随FD数目添加而线性下降
传统select/poll的还有一个致命弱点就是当你拥有一个非常大的socket集合,由于网络得延时,使得任一时间仅仅有部分的socket是"活跃" 的,而select/poll每次调用都会线性扫描所有的集合。导致效率呈现线性下降。可是epoll不存在这个问题,它仅仅会对"活跃"的socket进 行操作---这是由于在内核实现中epoll是依据每一个fd上面的callback函数实现的。于是,仅仅有"活跃"的socket才会主动去调用 callback函数,其它idle状态的socket则不会,在这点上,epoll实现了一个"伪"AIO,由于这时候推动力在os内核。
在一些
benchmark中,假设全部的socket基本上都是活跃的---比方一个快速LAN环境,epoll也不比select/poll低多少效率,但若 过多使用的调用epoll_ctl,效率略微有些下降。然而一旦使用idle connections模拟WAN环境。那么epoll的效率就远在select/poll之上了。
3) 使用mmap加速内核与用户空间的消息传递
这点实际上涉及到epoll的详细实现。不管是select,poll还是epoll都须要内核把FD消息通知给用户空间,怎样避免不必要的内存拷贝就显 得非常重要,在这点上,epoll是通过内核于用户空间mmap同一块内存实现的。而假设你像我一样从2.5内核就開始关注epoll的话。一定不会忘记手 工mmap这一步的。
4) 内核微调
这一点事实上不算epoll的长处。而是整个linux平台的长处。
或许你能够怀疑linux平台,可是你无法回避linux平台赋予你微调内核的能力。比 如。内核TCP/IP协议栈使用内存池管理sk_buff结构,能够在执行期间动态地调整这个内存pool(skb_head_pool)的大小---通 过echo XXXX>/proc/sys/net/core/hot_list_length来完毕。
再比方listen函数的第2个參数(TCP完毕3次握 手的数据包队列长度),也能够依据你平台内存大小来动态调整。甚至能够在一个数据包面数目巨大但同一时候每一个数据包本身大小却非常小的特殊系统上尝试最新的 NAPI网卡驱动架构。
以上是关于IO复用的主要内容,如果未能解决你的问题,请参考以下文章
java内存流:java.io.ByteArrayInputStreamjava.io.ByteArrayOutputStreamjava.io.CharArrayReaderjava.io(代码片段
java缓冲字符字节输入输出流:java.io.BufferedReaderjava.io.BufferedWriterjava.io.BufferedInputStreamjava.io.(代码片段