实际项目中，我们有很多高并发的场景需要考虑、设计，在高并发领域有个很有特点的名词叫惊群效应，你了解吗？

一、啥是惊群效应

啥叫惊群效应，有个例子说明的很透彻。当你往一群鸽子中间扔一块食物，虽然最终只有一个鸽子抢到食物，但所有鸽子都会被惊动来争夺，没有抢到食物的鸽子只好回去继续睡觉， 等待下一块食物到来。这样，每扔一块食物，都会惊动所有的鸽子，即为惊群。

也就是说，虽然只扔了一块实物，但是惊动了整个鸽群，最后只有一个鸽子抢到食物了，浪费了其他鸽子的能量。

二、惊群导致的问题

对于操作系统来说，多个进程/线程在等待同一资源是，也会产生类似的效果，其结果就是每当资源可用，所有的进程/线程都来竞争资源，造成了资源的浪费。

系统对用户进程/线程频繁的做无效的调度、上下文切换，系统系能大打折扣。为了确保只有一个线程得到资源，用户必须对资源操作进行加锁保护，进一步加大了系统开销。三、常见的惊群场景

1、linux惊群

linux中惊群主要是accept惊群和epoll惊群。

1）accept惊群，以多进程为例，在主进程创建监听描述符listenfd后，fork()多个子进程，多个进程共享listenfd，accept是在每个子进程中，当一个新连接来的时候，会发生惊群。

2）epoll惊群分两种，一是在fork之前创建epollfd,所有进程共用一个epoll；二是在fork之后创建epollfd,每个进程独用一个epoll。

epoll惊群和accept惊群类似，共享一个epollfd, 加锁或标记解决。在新的linux内核版本中都已得到解决。

2、nginx惊群

在nginx中使用的epoll，是在创建进程后创建的epollfd。因些会出现类似linux的惊群问题。即每个子进程worker都会惊醒。

nginx使用了互斥锁来解决惊群的问题。

采用了主动的方法去把监听描述符放到epoll中或从epoll移出。采用互斥锁去解决谁来accept问题，保证了同一时刻，只有一个worker接收新连接（所以nginx并没有惊群问题）。根据自已的载负情况，决定去不去抢锁，简单方便地解决负载，防止进程因业务太多而导致所有业务都不及时处理。

3、线程池惊群

多线程设计中，经常会用到互斥和条件变量的问题。当一个线程解锁并通知其他线程的时候，就会出现惊群的现象。

pthread_mutex_lock，线程互斥锁的加锁及解锁函数。pthread_cond_wait，线程池中的消费者线程等待线程条件变量被通知。pthread_cond_signal，生产者线程通知线程池中的某个或一些消费者线程池，接收处理任务。

这里的惊群现象出现在3里，pthread_cond_signal，语义上看，是通知一个线程。调用此函数后，系统会唤醒在相同条件变量上等待的一个或多个线程（可参看手册）。如果通知了多个线程，则发生了惊群。

1）一般用法，

所有线程共用一个锁，共用一个条件变量。当pthread_cond_signal通知时，就可能会出现惊群

2）解决惊群的方法，

所有线程共用一个锁，每个线程都有自己的条件变量。pthread_cond_signal通知时，定向通知某个线程的条件变量，不会出现惊群。

好了，惊群效应大体了解了吧。惊群有不同的场景和解决方案，在高并发场景下，需要做适当考虑哦。