java nio在linux上默认使用epoll，但jvm不控制epoll_ctl/epoll_wait的cpu核绑定，其调度完全由内核决定；epoll_ctl是轻量同步调用，epoll_wait唤醒位置取决于线程亲和性与内核调度，性能关键在于事件分发模型而非绑定。

Java NIO 在 Linux 上默认使用 epoll 实现 Selector，但 JVM 本身**不直接控制 epoll_ctl 或 epoll_wait 在哪个 CPU 核心上运行**，也不做显式的 CPU 插槽绑定。它的调度完全交由操作系统内核完成，JVM 层面仅通过系统调用间接参与。

epoll_ctl 的执行不受 CPU 绑定影响

epoll_ctl 是一次同步的内核系统调用，用于向 epoll 实例注册、修改或删除文件描述符（fd）及其关注事件。它不阻塞、不轮询、不等待事件，只更新内核中该 epoll 实例关联的红黑树（rbr）和就绪队列结构。

• 调用发生在用户线程上下文中，哪个线程调用，就在该线程当前被调度的 CPU 上执行系统调用入口
• 内核处理 epoll_ctl 时主要操作内存数据结构（如 rbtree 插入），不涉及跨核同步锁（现代内核已做 per-epoll 实例锁优化），因此无显著跨核开销
• 没有机制让 Java 程序指定“这个 epoll_ctl 必须在 CPU 3 上执行”——这既非 epoll 接口设计目标，也无实际必要

epoll_wait 的调度由内核决定，与线程亲和性间接相关

epoll_wait 是阻塞式系统调用，等待就绪事件。它是否唤醒、在哪颗 CPU 上返回，取决于：

Ag Model Usage

一款AI工具，主要用于使用 CodexBar CLI 本地成本使用情况，按模型汇总 Codex 或 Claude 的使用量，包括当前（最新）模型或完整的模型分解，适合需要提升相关任务效率的用户。

下载

• 调用线程是否设置了 CPU 亲和性（例如通过 pthread_setaffinity_np 或 taskset 启动 JVM）
• 内核调度器对线程的迁移策略（CFS 默认允许跨核迁移）
• 就绪事件发生时，中断服务程序（ISR）所在的 CPU（例如网卡软中断 softirq 在哪个 CPU 上处理完并触发 ep_poll_callback）

注意：epoll_wait 返回后，Java 线程继续执行 updateSelectedKeys() 等逻辑，这部分纯用户态代码的执行位置，仍遵循 OS 线程调度规则，JVM 不干预。

Netty 等框架的实践：靠线程模型规避跨核争用

高性能网络库（如 Netty）并不依赖绑定 epoll 到特定核，而是采用更有效的策略：

• 每个 EventLoop（单线程 Reactor）独占一个 epoll 实例，避免多线程并发调用 epoll_ctl/epoll_wait 引发锁竞争
• 通过 EpollEventLoopGroup 配置线程数，通常设为 CPU 核心数，再配合 JVM 启动参数（如 -XX:+UseThreadPriorities）提升调度优先级
• 部分部署会配合 taskset -c 0-3 java -jar app.jar 将整个 JVM 限定在特定 CPU 插槽，使 epoll_wait 唤醒后的 Java 工作线程更大概率留在本地核，减少 cache line bouncing

真正影响性能的是事件分发模式，不是 epoll 绑定

比起纠结 epoll_ctl 在哪执行，以下因素对多核伸缩性影响更大：

• 是否启用边缘触发（ET）+ 非阻塞 I/O：避免重复通知，降低 epoll_wait 调用频次
• 是否批量处理就绪 fd（epoll_wait 的 maxevents 参数合理设置，避免单次只取 1 个）
• 是否将 accept 和 I/O 处理分离（如主线程只 accept 并轮询分发到子 EventLoop，避免惊群）
• 网卡多队列（RSS）是否与 Java 线程绑核对齐（例如 rx queue 0 → CPU 0 → EventLoop 0）