引言
如果在一个网络服务器中有多个客户端发送请求，我们应该如何去处理这些请求呢？
image.png
- 多线程：每一个请求用一个线程去处理，缺点是线程上下文切换代价太大
-
单线程：像我们熟知的非常高效率的Redis就是单线程的，那么单线程处理这么多请求，如果服务器正在处理第一个客户端的请求，此时第二个客户端的请求会不会导致有些请求丢失掉呢？答案是不会的，因为处理I/O的时候并不是CPU直接去处理，而是先交给DMA控制器。
image.png
单线程处理请求算法：
while(1){
//fd是文件描述符，每个请求都以文件描述符的形式存在，请求的集合我们叫做fdx
for(fd:fdx){
//判断fd是否有数据
if(fd有数据){
读取数据；
处理；
}
}
}
Select
image.png
简而言之：select函数将文件描述符收集起来，以bitmap的形式描述，将这个bitmap交给内核，让内核帮我们判断哪些文件描述符里面有数据，当里面有1个或多个文件描述符代表的位有数据时，有数据的FD被置位，select函数返回这个FD集合，否则函数阻塞。 程序返回后循环读取FD集合，读取被置位的数据，并进行处理。 select提高效率最关键的一点是将rset交给内核去处理，提高了效率。
缺点：
- bitmap大小最多1024位，存在限制
- FDset不可重用
- rset从用户态拷贝到内核态仍然存在用户态到内核态的切换开销
- select返回的时候没有表明FDset中哪些是有数据的，还需要再次遍历一遍FDset
Poll
image.png
优点：
- 使用pollfds数组解决了大小限制问题
- 使用revent解决了FDset不可重用问题
- 其余两个问题仍然存在
epoll
image.png
<figcaption></figcaption>
可以看出epoll再poll的基础上还解决了剩余的两个问题
哪些使用了Epoll？
Redis，Nginx，JavaNIO(Linux)
