Java线程池无任务级负载均衡能力，需通过合理设置核心线程数、使用有界队列暴露瓶颈、善用拒绝策略调控及必要时切换ForkJoinPool实现负载均衡。
Java 线程池本身不提供任务级负载均衡能力，它默认按“先到先服务+空闲线程优先执行”方式分发任务，无法感知各线程当前负载。所谓“让任务均匀落到每个线程上”，不能靠改队列类型或加个自定义 BlockingQueue 实现——因为 ThreadPoolExecutor 的 execute() 和 getTask() 逻辑决定了：任务入队是被动缓冲，取任务是线程主动拉取，队列不参与调度决策。
真正影响多任务间实际负载分布的，是三个底层机制的配合效果，优化方向也应围绕它们展开：
核心线程数与任务特性匹配，减少“忙闲不均”根源
线程长期空闲或持续满载，往往不是队列问题，而是核心线程数设置脱离了任务真实行为：
- CPU 密集型（如计算、加解密）：设
corePoolSize = CPU核心数 + 1。多一个线程可覆盖偶尔的缓存未命中或轻量 IO，避免 CPU 周期浪费 - IO 密集型（如 HTTP 调用、DB 查询）：设
corePoolSize = CPU核心数 × 2～4。用线程数量“掩盖”等待时间，使 CPU 尽可能有活干 - 混合型（如下单流程含校验+库存+支付）：先按 IO 密集配置，再通过压测观察
getActiveCount()与getLargestPoolSize()，目标是 CPU 利用率稳定在 70%–85%，且平均响应时间无明显拐点
用有界队列 + 合理容量，暴露真实瓶颈而非掩盖
无界队列（如 new LinkedBlockingQueue()）会让任务无限堆积，表面看“没拒绝”，实则延迟飙升、内存暴涨，监控看到的是“所有线程都忙，但队列还在涨”——这不是负载不均，是系统已失控。
正确做法：
- 选用
ArrayBlockingQueue，容量按公式估算：QPS峰值 × 平均处理时长（秒）× 1.5 - 例如：接口峰值 200 QPS，平均耗时 150ms → 容量 ≈ 200 × 0.15 × 1.5 = 45，取 64
- 队列满后触发拒绝策略，才能让后续调控（如降级、限流、告警）真正起作用
拒绝策略作为负载调节入口，实现轻量级主动干预
当队列满 + 线程满时，RejectedExecutionHandler 是唯一可控的“任务再分发”时机：
- 放弃
AbortPolicy（直接抛异常），改用CallerRunsPolicy：让提交线程自己执行任务，天然减速提交速率，给系统喘息时间 - 若需更精细控制（如按线程当前活跃任务数选目标），可在
rejectedExecution()中：- 维护一个
AtomicIntegerArray记录每个 Worker 的实时任务数（需反射获取 Worker 列表，生产环境慎用） - 找最小值索引，尝试唤醒对应线程并投递任务（依赖
Thread.interrupt()和共享安全队列）
- 维护一个
- 更稳妥的替代方案：直接换用
ForkJoinPool。它内置工作窃取（work-stealing），空闲线程自动从繁忙线程的双端队列尾部“偷”任务，对耗时不均的任务（如 10ms 和 2s 混合）效果显著，无需额外编码
不复杂但容易忽略：负载均衡不是堆参数，而是让线程池各组件各司其职——核心线程兜住基线流量，有界队列暴露压力水位，拒绝策略守住底线，必要时用 ForkJoinPool 替代。
