Linux中epoll+线程池实现高并发

服务器并发模型通常可分为单线程和多线程模型，这里的线程通常是指“i/o线程”，即负责i/o操作，协调分配任务的“管理线程”，而实际的请求和任务通常交由所谓“工作者线程”处理。通常多线程模型下，每个线程既是i/o线程又是工作者线程。所以这里讨论的是，单i/o线程+多工作者线程的模型，这也是最常用的一种服务器并发模型。我所在的项目中的server代码中，这种模型随处可见。它还有个名字，叫“半同步/半异步“模型，同时，这种模型也是生产者/消费者（尤其是多消费者）模型的一种表现。

这种架构主要是基于i/o多路复用的思想（主要是epoll，select/poll已过时），通过单线程i/o多路复用，可以达到高效并发，同时避免了多线程i/o来回切换的各种开销，思路清晰，易于管理，而基于线程池的多工作者线程，又可以充分发挥和利用多线程的优势，利用线程池，进一步提高资源复用性和避免产生过多线程。

瓶颈在于io密集度。

线程池你开10个线程当然可以一上来全部accept阻塞住，这样客户端一连上来便会自动激活一个线程去处理，但是设想一下，如果10个线程全部用掉了，第11个客户端就会发生丢弃。这样为了实现”高并发“你得不断加大线程池的数量。这样会带来严重的内存占用和线程切换的时延问题。

于是前置事件轮询设施的方案就应运而生了，

主线程轮询负责io，作业交给线程池。

在高并发下，10w个客户端上来，就主线程负责accept，放到队列中，不至于发生没有及时握手而丢弃掉连接的情况发生，而作业线程从队列中认领作业，做完回复主线程，主线程负责write。这样可以用极少的系统资源处理大数量连接。

在低并发下，比如2个客户端上来，也不会出现100个线程hold住在那从而发生系统资源浪费的情况。

正确实现基本线程池模型的核心：

主线程负责所有的 i/o 操作，收齐一个请求所有数据之后如果有必要，交给工作线程进行处理 。处理完成之后，把需要写回的数据还给主线程去做写回 / 尝试写回数据直到阻塞，然后交回主线程继续。

这里「如果有必要」的意思是：经过测量，确认这个处理过程中所消耗的 cpu 时间（不包括任何 i/o 等待，或者相关的 i/o 等待操作无法用 epoll 接管）相当显著。如果这个处理过程（不包含可接管的 i/o 操作）不显著，则可以直接放在主线程里解决。

这个「必要」与否的前提不过三个词：假设，分析，测量。

所以，一个正确实现的线程池环境钟，用 epoll + non-blocking i/o 代替 select + blocking i/o 的好处是，处理大量 socket 的时候，前者效率比后者高，因为前者不需要每次被唤醒之后重新检查所有 fd 判断哪个 fd 的状态改变可以进行读写了。

实现单i/o线程的epoll模型是本架构的第一个技术要点，主要思想如下： 

单线程创建epoll并等待，有i/o请求（socket）到达时，将其加入epoll并从线程池中取一个空闲工作者线程，将实际的业务交由工作者线程处理。

刚学线程池，若有误请大家指出(可联系我，下有邮箱)：

服务器代码：

lock.h

threadpool.h,还没有实现动态增加功能，以后待更新...

epollserver.h

server.cpp服务器的主函数

客户端程序:

github：https://github.com/tianzengblog/websserver