基本概念：子进程继承父进程环境和上下文的大部分内容的拷贝，其中就包括文件描述符表。
父进程fork出来的子进程，复制父进程的文件描述符。这些文件描述符fd是独立的，但是文件描述符指向的系统文件表项是唯一的，即是 struct file本身唯一。
同理，fork得到的子进程和父进程共享同一个socket（套接字代表文件）。fd与文件关联，通过绑定struct sockaddr套接字地址空间，跟特定的ip和端口绑定在一起。
所以在子进程中accept（listen，....)，虽然listen在不同进程中，代表不同的进程的文件描述符，但是这个文件描述符对应的套接字是一样的。又因为套接字指定了套接字地址，所以可以监听来自客户端的连接。
惊群的服务器的模型：
父进程listen之后，子进程堵塞在accept函数这里，这就是惊群发生的根本原因
惊群现象：
当父进程绑定一个端口监听socket，然后fork出多个子进程，子进程们开始循环处理（比如accept）这个socket。每当用户发起一个TCP连接时，多个子进程同时被唤醒，然后其中一个子进程accept新连接成功，余者皆失败，重新休眠。
惊群现象的危害：
在较老的unix系统中，当有连接到来时，accept()在每个阻塞在这的进程里被唤醒。但是，只有这些进程中的一个能够真正的accept这个连接，其他的进程accept将返回EAGAIN，惊群造成的结果是系统对用户进程/线程频繁的做无效的调度、上下文切换，系统系能大打折扣。
解决：
我们不能只用一个进程去accept新连接么？然后通过消息队列等同步方式使其他子进程处理这些新建的连接，这样惊群不就避免了？没错，惊群是避免了，但是效率低下，因为这个进程只能用来accept连接。对多核机器来说，仅有一个进程去accept，这也是程序员在自己创造accept瓶颈。所以，我仍然坚持需要多进程处理accept事件。
其实，在linux2.6内核上，accept系统调用已经不存在惊群了（至少我在2.6.18内核版本上已经不存在）。大家可以写个简单的程序试下，在父进程中bind,listen，然后fork出子进程，所有的子进程都accept这个监听句柄。这样，当新连接过来时，大家会发现，仅有一个子进程返回新建的连接，其他子进程继续休眠在accept调用上，没有被唤醒。（没有被唤醒，继续休眠）
解决方法：