合理配置Java线程池参数可减少隐性CPU计算冗余：①core/maxPoolSize设为CPU核心数+1并禁用动态扩容，抑制上下文切换；②选用SynchronousQueue或有界ArrayBlockingQueue替代无界队列，避免假忙；③采用CallerRunsPolicy等拒绝策略实现反压，防止重试导致的重复计算；④开启allowCoreThreadTimeOut释放闲置资源。
Java 线程池参数本身不直接“减少 CPU 计算冗余”，但合理配置能避免因线程调度失当导致的无效 CPU 消耗，比如上下文切换开销、空转等待、线程争抢资源等——这些都属于隐性计算冗余。
关键在于：让 CPU 时间真正花在有效任务上，而不是浪费在线程管理或阻塞等待中。
corePoolSize 和 maximumPoolSize 控制线程规模，抑制上下文切换冗余
CPU 密集型任务（如加解密、数值计算）本身几乎不等待 IO，线程一旦启动就持续占用 CPU。
若线程数远超 CPU 核心数：
- 操作系统频繁调度线程，引发大量上下文切换；
- 每次切换需保存/恢复寄存器、缓存状态，消耗 CPU 周期；
- 实际并行度未提升，吞吐反而下降。
✅ 正确做法：
- 设
corePoolSize = CPU核心数 + 1（+1 是为了缓解偶尔的调度抖动）； -
maximumPoolSize通常与 core 一致，避免动态扩容； - 不设过高的 keepAliveTime（可设为 0），防止临时线程残留。
这样能保证线程数与物理并发能力匹配，把 CPU 几乎全留给计算，而不是调度。
立即学习“Java免费学习笔记（深入）”；
workQueue 类型影响任务堆积方式，减少“假忙”状态
当任务提交速率 > 处理速率时，队列选择决定 CPU 是否被“虚假占用”：
- 用无界
LinkedBlockingQueue：任务无限排队，线程池始终只用 core 线程处理，其余任务在队列里“躺平”——CPU 看似不忙，但内存持续增长，GC 压力上升，间接拖慢真实计算； - 用
SynchronousQueue：不缓存任务，必须立刻有空闲线程承接；若线程数不足，任务直接触发拒绝策略——这反而能暴露瓶颈，避免 CPU 被低效队列逻辑拖累； - 用有界
ArrayBlockingQueue：配合合理容量（如按 QPS × 平均耗时估算），让排队可控，既防 OOM，也避免线程长期空等队列。
✅ 关键逻辑：队列不是“缓冲性能”，而是“暴露压力”。选错队列会让 CPU 在不该忙的时候忙（比如 GC）、该忙的时候不敢忙（比如线程数卡死）。
RejectedExecutionHandler 决定过载时的行为，防止雪崩式冗余
当线程和队列都满时，拒绝策略决定系统如何退化：
- 默认
AbortPolicy：抛异常，调用方可能重试 → 更多任务涌入 → 冗余翻倍； -
CallerRunsPolicy：由提交线程自己执行任务 → 主动降速，反压上游，避免后台线程无序膨胀； - 自定义策略（如异步落库+延后重试）：把瞬时压力转化为可控的后续计算，避免 CPU 被突发流量反复打满又清空。
✅ 这本质是用“可控的延迟”替代“失控的重试”，减少重复计算、重复序列化、重复网络调用等典型冗余。
allowCoreThreadTimeOut 配合 keepAliveTime，释放闲置计算资源
默认 core 线程永驻，即使长时间没任务，也占着栈内存、线程句柄、TLS 缓存等。
对波动大的业务（如定时批处理），开启：
executor.allowCoreThreadTimeOut(true);
再设 keepAliveTime = 10~30 秒，能让低峰期自动缩容，释放 CPU 缓存亲和性干扰、减少调度器负担——这也是降低隐性冗余的一种方式。
