要让多线程扫表真正“对齐”cpu核心，关键不是堆线程数，而是让每个核心持续有活干、不空转、不抢资源，需从任务拆分、线程池参数、数据局部性三方面协同设计。

要让多线程扫表真正“对齐”CPU核心，关键不是堆线程数，而是让每个核心持续有活干、不空转、不抢资源。这需要从任务拆分、线程池参数、数据局部性三方面协同设计，而不是简单套用availableProcessors()。

任务必须可分割且低耦合

扫表类任务天然适合分治，但前提是数据能被安全切片。常见错误是直接按主键ID范围硬切，结果导致热点倾斜或跨事务不一致。

• 优先按物理存储结构切分：比如MySQL按分表/分库逻辑、Elasticsearch按shard、HBase按region，避免跨节点IO争抢
• 单个子任务粒度控制在100ms–2s内：太小则调度开销压过收益，太大则无法动态负载均衡
• 禁用全局共享状态：如共用一个计数器、缓存Map或未加锁的List，改用LongAdder或线程本地累加后合并

线程池参数需按IO/CPU混合特征反推

扫表本质是IO密集型（查库、网络传输），但中间可能夹杂解析、校验等CPU操作。不能只看CPU核数，要看实际瓶颈在哪。

• corePoolSize设为2 × CPU核心数起步，例如8核机器设16；这是为了覆盖数据库连接等待期，让CPU不闲着
• maximumPoolSize不超过corePoolSize × 2，防止创建过多连接拖垮DB（如MySQL默认最大连接数151）
• 队列用有界阻塞队列，容量建议设为corePoolSize × 3，避免无界队列吃光内存又掩盖吞吐瓶颈
• keepAliveTime设为30秒，配合allowCoreThreadTimeOut(false)，保证基础并发能力稳定

数据访问模式要贴合缓存行与NUMA架构

即使线程数匹配核心数，若数据在内存中随机跳读，L3缓存命中率暴跌，多核优势会打折扣。

• 扫描时尽量顺序读取：用SELECT ... ORDER BY id替代无序IN查询，减少页跳跃
• 批量拉取而非单条：一次查100–500条，降低网络往返和JDBC驱动开销
• 避免伪共享：不同线程更新相邻字段（如数组连续索引）时，用@Contended隔离或填充字节
• 大对象提前预热：首次扫描前用小批量触发JIT编译和GC晋升，避免高峰期卡顿

运行时需监控真实对齐效果

参数设得再合理，没验证就是纸上谈兵。重点看三个指标是否同步改善：

• CPU user% 持续高于70%，sys%低于15% → 核心利用率达标
• 线程池getActiveCount()稳定在corePoolSize附近波动，极少触达maxPoolSize → 负载均衡良好
• 数据库慢查询日志中，对应扫表SQL的Rows_examined / Rows_sent比值趋近1 → 数据拉取效率高，无无效扫描