java线程池性能优化关键在于threadpoolexecutor的四个核心参数：corepoolsize、maximumpoolsize、workqueue（类型+容量）、rejectedexecutionhandler，它们共同决定高并发下的响应能力、资源占用与故障退化方式。
Java线程池性能优化的关键不在堆参数或JVM调优，而在于ThreadPoolExecutor的四个核心行为参数：corePoolSize、maximumPoolSize、workQueue（类型+容量）、RejectedExecutionHandler。它们共同决定了系统在高并发下的响应能力、资源占用和故障退化方式。
按任务类型设定核心与最大线程数
同一台机器上不同任务对CPU和IO的消耗差异极大，混用线程池会相互拖累：
- CPU密集型任务（如加解密、图像转码、规则计算）： corePoolSize = CPU核心数 + 1；maximumPoolSize 通常与 corePoolSize 相同。 理由：线程过多引发频繁上下文切换，反而降低吞吐；keepAliveTime 可设为 0。
- IO密集型任务（如HTTP调用、数据库查询、文件上传）： corePoolSize = CPU核心数 × 2；maximumPoolSize = CPU核心数 × 4～5。 理由：线程常处于等待状态，提高并发数可提升CPU利用率；keepAliveTime 建议设为 30～60 秒。
- 混合型任务（如含本地计算+远程调用的接口）： 不建议统一配置，应拆分为两个独立线程池，分别按各自特征调参，并通过业务逻辑路由任务。
选对队列类型并控制容量
队列不是“越大越好”，它本质是缓冲区，错误选择会掩盖瓶颈甚至导致OOM：
- ArrayBlockingQueue（有界队列）：推荐用于生产环境。 容量需结合QPS、平均处理时长、可接受排队时长估算。例如：QPS=500，平均耗时200ms，允许最大排队1秒 → 队列容量 ≈ 500 × 0.2 = 100，再留20%余量 → 设为120。
- SynchronousQueue（无缓冲队列）：适合短平快、高吞吐场景（如消息分发）。 要求 maximumPoolSize 足够大，否则任务极易被拒绝；必须配合 CallerRunsPolicy 或自定义降级策略。
- LinkedBlockingQueue（默认无界）：慎用！若未指定容量，Integer.MAX_VALUE 容易撑爆堆内存。 若必须使用，务必显式传入合理容量（如1000），并监控 queue.size() 指标防止持续增长。
拒绝策略要匹配业务重要性
拒绝不是失败，而是系统主动限流的信号，策略选择体现容错设计水平：
- 关键链路（如支付、下单）：用 AbortPolicy 或自定义策略，立即抛异常并触发告警，避免脏数据或状态不一致。
- 非关键链路（如日志上报、异步通知）：可用 DiscardPolicy 或 DiscardOldestPolicy，静默丢弃，保障主流程不受影响。
- 削峰填谷场景（如定时报表生成）：推荐 CallerRunsPolicy，让提交线程自己执行任务，天然降低提交速率，避免雪崩。
- 进阶做法：自定义拒绝策略中记录被拒任务ID、入参摘要、时间戳，写入Kafka或本地磁盘，供后续人工补偿或自动重试。
配套动作不能少
光调参数不够，还需支撑机制确保效果落地：
- 用 NamedThreadFactory 给线程命名，如 “order-processor-thread-1”，便于JStack排查和监控平台识别。
- 定期采集 getActiveCount()、getQueue().size()、getCompletedTaskCount()，接入Prometheus+Grafana做趋势分析。
- 启用 allowCoreThreadTimeOut(true)（尤其IO型），让低峰期空闲核心线程也能回收，节省资源。
- 动态调整可行：运行时调用 setCorePoolSize() / setMaximumPoolSize() 实现弹性伸缩，但避免高频变更。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
