Select on 吾爱主机

Go channel 与 select：阻塞语义、关闭规则与工程实践

Wed, 29 Jul 2026 00:00:00 +0800

goroutine 之间如何安全地交换数据、如何表达“没有更多结果了”、如何在多个就绪通道里做非确定性选择——这些都落在 channel 与 select 上。Go 语言规范把 channel 定义为并发函数之间按指定元素类型发送/接收的通信机制；官方博客的口号则是：

Do not communicate by sharing memory; instead, share memory by communicating.

本文依据 Go 语言规范（Channel types / Send / Receive / close / Select statements）、Effective Go 的 Channels 章节、官方博客 Share Memory By Communicating 与 Go Concurrency Patterns: Pipelines and cancellation，把无缓冲/有缓冲阻塞规则、关闭语义、select 调度、管道关闭与取消讲清楚，并给出可复现实验与排错清单。它和「context 取消传播」互补：context 解决“该停了”，channel/select 解决“值怎么传、何时结束、多路怎么选”。

一、问题背景：共享内存锁 vs 通道通信

传统多线程模型里，线程通过共享数据结构 + 锁协作：谁拿到锁谁改状态。Go 的 CSP 风格把协作点显式化——发送/接收本身就是同步点。

常见踩坑往往不是“不会写 ch <- v”，而是对阻塞条件判断错误：

无缓冲通道上“先发后收”在单 goroutine 里会永久阻塞；
向已关闭通道发送触发 runtime panic；
对 nil 通道发送/接收会永远阻塞，select 里一不小心就“整段卡死”；
只 close 不约定所有权，多发送者并发 close 直接 panic；
管道中游生产者退出却不 close，下游 range 永不结束。

把规范里的规则记成表，比背 API 更有用。

二、核心模型：无缓冲握手与有缓冲队列

1. 创建与零值

var ch chan int // nil channel，零值
ch = make(chan int) // 无缓冲（容量 0）
ch2 := make(chan int, 0) // 同样无缓冲
buf := make(chan int, 8) // 缓冲容量 8

规范要点：

概念	规范语义	工程含义
元素类型	`chan T` / 方向 `chan<- T`、`<-chan T`	编译期限制发送/接收方向
make 容量	可选 capacity；0 或省略 → unbuffered	无缓冲 = 同步通信
缓冲通道	缓冲未满可发送、非空可接收且不阻塞	解耦生产/消费速率
零值 nil	未初始化的 channel 为 nil	对 nil 收发会永久阻塞
FIFO	通道是先进先出队列	多 goroutine 共用同一通道无需额外同步结构（仍要注意关闭约定）

无缓冲通道：只有发送方与接收方都就绪时通信才成功——值直接从发送方拷到接收方，同时完成同步。有缓冲通道：发送在缓冲有空位时即可完成；接收在缓冲有数据时即可完成。

Effective Go 的表述更偏工程直觉：

接收方总是阻塞到有数据可收；
无缓冲时，发送方阻塞到接收方取走值；
有缓冲时，发送方阻塞到值被拷入缓冲；缓冲满则等到有接收方腾出空位。

2. 发送 / 接收何时可推进

规范对 send 的可推进条件可以压缩成：

操作	可立即推进的条件	否则
无缓冲发送	已有接收方就绪	阻塞
有缓冲发送	缓冲未满	阻塞
向 closed 发送	—	runtime panic
向 nil 发送	—	永久阻塞
接收（开通道）	有数据或有发送方（无缓冲握手）	阻塞
从 closed 接收	总是可立即推进	先排空缓冲，再得到零值
从 nil 接收	—	永久阻塞

// 无缓冲：必须另一端参与
ch := make(chan string)
go func() { ch <- "ready" }()
msg := <-ch

// 有缓冲：容量内发送不阻塞
b := make(chan int, 2)
b <- 1
b <- 2
// b <- 3 // 若无接收方，此处阻塞

3. 关闭、ok 与 range

内建 close(ch) 表示“不会再有新值”。规范与管道博客共同强调的接收语义：

关闭后，先前已发送、仍在缓冲中的值会被正常接收完；
排空后，接收立即返回元素类型零值且不阻塞；
双返回值形式 v, ok := <-ch：ok == false 表示通道已关闭且没有更多值；
close(nil)、close 已关闭通道 → runtime panic；
向已关闭通道发送 → panic（这是最常见的线上事故之一）。

