select, poll, epoll笔记

看网络通信框架，netty, thrift，java nio等，最后都会通过select, poll, epoll或者socket等进行通信。查了些网页，总结一下。做个笔记

1. Socket单线程阻塞通信，一次只能处理一个请求

　　缺点：性能低

　　优点：简单

2. 来一个请求，起一个线程

　　缺点：cpu可能会升的很厉害，上下问切换性能损失

　　 优点：效率高

3. 线程池

　　优点：省去了初始化线程工作

　　缺点：应该仍然有线程上下文切换

4. select/poll

　　把要监听的文件，如socket，文件，等注册到select/poll。内核轮询所有的文件，如果有文件(linux所有设备都可以看作文件)可以操作，返回给用户空间。用户空间轮询文件，找出可以操作的文件。这里如何判断文件是否可读，可写，是有设备驱动程序提供函数判断。内核调用设备驱动程序

　　优点：

　　　　1. 可以单线程管理多个文件，没有线程上下文切换

　　缺点：

　　　　1. 可以监听文件个数有限制，有资料说是1024，好像可以修改这个限制

　　　　2. 轮询所有文件，如果要监听文件变得很多，效率会下降很快

　　　　3. 这是个系统调用，调用开始把要监听所有文件拷贝到内核，内核返回时，会把准备好的文件拷贝到用户空间。用户和内核空间不断切换，需要拷贝的内容很多。效率不高

5. epoll

　　同select/poll一样，把需要监听的文件注册到epoll。epoll提供了，添加要监听的文件，删除不监听文件。这些文件一直在内核，不会大量从用户空间拷贝到内核空间。有文件可读，这里网上有资料说是函数回调，不是select采用的轮询，返回可以操作的文件给用户空间。这里只有少量拷贝

　　优点：

　　　　1. 用户空间到内核空间拷贝量较小

　　　　2. 内核空间到用户空间拷贝量小

　　　　3. 不是轮询，函数回调。随着监听文件数增多，性能不会下降很厉害

　　缺点：

　　　　1. 编写应该比较复杂

总结：

　　1. 需要处理的连接不是很多可以考虑用线程池

　　2. select/poll不一定效率比线程池性能高，如，连接数不是很多

　　3. epoll可以处理连接数很多的情况

 

 

参考：

　　1. https://segmentfault.com/a/1190000003063859

　　2. https://blog.csdn.net/shuxiaogd/article/details/50366039

　　3. https://www.zhihu.com/question/20122137