想必看这边文章的人都了解什么是惊群效应以及在Nginx中惊群效应的解决方案，如果不了解，百度一下比比皆是。
接下来直入主题，nginx中的这套解决方案真的不会出现惊群效应么？
答案为否。我们看下具体情况：
当一个进程正处于低负载，即disabled值小于等于0时，那么进程假如在这个时候拿到锁并监听listening fd，进行处理时，如果请求新链接暴增使得disabled大于0，那么进入下一个循环的时候就不走拿锁的流程，也就不会删掉listening fd 。因此此时进程处于高负载 ，且仍旧一直在Epoll监听套接字。因此，这会造成惊群效应。个人认为，这也许并不是bug，原因如下：
如果按照完全排除惊群的可能，我们可以通过修改代码使得高负载时 进程就删掉 相关监听套接字，但这会造成严重的影响。比如说，当并发量非常大时，这时候恰好每个进程都经历了上面这个情况（低负载到高负载的过程connection大增，使得突然disabled值大于0），于是我们修改使得进程删掉监听套接字，不再进行监听处理，如果这个时候还有新的链接请求到来，就没有进程为之建立链接，会造成服务不可用的情况。按照Nginx本身的逻辑来看，如果每个进程都高负载，但仍然在监听套接字，虽然会出现惊群，但是进程还是能够接受新的链接请求，只是效率不如低负载时。按照7/8的高负载阈值进行高低负载判断也是合理的，结合上面这种偶然的情况，其实这时候已经接近服务的最大性能了，虽然出现一些惊群，仅仅导致其他进程accept返回失败，其他进程仍有很多事件要去处理，想必这也是能够理解的。
ps. 有两种方式消除惊群：
1）通过把7/8这个值调整到1，那么nginx中disabled值一直小于等于0，也就可以完全消除惊群了
2）在基于7/8的基础上，进行高负载判断时，加入删除listening fd的逻辑即可
相比较而言 第一种方式 更加合理，因为它在消除惊群的同时，也榨干了自己的性能。
仅属个人理解，如有偏颇，望请指出