线程池参数配置需从任务排队、执行、资源争抢三环节评估响应时间：大容量队列导致排队时间不可控，P95响应飙升；SynchronousQueue可减少排队但需合理设置maximumPoolSize；corePoolSize与maximumPoolSize应匹配任务类型（CPU型≈CPU核数+1，IO型为2–4倍）；keepAliveTime设为10–30秒利于IO型服务快速回收线程；拒绝率>0%表明系统过载，需检查队列容量、maximumPoolSize及拒绝策略。
线程池参数配置对响应时间的影响，不能只看平均耗时，得结合任务排队、执行、资源争抢三个环节来评估。关键在于识别“延迟从哪来”——是等线程，还是等执行，还是等外部依赖。
看任务排队时间：队列类型和容量决定等待起点
响应时间 = 排队时间 + 执行时间。如果用的是 LinkedBlockingQueue(10000) 这类大容量有界队列，或更危险的无界队列，任务会优先进队列，而不是触发扩容。结果就是高并发下大量任务在队列里“躺平”，P95响应时间可能飙升数秒，而线程利用率却很低（比如长期低于30%）。实际案例中，把队列从10000缩到100，下单接口P99从5秒降到200ms，本质就是砍掉了无效排队。
- 队列过大 → 排队时间不可控，响应长尾明显
- 改用 SynchronousQueue → 任务不排队，直接尝试创建新线程（需配合合理 maximumPoolSize），适合低延迟敏感场景
- 队列已满但 maximumPoolSize 没起作用 → 检查是否 corePoolSize == maximumPoolSize，导致根本不会扩容
看线程是否够用：核心与最大线程数决定并发承载力
corePoolSize 太小，就像只开2个收银台却排了100人；maximumPoolSize 太大，又像硬塞50人进10平米小店，互相推搡反而更慢。真实影响体现在两个指标上：
- 线程利用率持续低于50%：说明线程闲置，可能是 corePoolSize 过大，或任务本身执行太慢（比如IO阻塞未优化）
- 线程利用率长期100% + 队列积压：大概率是 corePoolSize 不足，或 maximumPoolSize 设得太保守，没给弹性空间
- CPU密集型任务建议 corePoolSize = CPU核心数 + 1；IO密集型可设为 2–4 倍，但必须配合监控验证，不能只套公式
看空闲资源回收：keepAliveTime 影响突发流量退潮后的恢复速度
这个参数不直接影响单次响应，但决定系统“喘气”的快慢。比如IO调用为主的微服务，keepAliveTime 从60秒降到10秒后，突发流量退去，线程数从232回落到48只需23秒（原来要112秒），后续请求就能更快获得空闲线程，避免因残留线程占着内存拖慢GC、间接拉高延迟。
立即学习“Java免费学习笔记（深入）”；
- keepAliveTime 过长 → 流量低谷期仍维持大量空闲线程，浪费内存，干扰GC
- keepAliveTime 过短 → 频繁创建销毁线程，增加调度开销，尤其在中等波动流量下反而抬高平均延迟
- 10–30秒是多数IO型服务的实测有效窗口，比默认60秒更贴近真实业务节奏
看拒绝是否发生：拒绝率是系统过载的明确信号
拒绝率 > 0%，说明已有任务被丢弃或回退，这不是“性能好”，而是“撑不住了”。常见诱因包括：
- workQueue 容量设得太大，掩盖了实际处理瓶颈
- maximumPoolSize 设置不足，队列一满就拒绝，但用户感知是“偶发超时”
- 拒绝策略选了 AbortPolicy（直接抛异常），上游没兜底，造成雪崩；换成 CallerRunsPolicy 可让调用线程自己执行，自然限流，延迟虽升但可控
