线程池性能问题源于参数与业务不匹配：无界队列掩盖瓶颈、线程数超CPU承载、拒绝策略致关键任务静默失败；应按任务类型（CPU/IO/混合）合理配置核心数、队列类型（推荐ArrayBlockingQueue）及拒绝策略。
Java线程池本身是为降低性能损耗而设计的，但配置不当反而会引入新问题。真正影响性能的不是“用了线程池”，而是参数与业务不匹配——比如用无界队列掩盖吞吐瓶颈、线程数远超CPU承载能力、拒绝策略导致关键任务静默失败。
线程创建/销毁开销被低估
虽然线程池复用线程，但当maximumPoolSize设得过大，且任务突发性强（如秒杀场景），线程池仍可能频繁扩容缩容。每个线程默认占用约1MB栈空间，大量线程还会加剧操作系统调度压力，引发高频上下文切换。
- 非核心线程空闲后需等待
keepAliveTime才销毁，该值设得过长（如10分钟）会导致资源长期闲置 - CPU密集型任务中，
corePoolSize超过Runtime.getRuntime().availableProcessors() + 1，多数线程实际在争抢CPU，徒增切换成本 - 避免依赖
Executors.newCachedThreadPool()——它使用SynchronousQueue+无上限maximumPoolSize，高并发下极易创建海量线程
任务队列选择直接决定系统韧性
队列不是缓存，而是背压信号的放大器。选错类型或容量，轻则响应延迟飙升，重则OOM崩溃。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
-
LinkedBlockingQueue若未指定容量（即默认Integer.MAX_VALUE），任务持续积压会快速耗尽堆内存 -
SynchronousQueue看似高效，实则要求maximumPoolSize必须足够大，否则任务提交直接触发拒绝策略 - 生产环境优先用
ArrayBlockingQueue：容量可估算——例如QPS=300、平均处理耗时150ms、允许排队不超过500ms，则队列大小 ≈ 300 × 0.15 × (1 + 0.2) ≈ 54，取整为60
拒绝策略暴露架构健壮性短板
拒绝不是异常，是系统主动限流的决策点。默认AbortPolicy抛出RejectedExecutionException，若上层未捕获，会导致调用方雪崩。
立即学习“Java免费学习笔记（深入）”；
- 支付、下单等关键链路：用自定义策略记录日志+触发告警，绝不静默丢弃
- 日志上报、消息通知等非核心任务：可用
DiscardPolicy，避免次要任务拖垮主流程 - 削峰类任务（如报表生成）：
CallerRunsPolicy让提交线程自己执行，天然降速，无需额外协调
混用任务类型会相互拖累
一个线程池同时处理数据库查询（IO密集）和图像压缩（CPU密集），会导致资源分配失衡：前者长期阻塞线程，后者却抢不到CPU。
- CPU密集型任务：设
corePoolSize = maximumPoolSize = CPU核心数 + 1，keepAliveTime = 0 - IO密集型任务：设
corePoolSize = CPU核心数 × 2，maximumPoolSize = CPU核心数 × 5，keepAliveTime = 30～60秒 - 混合型接口：拆分为两个独立线程池，由业务代码按任务特征路由，而非交给单一池“硬扛”