out := make(chan int, 3)
out <- 1
out <- 2
close(out)

for v := range out { // 自动在关闭且排空后结束
 fmt.Println(v)
}
v, ok := <-out
fmt.Println(v, ok) // 0 false

关闭约定（工程硬规则）：

发送侧关闭：通常由唯一“拥有发送权”的一方 close；多个发送者需要额外同步（例如用 sync.Once 或先汇合再 close）。
接收侧不要 close（除非协议明确且全局只有你发送——极少见）。
需要“广播停工”时，更常见的是 close 一个只读 done 信号通道（见下文管道取消），而不是让每个工作通道被多方乱关。

三、select：多路就绪与非确定性选择

select 像 switch，但 case 全部是通信操作。规范给出的执行步骤值得逐条对照代码：

进入 select 时，按源码顺序对所有 case 的通道操作数（以及发送右侧表达式）各求值恰好一次——副作用一定会发生，与最终选中哪个 case 无关；
若一个或多个通信可推进，用均匀伪随机选中其中一个；
若都不能推进且存在 default，走 default；
若都不能推进且无 default，阻塞直到至少一个可推进；
仅有 nil 通道 且无 default 的 select 永久阻塞。

select {
case v := <-a:
 handleA(v)
case b <- x:
 // 发送成功
case <-time.After(200 * time.Millisecond):
 // 超时分支（timer channel）
default:
 // 非阻塞探测：此刻无人可通信
}

工程模式

1）非阻塞试探（try-send / try-recv）

select {
case ch <- job:
default:
 // 队列满或无接收方：降级、丢弃或写指标
}

Effective Go 用 free-list + select/default 演示：缓冲通道兼作资源池，满则新建。

2）有缓冲通道当信号量

sem := make(chan struct{}, MaxOutstanding)

func handle(r *Request) {
 sem <- struct{}{} // 占坑；满则阻塞
 defer func() { <-sem }() // 释放
 process(r)
}

容量限制同时在飞的 process 数。注意：若外层对每个请求都 go handle 而不做接纳控制，仍可能制造海量 goroutine——需要在入口再限流。

3）与 context 组合：可取消等待

select {
case res := <-resultCh:
 return res, nil
case <-ctx.Done():
 return nil, ctx.Err()
}

channel 负责传结果，context 负责传“该停了”。二者不要互相替代。

四、可复现实验：阻塞、关闭与 select

下面用标准库即可在本机验证规范语义（Go 1.20+ 均可）。

package main

import (
 "fmt"
 "time"
)

func mustPanic(name string, fn func()) {
 defer func() {
 if r := recover(); r != nil {
 fmt.Println(name, "panic OK:", r)
 } else {
 fmt.Println(name, "ERROR: expected panic")
 }
 }()
 fn()
}

func main() {
 // 1) 无缓冲：单 goroutine 发送会死锁（用超时模拟探测）
 ub := make(chan int)
 go func() {
 select {
 case ub <- 1:
 fmt.Println("unexpected send success")
 case <-time.After(50 * time.Millisecond):
 fmt.Println("unbuffered send blocked as expected")
 }
 }()
 time.Sleep(80 * time.Millisecond)

 // 2) 有缓冲：容量内不阻塞
 b := make(chan int, 1)
 b <- 42
 fmt.Println("buffered len/cap:", len(b), cap(b))

 // 3) 关闭后接收
 close(b)
 v, ok := <-b
 fmt.Println("drain closed:", v, ok) // 42 true
 v, ok = <-b
 fmt.Println("after empty:", v, ok) // 0 false

 // 4) 向关闭通道发送 → panic
 mustPanic("send-on-closed", func() { b <- 1 })

 // 5) close(nil) → panic
 var n chan int
 mustPanic("close-nil", func() { close(n) })

 // 6) select 伪随机：两个都就绪时多次运行会看到不同分支
 a1, a2 := make(chan int, 1), make(chan int, 1)
 a1 <- 1
 a2 <- 2
 counts := map[string]int{}
 for i := 0; i < 200; i++ {
 // 重新填满，保证两 case 均可推进
 select {
 case <-a1:
 counts["a1"]++
 a1 <- 1
 case <-a2:
 counts["a2"]++
 a2 <- 2
 }
 }
 fmt.Println("select distribution:", counts)

 // 7) 仅 nil + 无 default：用超时包裹，避免真死锁进程
 var nilCh chan int
 select {
 case <-nilCh:
 fmt.Println("unreachable")
 case <-time.After(50 * time.Millisecond):
 fmt.Println("nil-only select would block forever without timeout")
 }
}

