关键在于打破“任务排队等待”这一延迟主因。应使用有界队列（如arrayblockingqueue(100)）、按任务类型设置核心线程数（io密集型为cpu核数×2～4，cpu密集型为cpu核数+1）、善用synchronousqueue实现即来即执行，并配置合理拒绝策略（如callerrunspolicy或discardoldestpolicy）以主动反馈过载压力。
关键在于打破“任务排队等待”这个延迟主因。线程池默认优先把任务塞进队列，而不是启动新线程——如果队列太大、核心线程太少，请求就会在队列里积压，响应时间直接拉长。
控制队列容量，避免任务无限堆积
无界队列（如默认的 LinkedBlockingQueue()）是延迟陷阱。它会让所有超出核心线程数的任务无条件入队，哪怕系统已明显处理不过来。队列越深，后面的任务等待时间越长，P99延迟飙升。
- 改用有界队列，例如 ArrayBlockingQueue(100) 或 LinkedBlockingQueue(200)
- 容量不是拍脑袋定的：按业务峰值QPS × 平均任务耗时 × 安全系数（建议1.5~2）粗略估算
- 配合拒绝策略使用，让系统在过载时“有感知”而非“默默卡死”
按任务类型配核心线程数，不让CPU或IO空转
线程数太少，资源闲置；太多，上下文切换反拖慢速度。必须区分任务性质：
- IO密集型（含数据库、RPC、HTTP调用）：核心线程数设为 CPU核心数 × 2～4。比如8核机器，配16～32个核心线程，掩盖等待开销
- CPU密集型（纯计算、加解密、图像处理）：核心线程数设为 CPU核心数 + 1，避免线程争抢CPU导致频繁切换
- 可通过 Runtime.getRuntime().availableProcessors() 动态获取核心数，提升环境适应性
善用SynchronousQueue，让任务“即来即执行”
当追求低延迟且任务处理节奏较稳时，SynchronousQueue 是更激进但有效的选择。它不存储任务，每个提交都必须立刻匹配到空闲线程，否则触发扩容逻辑。
- 搭配 corePoolSize 和 maximumPoolSize 合理差值（如 8 / 16），可快速伸缩应对突发
- 避免了队列缓冲带来的固有延迟，适合下单、支付等对响应时间敏感的链路
- 注意：需配套监控队列拒绝率，防止突发流量击穿线程上限
选对拒绝策略，把压力反馈给上游
拒绝不是失败，而是主动限流信号。默认的 AbortPolicy 直接抛异常，前端可能只看到500，无法感知是后端过载。
- CallerRunsPolicy：让调用方线程自己执行任务。天然降速，且不丢失请求，适合非核心链路
- DiscardOldestPolicy：丢弃队列中最老任务。适用于实时性要求高的场景（如行情推送）
- 自定义策略记录日志或上报指标，为容量评估和告警提供依据
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
