epoll的陷阱

Starvation

特别提出在ET模式下，因为需要一次性把数据读完，如果一次性通知的数据过大，有可能处理时间过长，导致同一线程其他的事件长时间等待。这个不仅仅是ET模式下，也不仅仅是epoll模型下才有的问题。对于网络接收模块，尽可能不要做额外工作，应该把数据接收出来，然后放到另一个分发线程，由分发线程分配到每一个对应的类中再做消息处理，减少接收网络消息使用的时间。不管有什么问题，在接收消息的时候占用过多时间，总归是不正确的做法，会产生各种无法预知的错误。

多个线程同时触发读取事件

如果使用了同一个epoll，那么在一个线程收到读取事件，开始读取数据之前，又来了一个读取事件，也就是对方又发送了一条数据，这时可能会唤起另一个线程，处理这个读取事件。然而第一个线程还没有读，那么第一次触发读取事件的数据会与第二次触发读取事件的数据合并到一起，也就是任何一个线程调用read读取socket的信息，效果都是一样的。如果两个线程同时调用read，那么结果可能是未知的，所以为了避免这种歧义的操作，需要设置EPOLLONESHOT标识，这个标识的作用就是，每次触发事件，就会把这个socket从epoll的监听列表中删除，就算来了新的数据，也不会通知，这样我们就可以安心的处理数据，处理完成后，再把socket标识重置一下，放入到epoll的监听列表中，就可以等待下次数据到来的消息了。

惊群 thundering herd

如果多个线程多个epoll，每个线程都在监听accept的消息，这时如果来了一个连接，所有的线程都会被唤醒去响应这次连接，但是只有一个线程才能成功响应，其余的线程都会报错。这个问题就是系统也不知道应该让那个epoll响应，所以就都唤醒了。可以设置SO_REUSEADDR，系统就可以自行判断，或是自己写一个全局的锁，每次竞争到锁的epoll才去响应。