预期观察：

无缓冲在无人接收时发送走超时分支；
关闭通道先拿到缓冲残留，再 ok=false；
向关闭通道发送、close(nil) 触发 panic；
双就绪 select 的计数大致接近（伪随机，不保证 50/50 精确）。

五、管道：关闭传播与 done 取消

官方 Pipelines 博客的模型：

A pipeline is a series of stages connected by channels, where each stage is a group of goroutines running the same function.

每阶段从上游 channel 读、处理后写入下游 channel。结束信号有两种常见方式：

关闭数据通道：表示“没有更多输入”。因对已关闭通道的接收总可立即完成，下游 range 能自然退出；发送方在发完后 close(out)。
显式取消（done channel）：当下游提前退出、不再消费时，上游若继续发送会阻塞。博客做法是额外传入 done <-chan struct{}，由下游（或 main）close(done) 做广播，上游在 select 里同时监听 done 与数据发送，从而放弃未完成发送。

func gen(done <-chan struct{}, nums ...int) <-chan int {
 out := make(chan int)
 go func() {
 defer close(out)
 for _, n := range nums {
 select {
 case out <- n:
 case <-done:
 return
 }
 }
 }()
 return out
}

// main 中：
done := make(chan struct{})
defer close(done) // 退出时广播取消
for n := range sq(done, gen(done, 2, 3)) {
 fmt.Println(n)
 break // 提前结束也安全：done 关闭后上游不再堵在发送上
}

这与 context 的取消树是同一思想的两种载体：done 通道是轻量广播；复杂调用链更推荐 context.Context。

六、常见坑与排查清单

症状	可能根因	排查 / 修复
`fatal error: all goroutines are asleep - deadlock!`	无缓冲自收自发；所有 goroutine 互相等待	用 `go` 起对端；检查是否缺接收/发送
`panic: send on closed channel`	接收方误 close，或多发送者重复 close	单一发送所有者 close；多生产者用 WaitGroup 汇合后再 close
`panic: close of closed channel` / `close of nil channel`	重复 close 或 close 零值	`sync.Once`；初始化后再 close
goroutine 数量持续上涨	发送阻塞无人收；`go handle` 无限接纳	有缓冲限流 + context 取消；pprof `goroutine`
`range` 永不结束	上游未 close	契约：最后一个发送者负责 close
select “总是”走同一分支	另一 case 实际不可推进（nil/满/空）	打印 `len/cap`、是否 nil、是否已 close
定时器泄漏	`time.After` 在热路径大量创建	复用 `time.NewTimer` 并 `Stop`
数据竞争仍在	channel 传的是指针/切片头，共享底层数组	发送所有权转移；或拷贝；或明确只读契约

补充 runtime 视角（runtime/chan.go 注释）：缓冲通道上，缓冲非空时接收队列为空、缓冲未满时发送队列为空——实现上把“数据在缓冲”与“对端在等待队列”分成清晰不变量。排障时你不需要背这些字段，但要理解：阻塞 = 进入 sendq/recvq 等待被对端或 close 唤醒。

七、总结

无缓冲 channel = 通信 + 同步；有缓冲 = 带容量的 FIFO，用于削峰与信号量。
关闭是“不再发送”的信号，不是“销毁”；排空后接收零值；禁止向已关闭通道发送。
nil 通道收发永久阻塞；select 求值有副作用，多就绪 case 伪随机，无就绪且无 default 则阻塞。
管道靠 close 数据通道 表达结束，靠 done/context 表达提前取消，避免上游堵死。
与上一篇 Go context 取消传播 搭配：context 管生命周期，channel/select 管数据面与多路选择。

把“谁发送、谁关闭、谁取消、缓冲多大”四件事写进代码评审清单，比事后查 deadlock 日志便宜得多。

参考资料

