方案1：listen后，启动多个线程(进程)，对此socket进行监听（仅阻塞accept方式不惊群）。
方案2：主线程负责监听，通过线程池方式处理连接。（通常的方法）
方案3：主线程负责监听，客户端连接上来后由主线程分配实际的端口，客户端根据此端口重新连接，然后处理数据。
先考虑客户端单连接的情况：
方案1：每当有新的连接到来时，系统内核会从队列中以FIFO的方式选择一个监听线程来服务此连接，因此可以充分发挥系统的系能并且多线程负载均衡。对于单连接的场景，这种方案无疑是非常优越的。遗憾的是，对于select、epoll，内核目前无法解决惊群问题。
(nginx对于惊群问题的解决方法)
方案2：由于只有一个线程在监听，其瞬时的并发处理连接请求的能力必然不如多线程。同时，需要对线程池做调度管理，必然涉及资源共享访问，相对于方案一来说管理成本要增加不少，代码复杂度提高，性能也有所下降。
方案3：与方案2有不少类似的地方，其优势是不需要做线程调度。缺点是增加了主线程的负担，除了接收连接外还需要发送数据，而且需要两次连接，孰优孰劣，有待测试。
再考虑客户端多连接的情况：
对于数据传输类的应用，为了充分利用带宽，往往会开启多个连接来传输数据，连接之间的数据有相互依赖性，因此Server端要想很好的维护这种依赖性，把同一个客户端的所有连接放在一个线程中处理是非常有必要的。
A、同一客户端在一个线程中处理
方案1：如果没有更底层的解决方案的话，Server则需要维护一个全局列表，来记录当前连接请求该由哪个线程处理。多线程需要同时竞争一个全局资源，似乎有些不妙。
方案2：主线程负责监听并分发，因此与单连接相比没有带来额外的性能开销。仅仅会造成主线程忙于更多的连接请求。
方案3：较单线程来说，主线程工作量没有任何增加，由于多连接而造成的额外开销由实际工作线程分担，因此对于这种场景，方案3似乎是最佳选择。
B、同一客户端在不同线程中处理
方案1：同样需要竞争资源。
方案2：没理由。
方案3：不可能。
另外：
(《UNIX网络编程》第三版是在第30章)
读《UNIX网络编程》第二版的第一卷时，发现作者在第27章“客户-服务器程序其它设计方法”中的27.6节“TCP预先派生子进程服务器程序，accept无上锁保护”中提到了一种由子进程去竞争客户端连接的设计方法，用伪码描述如下:
服务器主进程:
| listen_fd = socket(...);
bind(listen_fd, ...);
listen(listen_fd, ...);
pre_fork_children(...);
close(listen_fd);
wait_children_die(...);
|
服务器服务子进程:
| while (1) {
conn_fd = accept(listen_fd, ...);
do_service(conn_fd, ...);
}
|
初 识上述代码，真有眼前一亮的感觉，也正如作者所说，以上代码确实很少见（反正我读此书之前是确实没见过）。作者真是构思精巧，巧妙地绕过了常见的预先创建 子进程的多进程服务器当主服务进程接收到新的连接必须想办法将这个连接传递给服务子进程的“陷阱”，上述代码通过共享的倾听套接字，由子进程主动地去向内 核“索要”连接套接字，从而避免了用UNIX域套接字传递文件描述符的“淫技”。
不过，当接着往下读的时候，作者谈到了“惊群” （Thundering herd)问题。所谓的“惊群”就是，当很多进程都阻塞在accept系统调用的时候，即使只有一个新的连接达到，内核也会唤醒所有阻塞在accept上 的进程，这将给系统带来非常大的“震颤”，降低系统性能。
除了这个问题，accept还必须是原子操作。为此，作者在接下来的27.7节讲述了加了互斥锁的版本：
| while (1) {
lock(...);
conn_fd = accept(listen_fd, ...);
unlock(...);
do_service(conn_fd, ...);
}
|
原 子操作的问题算是解决了，那么“惊群”呢？文中只是提到在Solaris系统上当子进程数由75变成90后，CPU时间显著增加，并且作者认为这是因为进 程过多，导致内存互换。对“惊群”问题回答地十分含糊。通过比较书中图27.2的第4列和第7列的内容，我们可以肯定“真凶”绝对不是“内存对换”。
“元凶”到底是谁？
仔 细分析一下，加锁真的有助于“惊群”问题么？不错，确实在同一时间只有一个子进程在调用accept，其它子进程都阻塞在了lock语句，但是，当 accept返回并unlock之后呢？unlock肯定是要唤醒阻塞在这个锁上的进程的，不过谁都没有规定是唤醒一个还是唤醒多个。所以，潜在的“惊 群”问题还是存在，只不过换了个地方，换了个形式。而造成Solaris性能骤降的“罪魁祸首”很有可能就是“惊群”问题。
崩溃了！这么说所有的锁都有可能产生惊群问题了？
似乎真的是这样，所以
减少锁的使用很重要。特别是在竞争比较激烈的地方。
作者在27.9节所实现的“传递文件描述符”版本的服务器就有效地克服了“惊群”问题，在现实的服务器实现中，最常用的也是此节所提到的基于“分配”形式。
把“竞争”换成“分配”是避免“惊群”问题的有效方法，但是
也不要忽视“分配”的“均衡”问题，不然后果可能更加严重哦！
