线程池配置关键在于任务类型与系统承载力的匹配：cpu密集型宜用synchronousqueue和cpu核数+1线程；i/o密集型可设core=cpu×2、max=cpu×8～10、队列20～50；混合型按“平均耗时×峰值tps÷1000”估算队列，推荐有界队列并监控活跃线程与队列堆积。
线程池资源竞争，本质是任务提交速度、线程处理能力与缓冲空间三者失衡的结果。队列容量设太大，任务堆积吃内存；线程上限设太高，上下文切换拖垮CPU；两者配得不匹配，轻则响应变慢，重则OOM或请求超时。关键不在“多”或“少”，而在“匹配任务节奏和系统承载力”。
先看任务类型，再定队列和线程关系
队列不是越大越好，线程也不是越多越快——它们是一对需要协同的参数。
- CPU密集型任务（如数值计算、图像编码）：线程基本满负荷运转，几乎不等待。此时应缩小队列、收紧线程上限。推荐用 SynchronousQueue（容量为0），让任务直接交由空闲线程执行；corePoolSize 和 maximumPoolSize 都设为 CPU 核数 + 1，避免排队和额外线程开销。
- I/O密集型任务（如HTTP调用、DB查询）：线程常处于阻塞等待状态，CPU有空闲。这时可适度放宽线程上限，但队列不宜过大。例如 corePoolSize = CPU × 2，maximumPoolSize = CPU × 8～10，队列容量控制在 20～50。任务进来优先入队，队满再扩容线程，防止突发流量瞬间打爆内存。
- 混合型任务（如订单创建含校验+调用+写库）：建议按“平均处理时间 × 峰值TPS ÷ 1000”粗算队列容量，线程数取中间值（如 core = CPU × 1.5，max = CPU × 3），后续靠压测微调。
有界队列是底线，无界队列要慎用
LinkedBlockingQueue 默认无界（Integer.MAX_VALUE），表面省心，实则危险。一旦下游处理变慢，任务持续积压，JVM堆内存会快速耗尽。
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 生产环境强烈推荐使用有界队列，如 ArrayBlockingQueue 或带容量限制的 LinkedBlockingQueue。
- 队列容量不是拍脑袋定的。可参考公式：队列大小 ≈ 平均每秒任务数 × 平均单任务耗时（毫秒）÷ 1000。例如 TPS=200、平均耗时60ms → 理论缓冲约12个任务，实际可设为 32 或 64，留出余量。
- 若选用 SynchronousQueue，意味着“不缓存”，所有任务必须立刻被线程消费，此时 maximumPoolSize 必须足够大，否则极易触发拒绝策略。
线程上限要配合监控动态看住
maximumPoolSize 不是静态安全阀，而是动态调节的边界。它和队列一起构成“缓冲-扩容”双机制，但前提是能看清运行时状态。
- 重点关注两个指标：活跃线程数（getActiveCount）是否长期接近 maximumPoolSize，以及队列堆积量（getQueue().size()）是否持续高于容量的 70%。
- 如果活跃线程总在高位、队列却很空 → 说明线程数偏少或任务太重，考虑提升 corePoolSize 或优化单任务耗时。
- 如果队列持续积压、活跃线程却很低 → 说明线程处理不过来（可能是阻塞或慢SQL），而非并发不够，此时加线程无效，需查瓶颈点。
- Spring Boot 项目可集成 Actuator + Prometheus，暴露 ThreadPoolTaskExecutor 的 metrics，实现阈值告警与自动扩缩（如通过定时任务调整 setCorePoolSize）。
拒绝策略选得准，比硬扛更稳
当队列满 + 线程达上限，拒绝策略就是最后一道防线。选错策略，可能把雪崩藏在平静之下。
- AbortPolicy（默认）：直接抛 RejectedExecutionException。适合非核心任务，便于快速暴露配置问题，但线上支付、下单类场景不能接受丢任务。
- CallerRunsPolicy：让提交任务的线程自己执行。能自然降速，缓解压力，但若调用方是Web容器线程（如Tomcat），会导致请求线程被占住，影响整体吞吐——慎用于高并发入口。
- DiscardPolicy：静默丢弃。适用于日志采集、埋点等允许丢失的场景。
- 关键业务建议自定义策略：记录拒绝日志 + 上报监控 + 触发熔断或降级，把“拒绝”变成可观察、可响应的动作。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
