看网络通信框架，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