线程池参数配置是sla的底层兑现机制，需紧扣响应时间（如p99≤200ms）和拒绝率（如
线程池参数配置不是调参游戏，而是 SLA 的底层兑现机制。它直接决定任务能否在约定时间内完成、失败率是否可控、系统在峰值下是否崩溃。关键不在于堆数字，而在于让每个参数服务于明确的 SLA 指标——比如“99% 的订单处理任务在 200ms 内完成”或“拒绝率长期低于 0.1%”。
紧扣 SLA 目标反推核心参数
先明确你的硬性指标，再倒推参数边界：
- 响应时间目标（如 P99 ≤ 200ms）：意味着不能让任务在队列里长时间等待。这时 workQueue 不能选无界 LinkedBlockingQueue，而应设为有界（如 ArrayBlockingQueue(500)），配合合理的 corePoolSize，确保大部分任务能立刻获得线程执行，而非排队。
- 最大允许拒绝率（如 ：说明 handler 不能用 DiscardPolicy 这种静默丢弃策略。AbortPolicy（抛异常）配合监控告警，或 CallerRunsPolicy（由调用方降速），才能把过载信号及时反馈给上游，触发限流或扩容。
- 资源水位约束（如 CPU 使用率 ≤ 75%）：限制 maximumPoolSize 上限。例如 8 核机器，IO 密集型任务最大设到 32 已足够，再往上只会加剧上下文切换，拖慢整体响应，反而破坏 SLA。
按任务类型匹配队列与线程数逻辑
同一套参数无法适配所有业务，SLA 保障必须区分任务性质：
- CPU 密集型（如图像压缩、风控计算）：线程过多等于内耗。corePoolSize 设为 CPU 核数 + 1（如 8 核 → 9），maximumPoolSize 控制在核数 × 2 内；workQueue 用 SynchronousQueue 或小容量 ArrayBlockingQueue（如 100），逼迫线程池优先扩容而非堆积任务。
- IO 密集型（如数据库查询、HTTP 调用）：线程常阻塞，需更多并发能力。corePoolSize 可设为 2–4 × CPU 核数（如 8 核 → 16~32），但 workQueue 必须有界（如 LinkedBlockingQueue(1000)），否则一次慢 SQL 就可能把几万任务压进内存，引发 OOM，SLA 彻底失效。
空闲控制与拒绝策略是 SLA 的安全阀
keepAliveTime 和 handler 不是兜底选项，而是主动防御设计：
- keepAliveTime 要配合负载波动：促销期间流量激增，非核心线程可多留一会儿（如 300 秒）；凌晨低峰期则快速回收（如 60 秒），避免空转消耗内存和 GC 压力，维持基础响应能力。
- handler 必须可观测、可联动：用 AbortPolicy 时，捕获 RejectedExecutionException 后立即上报 Prometheus 指标并触发企业微信告警；用 CallerRunsPolicy 时，记录日志并统计调用方线程执行耗时——这本身就是 SLA 降级的明确信号，需同步通知网关层启动熔断。
线程工厂与监控是 SLA 追溯的基础设施
没有命名和指标，SLA 问题就无法定位：
- threadFactory 必须自定义命名：如 "order-processor-worker-%d"。当线程数飙升或某类任务延迟突增时，Jstack 或 Arthas 能一眼锁定是哪个业务线程池出了问题，而不是在一堆 pool-1-thread-xx 中大海捞针。
- 暴露关键运行指标：活跃线程数、队列长度、已拒绝任务数、历史最大池大小——这些不是锦上添花，而是判断 SLA 是否被击穿的实时依据。配合 Hippo4j 或自建 Micrometer Exporter，让 Grafana 看板直接显示“当前订单队列深度：482（阈值 500）”，比任何日志都直观。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
