没有流量却把一个核吃满：Java NIO Selector 空转（JDK-6670302）的复现、定位与止血

结论先行：一台 NIO 网关"零请求、单核 100% CPU"，第一嫌疑不是业务代码，而是 JDK 在 epoll 平台上的 Selector 空转缺陷（JDK-6670302）——select() 在没有事件时频繁空醒，把 epoll_wait 变成死循环。它不报错、不 OOM、不重启，只在 top 里安静地烧一个核。下面是一次真实复盘。

一、现象与背景

某 B 端网关（Spring Boot 2.3 + Netty 4.1.x，JDK 8u192，4C8G，约 2200 条长连接挂在 epoll 上），某次上游发布后出现：

• 业务侧一切正常，QPS 不到 50，P99 稳定 28ms；
• 但 top 里某一个核持续 100%，整机 CPU 从 35% 抬到 ~75%，告警只报了"CPU 偏高"；
• jstack 抓到的栈几乎全卡在 sun.nio.ch.EPollArrayWrapper.epollWait0 → EPollSelectorImpl.doSelect → Selector.select；
• strace -p <pid> 看到 epoll_wait(...) 以每 ~0.3ms 一次的频率返回 0（没有任何就绪事件），一天能刷出上亿次系统调用。

规模感：这个"空转核"一天烧掉约 8.6 小时满核 CPU，按当时云主机单价算，纯粹浪费成本；更危险的是它把同机另一条延迟敏感链路的 P99 从 28ms 顶到 90ms——因为空转核在抢缓存行和调度时间片。

二、根因：epoll 平台的 Selector 空转 bug

机制上讲清三层：

1. epoll 的正常语义：epoll_wait 阻塞，只有 fd 就绪才返回。NIO 的 Selector.select() 正常就该是"睡到有事"。
2. JDK-6670302 的缺陷：在 Linux/epoll 路径上，由于 EPOLLONESHOT/事件计数（publicEventCount）与内核唤醒的竞态，select() 会在没有实际事件的情况下频繁返回（空醒）。正常实现里空醒后应重新进入阻塞，但这条路径下它会立刻再 epoll_wait，形成高频自旋。
3. 为什么"平时没事、偶发爆发"：空醒概率与事件到达的瞬时密度相关。上游一次批量推流、或一个连接被反复读写，会"喂"出更多空醒，让自旋被放大——所以它常跟着一次发布或流量尖峰出现，事后又"自愈"，极难复现。

关键点：这不是业务 bug，是 JDK 在特定版本 + epoll 平台上的已知缺陷，跨语言只影响走 NIO/Netty 的 Java 进程。

三、具体做法：复现、定位与止血

1）先确认是不是空转，而不是真忙

# 单核高、整机不高 → 空转特征
top -H -p <pid>            # 看是否单一线程 100%
strace -c -p <pid> -e epoll_wait   # 采样 3s，看 epoll_wait 次数与返回值
# 若 epoll_wait 返回 0 的占比 > 99% 且频率极高 → 基本坐实空转

2）止血：在 select 循环里垫一个极短 sleep（Netty 当年的经典 workaround）

// 空转保护：select 返回 0 且非主动 wakeup 时睡 10ms，打断自旋
long idle = System.nanoTime();
int n = selector.select(1000);
if (n == 0 && Thread.interrupted() == false) {
    Thread.sleep(10);   // 打断空醒自旋，代价是 +10ms 唤醒延迟
}

注意：Thread.sleep(10) 是止血不是根治，它把每 0.3ms 一次的自旋降到每 10ms 一次，单核立刻从 100% 回落到 <1%；代价是极端情况下事件唤醒最多延迟 ~10ms，对延迟敏感链路要评估。

3）根治：升级 JDK 到修复版本，或换事件循环实现

• 升级到已修复该竞态的 JDK 8u 更高版本 / JDK 11+（epoll 路径对空醒做了 idle 检测与退避）；
• 或确认 Netty 版本已内置空转保护（较新的 Netty 在 EpollEventLoop 里对 selectNow 空返做了 backoff）；
• 升级后用 strace -c 复测：epoll_wait 频率应从每秒数十万次回落到每秒个位数~几十次。

4）加一道可观测护栏

# 监控：单核 > 90% 持续 3min 且 QPS < 阈值 → 判定"空转"告警，区别于"真高负载"
cpu.per_core.utilization:
  alert: "core_util > 0.9 for 3m and qps < 100"

四、踩过的坑 / 反直觉之处

• 最反直觉：jstack 栈看起来"很健康"——全在 epollWait，像个正常的阻塞线程。真正的线索是 strace 里 epoll_wait 的高频 + 返回 0，而不是 Java 栈。
• Thread.sleep(10) 别嫌脏：它是官方 workaround 级别的止血，比"重启大法"可控得多；但别把它当永久方案，否则你会失去对真实高负载的敏感度（因为真正的忙也会被睡平）。
• 空转会"污染邻居"：同一个容器/主机上，空转核抢 L3 缓存与时间片，能把无关进程的尾延迟顶高——这是这次最隐蔽的代价，监控只看单进程完全发现不了。
• 升级 JDK 未必立刻见效：有些构建/发行版对 epoll 路径打了自己的补丁或没打全，务必用 strace -c 的前后频率对比作为验收，而不是"升了就完事"。
• 复现极难：它依赖事件到达密度的竞态，压测工具造不出"恰好那种节奏"。我倾向于把它列为已知风险而非"复现后修复"，靠护栏 + 版本基线兜底。

五、结论与可复用清单

结论：NIO/Netty 服务出现"无流量单核 100%"，优先排查 JDK epoll 空转（JDK-6670302 一族缺陷），而不是先怀疑业务代码或 GC。

可复用清单

1. 判据：top -H 单线程 100% + strace -c 里 epoll_wait 高频且返回 0 占比 >99% → 空转。
2. 止血：select 循环空返时 Thread.sleep(10)，代价 +10ms 唤醒延迟，需评估。
3. 根治：升级 JDK 到修复版本 / 用带空转保护的 Netty；以 strace 频率回落为验收。
4. 护栏：加"单核高 + 低 QPS"的复合告警，与真实高负载区分开。
5. 邻域意识：空转会抬高同机无关进程尾延迟，监控要看到整机/容器层。
6. 纪律：把它当已知风险管理（版本基线 + 护栏），别指望能稳定复现。

留一个开放问题给大家：你们线上有没有遇到过"没流量却烧核"的场景？如果是空转，你们最后是靠升级 JDK、加 sleep 止血、还是换事件循环（epoll/kqueue）解决的？另外——有没有人遇到过 epoll 空转和 busy-poll（EPOLLEXCLUSIVE / busy poll 模式）叠加的情况？ 我怀疑在容器里这两件事的边界比文档写的要模糊，想听听大家的实测。