网络编程多个 epoll 线程有何作用？

不懂 epoll ，不过单线程去 accept ，那短连接的瓶颈就在这单个线程了，毕竟 accpet 之后还要分发到其他线程去处理

如果你 epoll 事件会进行 CPU 密集型操作的话建议把操作交给另一个线程，epoll 作为分发器把任务分给其他的线程

读写 fd 有它固有的消耗，无论你是 select 还是 epoll ，单线程跑满了就只能多开线程

one loop one thread 和 one loop all threads 只是两种不同的编程模型，取决于 epoll 接收到事件后怎么处理。没有绝对的优劣

再快也是有极限的吧

参照 nginx ，epoll_wait 专门一个 master 进程可以用作套接字的 三次握手、四次挥手；和读、写数据包的事件通知仅仅做通知。
真正耗费时间的是读、写数据包和期间的业务处理过程，所以放到单独 worker 下最佳。可以显著避免阻塞 epoll_wait 进程。想要 高并发必须要做的。

@nibaozhu 在进程这个层次不存在三次握手。内核做好 TCP 连接之后，才轮到 userland 的 accept/epoll ready

多路复用是相对于每次只能处理一个连接的编程模式来说的（单个线程），都可以使用多线程增加处理能力

多线程一般是为了充分利用 CPU 性能，尤其是处理逻辑里涉及 CPU 密集的代码时

@julyclyde 不是 listen 完，有客户上来内核就自动做好 TCP 连接。这里必须由用户的进程主动调用 accept 函数（不管异步与否），然后由中断切换到系统调用 sys_accept4 返回客户机地址及套接字，这个过程没有 epoll 也是可以的，epoll 只是提高了效率，不是必要条件。

epoll_wait 返回后，可以遍历触发事件的列表，结构体里面包含了套接字，（如果是 listen 套接字就说明有新晋的客户端需要建立新连接，如果是之前已经建立连接的 对端套接字，那这种情况下根据是可读可写标志做判断，如果读到零，说明客户机需要关闭连接，这种需要调用 shutdown 关闭套接字）。