核心线程数与最大线程数设为一致是网卡级高频吞吐场景下的主动设计，需满足rss多队列绑核、非阻塞io、无混合cpu操作、可控提交节奏四大前提，可实现零扩缩开销、缓存亲和性提升及调度抖动收敛；否则易导致吞吐下降。

核心线程数与最大线程数设为一致，在网卡级高频吞吐场景下不是“凑巧省事”，而是有明确收益的主动设计——前提是任务模型匹配、IO路径已非阻塞化、且网卡与CPU资源协同到位。

适合该配置的典型场景

这类设置真正起效，需同时满足几个硬条件：

• 网卡已启用多队列（RSS）并完成CPU绑核：每个RX/TX队列绑定独立CPU核心，避免中断和软中断争抢同一核，使线程能稳定绑定到对应处理核上
• 网络IO已切换至非阻塞模型：如使用Netty或JDK 21+虚拟线程+异步SocketChannel，线程不再因recv()或send()挂起，而是通过事件通知驱动
• 无混合型CPU密集操作混入IO路径：例如JSON序列化、加解密等不放在IO线程中执行，否则会拖慢整个绑定核上的轮询效率
• 任务提交节奏可控、无突发尖峰：比如Kafka消费者以固定拉取批次+背压机制运行，而非全量堆积后集中消费

性能收益来自三重确定性

设 corePoolSize = maximumPoolSize = N（N通常等于网卡RSS队列数 × 每队列绑定的逻辑核数），带来的不是“更多并发”，而是更稳的调度质量：

• 零动态扩缩开销：避免突发流量触发新线程创建/销毁，消除GC压力与线程本地变量（ThreadLocal）反复初始化成本
• 缓存亲和性最大化：每个线程长期绑定固定CPU核心，L1/L2缓存命中率显著提升；实测在40Gbps以上吞吐时，延迟P99可降低15%～25%
• 调度抖动收敛：Linux CFS调度器对固定数量线程的调度周期更可预测，配合SCHED_FIFO或SCHED_RR（需root权限）可进一步压低尾部延迟

配套必须做的四件事

单设相等参数不等于自动生效，需同步落地以下支撑措施：

• 禁用默认无界队列：必须用 ArrayBlockingQueue 或 SynchronousQueue，容量严格匹配单核处理能力（如每核队列深度 ≤ 128）
• 拒绝策略选 CallerRunsPolicy：当队列满时由调用方线程执行，天然反压上游，防止网卡缓冲区溢出丢包
• 关闭 allowCoreThreadTimeOut：确保线程永不回收，维持绑定关系与JIT热点方法驻留
• 暴露并监控线程绑定状态：用 taskset -c -p 验证，配合 /proc//status 中的 Cpus_allowed_list 字段做巡检

什么情况下不该这么设

如果出现以下任一情况，强制设为相等反而损害吞吐：

• 业务存在明显波峰波谷（如每小时整点批量上报），且无法用限流+缓冲平滑
• 网卡未开启多队列，或中断全部落在单个CPU上（cat /proc/interrupts | grep eth 可查）
• 仍使用阻塞式HTTP客户端（如RestTemplate）或JDBC传统驱动
• 应用部署在容器中但未配 cpuset，导致OS调度打乱绑定关系