是很经典的领导者追随者模型，因为不想命名太长，就叫xpool。多个工作线程同时accept竞争一个可用的连接，拿到连接后就自己进行处理。accept这个地方加了锁是为了避免低版本内核上出现惊群效应. 一般认为在短连接的时候效果比较好，但如果同一时候连接数过多会造成没有工作线程与客户端进行连接，客户端会出现大量的连接失败。
cpool: 经典的生产者消费者模型，由一个线程不断的建立连接，通过使用select判断是否可读，可读放入等待队列，多个工作线程从等待队列里获取连接进行处理。在大压力下很少出现像xpool那样出现连接失败的问题。cpool的一个经典问题就是在长连接的时候的性能问题，如果长连接的连接数比工作线程还少的时候，当所有的连接都被处理了，有连接需要放回pool中，而这个时候如果正常建立连接的监听线程正好处于select状态，这个时候必须要等到select超时才能重新将连接放入select中进行监听，因为这之前被放入select进行监听的处理socket为空，不会有响应，这个时候由于时间的浪费造成cpool长连接的性能下降。过去的一些做法是控制连接数和服务端的工作线程数以及通过监听一个管道fd,在工作线程结束每次都激活这个fd跳出这次select。
现在可以简单换成epool就可以避免这个问题 epool: 这个只在2.6内核上支持，我们可以在2.4内核上编译到2.6内核上运行。epool的模型与cpool是一样的，只是使用epoll代替了select。提高了性能。另外由于epoll中监听的socket是随时放入，随时可以被监听到，所以不会出现上面cpool中的问题。 select 和 epoll的区别 select 和 epoll都是用来监听套接字上是否有事件发生，简单来讲，select是轮询方式，而epoll是触发方式的,用回调把信息赋给event结构体。