Linux epoll I/O 多路复用：水平触发、边缘触发与工程实践

Tue, 28 Jul 2026 00:00:00 +0800

高并发服务里最常见的一类卡顿不是“CPU 不够”，而是 大量连接上只有少量真正可读/可写。若对每个连接开线程阻塞 read/write，上下文切换与内存开销会迅速失控；若用轮询扫所有 fd，又会把 CPU 烧掉。Linux 提供的 epoll 就是为“只在就绪时被唤醒”设计的 I/O 事件通知机制。

本文基于 Linux man-pages 的 epoll(7)、epoll_create(2)/epoll_create1(2)、epoll_ctl(2)、epoll_wait(2)，并结合 Python selectors 与 Nginx 连接处理文档，把 interest/ready 两张表、LT/ET 语义、ONESHOT、非阻塞与 EAGAIN、常见坑与排障 讲清楚，方便你在自研事件循环或排查 Nginx/Redis 类服务时按机制定位。

一、问题背景：为什么 select/poll 会“长不大”

传统 select(2) / poll(2) 也能多路复用，但工程上有两个长期痛点：

每次调用都要反复提交关注集合。调用者把“我关心哪些 fd、关心读还是写”整包传给内核；内核再线性扫描。连接数上来后，用户态↔内核态的拷贝与扫描成本随 N 增长。
就绪集合表达方式不友好。select 还有历史性的 fd 数量上限（与 FD_SETSIZE 相关），大规模长连接场景很难优雅扩展。

epoll 的定位不同：它在内核里维护一个 epoll 实例（本质是“容器 + 回调”），应用 只注册一次兴趣，之后用 epoll_wait 拉取当前就绪事件。man 页明确指出：epoll 既可作 水平触发（level-triggered, LT） 也可作 边缘触发（edge-triggered, ET），并且 能较好扩展到大量被监视的文件描述符。

二、核心机制：interest list 与 ready list

从用户视角看，一个 epoll 实例可理解为两张表（epoll(7) 原文概念）：

结构	含义
interest list（epoll set）	进程通过 `epoll_ctl` 注册、希望监视的 fd 集合
ready list	interest list 的子集（更准确：其中“就绪”的引用集合），由内核因 I/O 活动动态填充

配套系统调用职责清晰：

调用	作用
`epoll_create` / `epoll_create1`	创建 epoll 实例，返回 epoll 自身的 fd
`epoll_ctl`	对 interest list 做 `ADD` / `MOD` / `DEL`
`epoll_wait` / `epoll_pwait`	从 ready list 取回最多 `maxevents` 个事件；无事件时可阻塞

2.1 创建实例：优先 `epoll_create1`

epoll_create(size) 在 Linux 2.6.8 之后 忽略 size（但仍要求 size > 0）。更推荐 epoll_create1(flags)：可传 EPOLL_CLOEXEC，避免 fork+exec 时泄漏 epoll fd（与 open(2) 的 O_CLOEXEC 同理）。

2.2 注册兴趣：`epoll_ctl` 与事件掩码

struct epoll_event {
 uint32_t events; /* EPOLLIN | EPOLLOUT | ... */
 epoll_data_t data; /* 用户数据：常存 fd 或指针 */
};

int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);

常用 op：

EPOLL_CTL_ADD：加入 interest list
EPOLL_CTL_MOD：修改已有项的事件掩码/用户数据
EPOLL_CTL_DEL：从 interest list 删除

常见事件位（epoll_ctl(2)）：

标志	含义
`EPOLLIN`	可读（含对端数据、监听 socket 有新连接等）
`EPOLLOUT`	可写
`EPOLLRDHUP`	流式套接字对端关闭或关闭写半部（2.6.17+，ET 下检测对端关闭很有用）
`EPOLLPRI`	带外/异常条件（语义见 `poll(2)` 的 `POLLPRI`）
`EPOLLERR`	错误；无需在 `events` 里显式设置，`epoll_wait` 总会报告
`EPOLLHUP`	hang up；同样总会报告，不必手动设置
`EPOLLET`	请求边缘触发（默认是水平触发）
`EPOLLONESHOT`	通知一次后自动禁用该 fd，需 `MOD` 重新武装
`EPOLLEXCLUSIVE`	多 epoll 监听同一 fd 时的互斥唤醒（4.5+）

