线程池参数配置需四者协同匹配任务特征：CPU密集型设corePoolSize=maximumPoolSize=CPU核数+1、SynchronousQueue；IO密集型用ArrayBlockingQueue（容量20~50）、core=2×CPU、max=8~10×CPU；混合型依TPS与耗时估算队列，必用有界队列并配自定义拒绝策略及运行时监控。
线程池参数配置不当，是引发资源竞争的常见根源。关键不在于堆叠线程或扩大队列，而在于让 corePoolSize、maximumPoolSize、队列类型与容量、拒绝策略 四者形成协同机制，匹配实际任务特征与系统承载边界。
按任务类型定线程与队列关系
任务行为决定资源调度逻辑，不能一概而论：
-
CPU 密集型任务（如加解密、图像处理）：线程几乎无等待，满负荷运行。应设
corePoolSize = maximumPoolSize = CPU 核数 + 1，队列用SynchronousQueue（容量为 0），避免排队和额外线程开销。 -
I/O 密集型任务（如 HTTP 调用、数据库查询）：线程常阻塞，CPU 有空闲。可设
corePoolSize = CPU × 2，maximumPoolSize = CPU × 8～10，队列选ArrayBlockingQueue，容量控制在 20～50，防止突发流量压垮内存。 -
混合型任务（如订单创建含校验+调用+写库）：按公式粗估队列大小：
平均 TPS × 平均耗时（ms）÷ 1000；例如 TPS=200、耗时 60ms → 理论缓冲约 12，实际设 32 或 64；线程数取中间值，如core = CPU × 1.5，max = CPU × 3，后续靠压测调优。
必须用有界队列，禁用无界默认
LinkedBlockingQueue 默认容量为 Integer.MAX_VALUE，表面“省心”，实则危险——下游变慢时任务持续堆积，JVM 堆内存迅速耗尽，触发 OOM。
- 生产环境只用有界队列：
ArrayBlockingQueue或显式指定容量的LinkedBlockingQueue(100)。 - 队列容量不是拍脑袋定的，需结合业务节奏：若任务平均 50ms 完成、峰值每秒进 100 个，则理论缓冲需求为
100 × 50 ÷ 1000 = 5，留 3～5 倍余量，设为 16 或 32 更稳妥。 - 选用
SynchronousQueue时，意味着“零缓存”，所有任务必须立刻被线程消费，此时maximumPoolSize必须足够大，否则极易触发拒绝策略。
拒绝策略要兜底，别依赖 AbortPolicy
默认 AbortPolicy 直接抛异常，可能让上游请求失败；更合理的做法是：
立即学习“Java免费学习笔记（深入）”；
-
CallerRunsPolicy：由提交任务的线程自己执行，天然削峰，适合对延迟不敏感但需保命的场景。 -
DiscardOldestPolicy：丢弃队列头任务，适用于任务有时效性（如实时行情推送）。 - 自定义策略：记录日志 + 上报监控，便于事后分析饱和原因，而非静默丢弃。
配完必须监控活跃线程与队列堆积
参数配置只是起点，运行时状态才是真实反馈：
- 持续观察
getActiveCount()：若长期接近maximumPoolSize，说明线程上限偏低或任务处理慢，需优化逻辑或扩容。 - 定期采样
getQueue().size()：若持续增长且不下降，表明消费能力跟不上提交速度，要么调优下游，要么收紧上游流量。 - 配合 JVM GC 和 CPU 使用率看：若线程数高但 CPU 利用率低，大概率是 I/O 阻塞；若 CPU 满载但活跃线程不多，可能是锁争用或单点瓶颈。
