线程池配置需匹配算法类型：CPU密集型设为核心数+1，I/O密集型为核数×2~4并压测验证，混合型应分阶段建池；队列须有界（如ArrayBlockingQueue），容量按批量与并发批次设定；非核心线程keepAliveTime设10~30秒，maximumPoolSize略高于corePoolSize；拒绝策略首选CallerRunsPolicy配合业务降级。
处理复杂并行算法时，线程池不是“越大越好”，而是要让线程数、队列容量和存活策略匹配算法的计算特征与资源消耗模式。关键在于识别算法是 CPU 密集主导、I/O 等待显著，还是混合型，并据此动态约束并发粒度。
根据算法类型确定核心线程数
复杂并行算法常涉及多阶段计算（如分治、图遍历、矩阵分解），需区分其瓶颈所在：
- CPU 密集型（如蒙特卡洛模拟、FFT 变换、遗传算法迭代）：核心线程数建议设为 Runtime.getRuntime().availableProcessors() + 1。过多线程会加剧上下文切换，反而降低吞吐；+1 是为应对偶尔的系统调度抖动。
- I/O 密集型（如并行读取多个数据源、调用外部服务聚合结果）：核心线程数可设为 CPU 核数 × (1 + 平均阻塞时间 / 平均计算时间)，实践中常取 CPU 核数 × 2 ~ 4，但必须配合压测验证——例如 8 核机器配 16~32 核心线程，前提是任务确实存在长等待。
- 混合型（如机器学习训练：GPU 计算 + 数据加载 + 梯度同步）：不宜直接套公式。应拆解 pipeline 各阶段，对纯计算段用 CPU 密集策略，对数据加载段单独建 IO 专用线程池，避免相互抢占。
选用有界队列并设置合理容量
复杂算法的任务往往携带大量中间状态（如子图结构、临时数组），无界队列（如默认 LinkedBlockingQueue）极易引发 OOM。必须使用有界队列，并按实际负载预估缓冲深度：
- ArrayBlockingQueue 是首选：显式限定容量（如
new ArrayBlockingQueue(50)），能及时暴露背压，防止任务无限堆积。 - 容量设定参考：等于「单次批量提交的最大任务数 × 预期并发批次」。例如每次并行处理 10 个分片，系统支持 3 批重叠执行，则队列至少设为 30。
- 避免 SynchronousQueue：它不缓存任务，要求“立刻有空闲线程”，在复杂算法中因执行时间波动大，易频繁触发拒绝策略，稳定性差。
精细控制非核心线程生命周期
复杂算法运行周期长、阶段性明显（如初始化 → 并行计算 → 收敛判断 → 结果合并）。非核心线程应快速伸缩，而非长期驻留：
立即学习“Java免费学习笔记（深入）”；
- keepAliveTime 建议设为 10~30 秒（单位 TimeUnit.SECONDS），足够覆盖短时突发，又能在空闲后快速回收资源。
- 务必关闭 allowCoreThreadTimeOut：核心线程应始终保活，保障基础吞吐能力；仅对超出 corePoolSize 的线程启用超时销毁。
- maximumPoolSize 不宜远高于 corePoolSize。例如 core=8 时，max 可设为 12~16，而非 64——过大的弹性空间在长任务场景下只会增加内存占用与 GC 压力，而非提升性能。
拒绝策略选 CallerRunsPolicy + 业务降级
当线程池满载，说明系统已达真实处理边界。此时简单丢弃或抛异常会破坏算法完整性（如丢失某个分片结果）：
- 使用 CallerRunsPolicy：让提交任务的主线程（如算法协调器）同步执行一个任务，天然形成反压，减缓输入速率，避免雪崩。
- 在此基础上叠加业务逻辑降级：例如检测到连续多次触发拒绝，自动将后续任务从“细粒度并行”降级为“粗粒度批处理”，减少并发数，确保主流程不中断。
- 避免 AbortPolicy：在算法类场景中抛出 RejectedExecutionException 往往导致整个计算流程中止，恢复成本高。