工程建议：监听 socket 与连接 socket 都建议设为非阻塞；读写方向若会频繁切换，可一次 ADD 时就挂 EPOLLIN|EPOLLOUT，避免来回 MOD 切换。

2.3 等待就绪：`epoll_wait`

int epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout);

要点：

maxevents 必须 > 0，表示输出数组容量。
timeout 单位毫秒：0 立即返回；-1 一直阻塞；正数限时等待。时间基准为 CLOCK_MONOTONIC。
返回值：就绪事件个数；0 表示超时；-1 出错（常见 EINTR）。
返回的 events[i].events 是 实际发生 的事件掩码；data 原样带回你在 ctl 时写入的用户数据。

epoll_wait 的返回策略还会尽量避免饥饿：若某次只处理“已经知道就绪”的一小撮 fd，而忽略其他已就绪 fd，系统可能长期“看不见”后者。应用层也应做 就绪队列 + 轮转处理，而不是在单次事件上无限 read 到饿死其它连接（man 页 “Starvation” 小节专门提醒）。

三、水平触发 vs 边缘触发：语义决定写法

这是 epoll 最容易写错的地方。epoll(7) 用管道例子讲得很直白：

把管道读端 rfd 加入 epoll；
写端写入 2KB；
调用 epoll_wait → 报告 rfd 可读；
应用只读了 1KB，缓冲区仍剩数据；
再次 epoll_wait：
- LT（默认）：只要缓冲区仍“可读”，就会继续报告就绪；
- ET（EPOLLET）：只在状态 发生变化 时报告；若你没把数据读到“暂时不可读”，可能 不再通知，下一次 wait 会“卡住”，尽管缓冲里还有数据。

3.1 LT：像 poll，好写，易“吵”

语义接近 poll：条件成立就通知。
适合：业务逻辑简单、可接受重复通知、希望少踩坑。
风险：若某 fd 长期可读但你处理很慢，它会反复出现在 ready list，拖慢整个循环。

3.2 ET：变化才通知，必须“抽干 + 非阻塞”

man 页对 ET 的建议可压缩成两条硬规则：

fd 必须非阻塞。否则一次阻塞 read/write 可能饿死处理其它 fd 的任务。
只有在 read/write 返回 EAGAIN（或等价“暂时不可用”）之后，才回去 epoll_wait。也就是说，事件到来后要 循环读写直到资源暂时耗尽，不能“读一次就回 wait”。

ET 适合：超高连接数、希望减少重复唤醒、团队能严格遵守非阻塞与 drain 协议的场景。很多高性能网络库默认 ET + 非阻塞。

3.3 `EPOLLONESHOT`：一次性通知与重武装

设置 EPOLLONESHOT 后，某个 fd 被 epoll_wait 报告一次，就会在 interest list 中被禁用，直到你用 EPOLL_CTL_MOD 重新启用。它常用于：

多线程 worker：保证同一连接同一时刻只被一个线程处理；
防止在处理完成前被其它线程再次取到同一事件。

代价是：处理结束后 必须记得 rearm，否则该连接“静音”。

四、最小可运行实验：管道上的 LT vs ET

下面用 Python 演示 同一场景在 LT/ET 下的不同表现（Linux 上 selectors.EpollSelector；其它平台会落到 kqueue/select 等，行为不完全等价）。目标不是抄生产框架，而是把 man 页语义变成可观测实验。

#!/usr/bin/env python3
"""LT vs ET demo on a pipe (Linux)."""
import os, select, sys

def make_pipe():
 r, w = os.pipe()
 # set non-blocking on read end for ET-safe drain
 os.set_blocking(r, False)
 os.set_blocking(w, False)
 return r, w

def run(edge: bool):
 r, w = make_pipe()
 ep = select.epoll()
 flags = select.EPOLLIN
 if edge:
 flags |= select.EPOLLET
 ep.register(r, flags)

 os.write(w, b"A" * 2048)
 print("mode:", "ET" if edge else "LT")

 # first wait should fire
 ev = ep.poll(timeout=0.2)
 print(" first poll:", ev)

 # only read 1024, leave 1024 in buffer
 data = os.read(r, 1024)
 print(" partial read:", len(data))

 # second wait: LT should still report; ET often does not
 ev2 = ep.poll(timeout=0.2)
 print(" second poll:", ev2)

 # drain remaining
 rest = b""
 while True:
 try:
 chunk = os.read(r, 4096)
 if not chunk:
 break
 rest += chunk
 except BlockingIOError:
 break
 print(" drained rest:", len(rest))
 ep.close(); os.close(r); os.close(w)

