java线程池需平衡响应与吞吐：核心线程按任务类型设定（cpu密集型为cpu数+1，io密集型为2–4倍cpu数），队列用有界arrayblockingqueue（容量=峰值qps×平均耗时×1.5），最大线程数设为核心数2–4倍且≤cpu×8，keepalivetime建议60秒，拒绝策略优选callerrunspolicy，线程工厂须自定义命名。
要让Java线程池在响应速度和吞吐量之间取得平衡，关键不是堆线程数，而是让每个参数都“各司其职”——核心线程稳住日常负载，队列缓冲突发流量，最大线程兜底高峰，拒绝策略守住系统底线。
核心线程数：按任务类型精准设定
它决定线程池的“常驻战斗力”，设高了浪费资源，设低了压不住日常请求。
- CPU密集型任务（如加解密、图像处理）：设为 CPU核心数 + 1。多一个线程可应对偶尔的IO等待，避免CPU空转
- IO密集型任务（如HTTP调用、数据库查询）：设为 2 × CPU核心数 起步，若IO等待时间长（比如平均300ms），可逐步上调至3–4倍，用线程“掩盖”等待
- 混合型场景（如电商下单：含校验、库存、支付）：建议先按IO密集型配置，再通过压测观察CPU使用率和平均响应时间，微调至CPU利用率稳定在70%–85%
任务队列：有界优先，容量需可推演
无界队列（如默认的LinkedBlockingQueue）看似安全，实则会把问题藏起来——任务越积越多，延迟飙升，最终OOM。必须用有界队列，并让容量有意义。
- ArrayBlockingQueue 是首选：容量明确，能触发拒绝策略，便于监控告警。容量建议 = 预估峰值QPS × 平均任务处理时长（秒）× 1.5（留缓冲）
- 例如：接口QPS峰值100，平均耗时200ms → 队列容量 ≈ 100 × 0.2 × 1.5 = 30，取整为32或64
- 慎用SynchronousQueue：适合短平快任务（如日志落盘），但要求线程创建能力极强；若maximumPoolSize没设够，任务直接被拒绝
最大线程数与存活时间：弹性伸缩不靠猜
它不是固定值，而是应对尖峰的“临时增援部队”。设太死，扛不住大促；设太松，上下文切换拖垮性能。
- maximumPoolSize 建议设为 corePoolSize 的 2–3倍（IO密集型可到4倍），上限不超过CPU核心数×8，防止调度开销反超收益
- keepAliveTime 推荐 60秒：足够回收短时激增的线程，又不会因抖动频繁启停；单位务必与传入的TimeUnit一致（别写60L却用MILLISECONDS）
- 开启 allowCoreThreadTimeOut(true) 可让核心线程也参与回收（需配合非零keepAliveTime），适合流量波动极大的后台服务
拒绝策略与线程工厂：稳定性最后一道防线
当队列满+线程满，拒绝不是失败，而是主动控流。同时，可读的线程名是定位问题的起点。
- 放弃默认AbortPolicy（抛RejectedExecutionException）：生产环境容易导致上游重试雪崩
- 推荐CallerRunsPolicy：由调用方线程执行任务，天然限流，且不丢任务；若需降级，可自定义Handler记录日志+发告警+写入本地磁盘队列异步重试
- 务必使用自定义ThreadFactory：给线程命名（如“order-processor-thread-1”），方便JVM线程dump分析、Prometheus监控打标
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
