直接对齐cpu核心数是大范围数据扫描任务最稳妥起点，需用runtime.getruntime().availableprocessors()动态获取逻辑核心数，设maximumpoolsize为该值或+1，corepoolsize与之相等，选用synchronousqueue，配合pidstat等工具验证cpu利用率是否趋近100%。
直接对齐 CPU 核心数是大范围数据扫描类任务最稳妥的起点，但“对齐”不是简单套用 availableProcessors()，而是让线程数与 CPU 计算能力形成低开销、高吞吐的匹配关系。关键在识别任务是否真正属于 CPU 密集型——如果扫描过程包含大量解压缩、哈希计算、正则匹配或内存遍历运算，且几乎不等待磁盘 I/O 或网络响应，那它就是。
CPU 核心数怎么准确获取
别依赖硬编码数字，始终用运行时探测：
-
Runtime.getRuntime().availableProcessors() 返回的是 JVM 可见的逻辑核心数（含超线程）；在容器或云环境里，它可能高于物理核数，也可能是被
cgroups限制后的值 - 若需物理核数，Linux 下可读
/sys/devices/system/cpu/online或用os.cpuCount(true)（如 JNA 库），但多数扫描场景用逻辑核数更合理 - 验证方式：启动后打印该值，并对比
top -H或htop中实际活跃线程数与 CPU 使用率是否趋近 100%（无明显空闲核）
最大线程数（maximumPoolSize）设多少才真对齐
对纯计算型扫描任务，最大线程数不宜超过核心数，否则上下文切换反成瓶颈：
- 推荐设为 availableProcessors() 或 availableProcessors() + 1
- +1 是为应对短暂缺页、TLB miss 或缓存未命中导致的微小阻塞，确保 CPU 始终有活可干
- 绝对避免设为
Integer.MAX_VALUE或远大于核心数（如 ×4、×8），这在扫描场景下只会拉低单任务吞吐、抬高延迟 - 若扫描逻辑中混有少量文件读取（如 mmap 后解析），仍属 CPU 主导，保持该上限不变，靠预读和零拷贝优化 IO，而非堆线程
配套参数必须同步收紧
只调最大线程数不够，其他参数松动会破坏核心对齐效果：
- corePoolSize = maximumPoolSize：让所有线程常驻，消除扩容/缩容抖动；扫描任务周期长、负载稳，无需弹性伸缩
- workQueue 选 SynchronousQueue 或小容量 ArrayBlockingQueue（如 16～64）：拒绝缓冲堆积，逼迫调用方控制提交节奏；用无界队列等于放弃背压，扫描变慢时任务照单全收，内存先爆
- keepAliveTime 设为 0L 或极短（如 100ms）：因 core == max，此参数实际不生效；但显式写明可防误配，也便于未来切模式
- 拒绝策略用 AbortPolicy 或自定义快速失败策略：扫描任务通常不可丢，但应立刻报错而非静默排队；CallerRunsPolicy 在此处意义不大，因无排队空间
上线前必须验证是否真的对齐
数值设对不等于效果到位，要靠观测确认硬件利用率真实匹配：
- 用
pidstat -t -p <pid> 1</pid>观察线程级 CPU%，看是否多数线程稳定在 80%~95%，无大量的“假忙”线程 - 监控
ThreadPoolExecutor.getActiveCount()和getCompletedTaskCount()，二者比值应长期接近 1.0（说明线程几乎不空闲） - 对比不同线程数下的总耗时：从 N→N+1，耗时下降应明显；N+1→N+2 若基本不变甚至上升，说明已到临界点
- 注意 GC 行为：线程数过多易引发频繁 young GC；若发现 GC 时间占比 >5%，优先降线程数而非调堆