if __name__ == "__main__":
 run(edge=False)
 print("---")
 run(edge=True)

预期现象（内核版本与缓冲细节可能略有差异，但方向稳定）：

LT：partial read 后第二次 poll 仍可能看到 EPOLLIN（缓冲仍可读）。
ET：partial read 后第二次 poll 往往 超时为空，直到再次有“新数据写入”或你换回 LT/ONESHOT 策略。

这正是生产代码里 “ET 下偶发假死：连接其实有数据，事件循环却不再被唤醒” 的最小复现。

4.1 监听 socket 的标准骨架（伪代码）

/* listener, conn 均为 nonblocking */
epoll_ctl(epfd, EPOLL_CTL_ADD, listener, &(struct epoll_event){
 .events = EPOLLIN | (use_et ? EPOLLET : 0),
 .data.fd = listener,
});

for (;;) {
 int n = epoll_wait(epfd, events, MAX_EVENTS, -1);
 for (int i = 0; i < n; i++) {
 int fd = events[i].data.fd;
 if (fd == listener) {
 for (;;) { /* ET 下要循环 accept 到 EAGAIN */
 int c = accept(listener, ...);
 if (c < 0) { if (errno == EAGAIN) break; /* handle error */ }
 set_nonblocking(c);
 epoll_ctl(epfd, EPOLL_CTL_ADD, c, &(struct epoll_event){
 .events = EPOLLIN | EPOLLRDHUP | (use_et ? EPOLLET : 0),
 .data.fd = c,
 });
 }
 } else {
 do_use_fd(fd); /* ET: 读写到 EAGAIN；注意 EPOLLERR/HUP */
 }
 }
}

do_use_fd 在 ET 下必须把 可读数据读尽、可写缓冲区写满到 EAGAIN；半包协议要在用户态自己做缓冲拼装。

五、工程映射：语言运行时与 Nginx

5.1 Python `selectors`

标准库 selectors 把 epoll/kqueue/select 统一成高层 API：

DefaultSelector：当前平台最高效实现的别名（Linux 上通常是 EpollSelector）。
EVENT_READ / EVENT_WRITE：跨平台事件抽象。
register / unregister / modify / select：对应 ctl + wait 的职责拆分。

自研 asyncio 之外的小工具时，优先用 selectors，比直接 select.epoll 更易移植；但若你要精细控制 EPOLLET/ONESHOT，仍需回到平台原生接口。

5.2 Nginx 的连接处理方式

Nginx 文档 Connection processing methods 写明：Linux 2.6+ 使用高效的 epoll 方法，并支持 EPOLLRDHUP、EPOLLEXCLUSIVE 等标志。平台支持多种方法时，Nginx 会自动选最高效者，也可用 use 指令显式指定。这解释了为何“同一套配置在 Linux 与 FreeBSD 上行为细节不同”——底层分别是 epoll 与 kqueue。

六、常见坑与排查清单

症状	更可能的机制原因	排查/修复
ET 下连接“有数据但不再触发”	partial read 后未 drain 到 `EAGAIN`	循环读；确认非阻塞；对照 man 管道示例
单连接阻塞拖死整进程	阻塞 fd + 同步 `read`/`write`	全部 `O_NONBLOCK`；慢业务丢线程池/协程
某连接饿死其它连接	单 fd 上无限处理大流量	就绪列表 + 轮转；限制单次读写字节/次数
ONESHOT 后永久静音	处理完未 `EPOLL_CTL_MOD` rearm	统一在处理结束路径 rearm
对端已关仍不清理	只看 `EPOLLIN`，忽略挂断	处理 `EPOLLRDHUP`/`EPOLLHUP`/`EPOLLERR`，读到 0 关闭
`epoll_ctl ADD` 报 `EEXIST`	重复 ADD 同一 fd	用 `MOD` 改掩码，或先 `DEL`
`epoll_wait` 被信号打断	返回 `-1` + `EINTR`	循环重试，或使用 `epoll_pwait` 管理信号掩码
多进程抢同一监听 socket	惊群/重复唤醒	评估 `EPOLLEXCLUSIVE`、`SO_REUSEPORT` 等策略

