线程池需按任务行为构建“三级响应链”：核心线程兜底日常，队列缓冲脉冲，最大线程应对尖峰；核心数依CPU/IO/混合型任务分别设定；队列须有界，推荐ArrayBlockingQueue并按QPS×耗时×1.5推演容量；最大线程数设为core的2–4倍且≤CPU×8；拒绝策略首选CallerRunsPolicy或自定义降级。
要让线程池在高并发下稳定输出最大吞吐量，核心线程数、最大线程数和队列容量不是各自调优，而是按任务行为形成“三级响应链”：核心线程兜底日常，队列缓冲短时脉冲，最大线程应对尖峰突袭。三者失配，轻则延迟飙升，重则拒绝激增或内存溢出。
核心线程数：按任务类型定“常驻兵力”
它决定冷启动响应速度和基础承载力，设错会导致资源浪费或任务积压。
-
CPU 密集型（如加解密、实时计算）：设为
Runtime.getRuntime().availableProcessors() + 1。多一个线程可覆盖 GC 或锁阻塞带来的空转，避免 CPU 利用率跌穿 70% -
IO 密集型（如 HTTP 调用、DB 查询）：按公式
cpuCount × (1 + 平均等待时间 / 平均执行时间)估算，实测常用 4–16；若使用异步 IO（Netty/CompletableFuture），可降至 2–4 - 混合型（如下单流程含校验+库存+支付）：不建议统一配置，应拆分——快计算走小池（core=2–4），慢 IO 走独立大池（core=8–16），否则慢任务会阻塞整个池
队列容量：有界为刚，容量可推演
无界队列（如默认 LinkedBlockingQueue）是生产事故高发区，必须用有界队列，并让容量有意义。
- ArrayBlockingQueue 是首选：容量 = 预估峰值 QPS × 平均处理耗时（秒）× 1.5（安全缓冲）。例如 QPS 峰值 200、平均耗时 150ms → 容量 ≈ 200 × 0.15 × 1.5 = 45，取整为 64
-
SynchronousQueue 适合短平快场景：如日志落盘、事件广播，它不存任务，靠线程“手递手”交接，要求
maximumPoolSize充足且扩容灵敏 - 避免 LinkedBlockingQueue 不设容量：默认无界，任务持续堆积最终触发 OOM，即使设了容量也建议显式声明，别依赖默认值
最大线程数：弹性上限，防过载不防浪费
它不是用来长期运行的，而是给突发流量留的“临时增援”，设太高反而因上下文切换拖垮性能。
立即学习“Java免费学习笔记（深入）”；
- 推荐设为
corePoolSize 的 2–4 倍，IO 密集型可取上限，CPU 密集型建议 ≤ 2 倍 - 硬性上限建议 ≤
CPU 核心数 × 8，超过后线程争抢调度器、锁和内存带宽，吞吐不升反降 - 配合
setAllowCoreThreadTimeOut(true)和合理keepAliveTime（如 60 秒），让非核心线程空闲后回收，降低容器化部署中 Pod OOM 风险
拒绝策略：守住系统底线的最后一道闸
当队列满且线程已达最大值，拒绝策略不是补救，而是主动限流信号。
- 别用 AbortPolicy：直接抛异常，易引发上游级联失败
- CallerRunsPolicy 更稳妥：由提交线程自己执行任务，天然降速，避免雪崩
- 自定义策略更优：记录日志 + 返回降级结果（如缓存值、空响应、排队中提示），把拒绝变成可感知、可运营的行为
