这两个问题看起来矛盾："端口既然只能一个程序监听，那哪来的'一群'进程被惊醒？" 本文把这条逻辑链完整打通。
Q：一个端口能被两个程序同时监听吗？
默认不能。同一个 (协议, IP, 端口) 三元组，在同一网络命名空间里只能被一个 socket 绑定并监听。第二个程序调用 bind() 会直接失败，返回 EADDRINUSE (Address already in use)。
唯一的例外：所有 socket 都显式设置了 SO_REUSEPORT（Linux 3.9+），才允许多个 socket 绑定完全相同的地址与端口 —— 这是内核专门开的口子，且每个 socket 有自己独立的 accept 队列。
Q：那惊群问题是怎么来的？
惊群跟"两个程序监听同一端口"毫无关系。它的真实场景是：一个监听 socket，被多个进程/线程共享（典型是 fork() 继承 fd），这些进程全都阻塞在同一个 accept() 上。一个连接到达时，内核把所有等待者都唤醒，可连接只有一个 —— 醒了却抢不到的人白忙一场，再回去睡。
一句话化解矛盾：端口确实只有一个"监听者"，但监听者身后排着一队等着接客的服务员。"群"指的是这队服务员，不是多个监听者。
内核判断"这个端口有没有被占"，看的是四元组（监听场景是三元组）：协议 + IP + 端口。
| 场景 | 能否共存 | 说明 |
|---|---|---|
| TCP 8080 与 TCP 8080（同 IP） | 不能 | 完全相同的三元组 → EADDRINUSE |
| TCP 8080 与 UDP 8080 | 能 | 协议不同，是两个独立的端口空间 |
| 127.0.0.1:8080 与 10.0.0.5:8080 | 能 | 绑定 IP 不同（多网卡机器常见） |
| 0.0.0.0:8080 与 10.0.0.5:8080 | 视情况 | 需 SO_REUSEADDR，且行为依赖系统 |
两个进程都设 SO_REUSEPORT 绑同一 IP:端口 | 能 | 内核允许，各有独立 accept 队列，由内核分发 |
SO_REUSEADDR：主要解决"端口处于 TIME_WAIT 时重启服务绑不上"的问题，让地址可以复用。它并不能让两个进程同时监听同一个端口（这是最常见的误解）。
SO_REUSEPORT：才是"允许多个 socket 绑定完全相同 addr:port"的那个开关。它本来的设计目的之一，恰恰就是为了解决惊群。
关键在 fork()：子进程会继承父进程的文件描述符。如果父进程先创建好 listening socket 再 fork 出 N 个 worker，那么这 N 个 worker 手里拿的是同一个 socket 的引用（内核里是同一个 struct sock，只是引用计数 +N）。
定义：当一个资源变为可用（有新事件）时，内核/框架把所有等待这个资源的进程/线程全部唤醒，但最终只有一个（或少数几个）能真正拿到并处理它 —— 其余的都在"白醒"，做了一次无效的调度与上下文切换。
名字由来：英文 thundering herd，形容一群牲畜/鸟受惊后同时狂奔。一个小小的事件，惊动了一整群。
下面模拟一组 worker 共享同一个 listening socket。点「来一个连接」观察：普通模式下全部 worker 被唤醒，只有 1 个成功；切到「独占唤醒」模式后，内核只叫醒 1 个。
EPOLLEXCLUSIVE / SO_REUSEPORT 做的事。这是最容易讲错的一节，必须分层看：
| 场景 | 是否惊群 | 说明 |
|---|---|---|
多进程直接阻塞在 accept()（fork 共享 listening fd） |
基本已修复 | Linux 2.6 起，内核在 accept 等待队列上用了独占唤醒（WQ_FLAG_EXCLUSIVE）：新连接入队时只唤醒一个进程。经典 accept 惊群在现代内核上基本不存在了。 |
多进程用各自 epoll 监听同一个 listening fd |
仍然惊群 | 每个 epoll 实例都会收到可读事件并唤醒自己的进程 → 多个进程同时被叫醒去 accept，只有一个成功。这是今天最常遇到的惊群。 |
select / poll 共享 fd |
惊群 | 同 epoll，无独占唤醒机制。 |
多个 socket 各自 SO_REUSEPORT |
不惊群 | 每个 socket 有独立的 accept 队列，内核按四元组 hash 选一个 socket，只唤醒它的等待者。 |
所以"既然端口只能一个程序监听，为什么会有惊群"的完整答案是：
惊群发生在"一个监听 socket + 多个等待者"这个结构上（fork 共享 fd / 多 epoll 实例监听同一 fd），跟"几个程序监听端口"无关。即使全世界只有一个程序能 bind 这个端口，只要它 fork 出 8 个 worker 共享这个 fd，惊群的条件就成立了。
只让一个线程/进程负责 accept()，拿到 connfd 后通过管道/队列分发给 worker 处理。没有竞争就没有惊群。缺点是单点可能成为瓶颈（但 accept 本身很快，多数场景够用）。
worker 之间抢一把锁，只有拿到锁的进程才把 listening fd 加入自己的 epoll。锁的粒度是"要不要去监听"，不是"每次 accept 都抢锁"，所以开销可控。缺点：仍有一次锁竞争，且负载可能不均。
把 fd 以独占方式加入 epoll：EPOLL_CTL_ADD 时带上 EPOLLEXCLUSIVE。事件就绪时，内核只唤醒其中一个 epoll 实例，而不是全部。改一个 flag 就能解决，代价最小。
struct epoll_event ev; ev.events = EPOLLIN | EPOLLEXCLUSIVE; // ← 关键：独占唤醒 ev.data.fd = listenfd; epoll_ctl(epfd, EPOLL_CTL_ADD, listenfd, &ev);
每个进程各自 socket + bind + listen 同一端口，内核做负载均衡。注意：这正好是本文开头说的"端口能被多个程序监听"的唯一例外情况。
| 方案 | 是否有惊群 | 是否需加锁 | 负载均衡 | 备注 |
|---|---|---|---|---|
| 单 acceptor + 分发 | 无 | 不需要 | 取决于分发策略 | 简单可靠，accept 通常不是瓶颈 |
| accept_mutex | 无 | 需要 | 一般 | Nginx 早期方案，accept_mutex on |
| EPOLLEXCLUSIVE | 无 | 不需要 | 较好（内核挑一个） | Linux 4.5+，改动最小 |
| SO_REUSEPORT | 无 | 不需要 | 好（hash 分发） | Linux 3.9+，Nginx 1.9.1+ 支持，现代首选 |
"一次事件唤醒一群，只有一个有用"这个模式到处都是，理解了这个模式就能举一反三：
| 场景 | 表现 | 常见解法 |
|---|---|---|
| 条件变量 | notify_all() 唤醒全部等待线程，只有一个能拿到任务 | 用 notify_one() |
| 线程池 | 一个任务入队，所有空闲线程被唤醒争抢 | 任务队列 + 单唤醒 |
| select/poll/epoll 共享 fd | 同上文 accept 场景 | EPOLLEXCLUSIVE / SO_REUSEPORT |
| 缓存击穿 | 热点 key 过期瞬间，海量请求同时打到数据库 | 互斥重建 / 逻辑过期 / 提前预热 |
| 锁竞争 | 锁释放时唤醒所有等待者，只有一个抢到 | 队列化排队唤醒 |
Q：一个端口能被两个程序同时监听吗？
A：默认不能。(协议, IP, 端口) 三元组唯一，第二个 bind() 会返回 EADDRINUSE。SO_REUSEADDR 只解决 TIME_WAIT 复用，不能让两个进程同时监听；只有所有 socket 都设了 SO_REUSEPORT 才可以，此时每个 socket 有独立 accept 队列，由内核 hash 分发。
Q：那惊群是怎么回事？
A：惊群不是多个程序监听同一端口导致的，而是一个监听 socket 被多个进程/线程共享、全部阻塞在同一个 accept()（或同一个 fd 的 epoll）上。事件到达时内核如果唤醒所有等待者，就只有 1 个能成功，其余 N−1 个白醒，白白付出调度与上下文切换代价。
现代 Linux 上：裸 accept 的惊群已被内核的独占唤醒基本修复；但多个 epoll 实例监听同一 listening fd 仍会惊群，需要 EPOLLEXCLUSIVE（Linux 4.5+）或 SO_REUSEPORT（Linux 3.9+）。Nginx 早期用 accept_mutex，现在推荐 SO_REUSEPORT。
一句话口诀：端口只能一个主，fork 之后一群人；事件来时别全叫，独占唤醒才高效。