排障时建议同时抓三份证据：

fd 是否非阻塞（fcntl 标志）；
interest 掩码是否含 EPOLLET/ONESHOT/RDHUP；
一次事件处理是否读/写到 EAGAIN，以及是否处理 hangup。

七、和 select/poll 的选型建议

小工具、fd 很少、要极致可移植：poll/select 或高层封装足够。
Linux 上万级长连接、自研事件循环：epoll（多数生产库默认 ET + 非阻塞）。
跨 Unix 可移植高性能库：用 libuv / netty / Go runtime 等已封装的多路复用层，而不是在业务里手写三套 epoll/kqueue/IOCP。
只做业务、不碰事件循环：理解 LT/ET 与非阻塞，是为了读懂框架文档和 flame graph，而不是 reinvent。

八、总结

epoll 在内核维护 interest list + ready list，用 create/ctl/wait 三件套把“注册”和“等待”拆开，从而在大规模 fd 上更省。
默认 LT：条件成立就通知，写法像 poll；ET：状态变化才通知，必须 非阻塞 + 读/写到 EAGAIN。
EPOLLONESHOT 适合多线程串行化处理，但务必 处理完 rearm；EPOLLRDHUP/HUP/ERR 是连接回收的关键信号。
饥饿、假死、惊群，大多不是“epoll 不灵”，而是 事件语义与读写协议不匹配。先复现 LT/ET 差异，再改生产代码。

掌握这些机制后，再看 Nginx worker、Redis 事件循环、Netty EventLoop 或自研网关，会发现它们都在同一套规则上做工程化封装。

参考资料

Linux man-pages: epoll(7) — interest/ready、LT/ET、ONESHOT、建议用法与陷阱
Linux man-pages: epoll_ctl(2) — 事件标志、ADD/MOD/DEL、EPOLLET/ONESHOT/EXCLUSIVE
Linux man-pages: epoll_wait(2) — timeout、maxevents、就绪返回语义
Linux man-pages: epoll_create(2) / epoll_create1(2) — 创建实例与 EPOLL_CLOEXEC
Python 3 Docs: selectors — High-level I/O multiplexing — EpollSelector / DefaultSelector
Nginx Docs: Connection processing methods — Linux 上 epoll 方法及 RDHUP/EXCLUSIVE 支持说明

Select on 吾爱主机

Go channel 与 select：阻塞语义、关闭规则与工程实践

一、问题背景：共享内存锁 vs 通道通信

二、核心模型：无缓冲握手与有缓冲队列

1. 创建与零值

2. 发送 / 接收何时可推进

3. 关闭、ok 与 range

三、select：多路就绪与非确定性选择

工程模式

四、可复现实验：阻塞、关闭与 select

五、管道：关闭传播与 done 取消

六、常见坑与排查清单

七、总结

参考资料

Linux epoll I/O 多路复用：水平触发、边缘触发与工程实践

一、问题背景：为什么 select/poll 会“长不大”

二、核心机制：interest list 与 ready list

2.1 创建实例：优先 epoll_create1

2.2 注册兴趣：epoll_ctl 与事件掩码

2.3 等待就绪：epoll_wait

三、水平触发 vs 边缘触发：语义决定写法

3.1 LT：像 poll，好写，易“吵”

3.2 ET：变化才通知，必须“抽干 + 非阻塞”

3.3 EPOLLONESHOT：一次性通知与重武装

四、最小可运行实验：管道上的 LT vs ET

4.1 监听 socket 的标准骨架（伪代码）

五、工程映射：语言运行时与 Nginx

5.1 Python selectors

5.2 Nginx 的连接处理方式

六、常见坑与排查清单

七、和 select/poll 的选型建议

八、总结

参考资料

2.1 创建实例：优先 `epoll_create1`

2.2 注册兴趣：`epoll_ctl` 与事件掩码

2.3 等待就绪：`epoll_wait`

3.3 `EPOLLONESHOT`：一次性通知与重武装

5.1 Python `selectors`