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