线程池参数需精准配置：核心线程数按cpu或io密集型合理设置；队列容量须依qps与耗时计算，禁用无界队列；最大线程数与存活时间协同控制弹性；拒绝策略应选型并自定义告警。
线程池参数不是“设完就完”的配置项，而是直接影响系统是否扛得住流量、会不会突然卡死、出问题时能不能快速恢复的关键开关。调得准，系统稳如磐石；调得偏，小流量都可能引发雪崩。
核心线程数配少了，CPU就闲着等任务
核心线程数（corePoolSize）是常驻线程的底线。它太小，意味着哪怕系统有空闲 CPU，也没线程去干活。
- CPU 密集型任务（如图像压缩、复杂计算）：设为 CPU 核心数或 +1 就够用。再多只会增加上下文切换开销，反而拖慢整体速度
- IO 密集型任务（如 HTTP 调用、数据库查询）：可设为 2–4 倍 CPU 核心数。因为线程大部分时间在等响应，多开几个能提升吞吐
- 常见误区：直接写死 10 或 20 —— 如果部署在 4 核机器上，8 个核心线程可能比 20 个更高效
队列容量没算清，延迟就悄悄变高
队列不是“越大越保险”，而是决定任务要排队多久的缓冲区。容量设错，表面不报错，实际已不可用。
- 用 LinkedBlockingQueue(1000)？先算算：峰值 QPS 是 500，单任务平均耗时 200ms → 理论积压量 ≈ 500 × 0.2 = 100 个。设 1000 容量，意味着任务可能排队 2 秒才开始执行
- 无界队列（如 new LinkedBlockingQueue()）绝对禁止在生产环境使用 —— 一旦下游变慢，队列无限膨胀，直接 OOM
- SynchronousQueue 适合短平快任务，但要求 maxPoolSize 必须合理，否则一压就拒绝，不适合业务主流程
最大线程数和存活时间共同控制弹性边界
maximumPoolSize 和 keepAliveTime 是一对搭档：一个管“最多能涨多少”，一个管“涨完后缩得多快”。
- maxPoolSize 过大（比如设成 200）：突发流量来了，线程数冲到上百，CPU 切换成本飙升，GC 压力剧增，响应时间反而跳升
- keepAliveTime 过长（如 600 秒）：流量退潮后，多余线程迟迟不退，占着内存和句柄，拖慢后续 GC，还可能干扰健康检查
- 实测建议：keepAliveTime 设为 10–30 秒，maxPoolSize 比 corePoolSize 高 2–4 倍（IO 密集），且不超过 CPU 核心数 × 8
拒绝策略选错，等于把故障藏进日志
拒绝不是失败，而是系统在说“我真处理不过来了”。策略选得不对，轻则丢数据，重则压垮调用方。
- AbortPolicy（默认）：直接抛异常 —— 适合关键链路，让上游立刻感知失败
- CallerRunsPolicy：由提交任务的线程自己执行 —— 能自然降速，但会阻塞业务线程，慎用于 Web 请求入口
- DiscardOldestPolicy：丢最老的任务 —— 适合实时性要求高的场景（如监控上报）
- 强烈建议：自定义拒绝策略，记录被拒任务 ID + 上游 traceId，并触发告警，而不是静默丢弃
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
