线程池参数配置需在任务特征、系统资源和响应要求间求平衡：corePoolSize应贴近稳定并发量，CPU密集型设为CPU核数+1，IO密集型设为CPU核数×2～4；maximumPoolSize建议为corePoolSize的1.5～2倍并结合监控设定；workQueue优先选用有界队列如ArrayBlockingQueue，避免无界队列导致OOM；keepAliveTime设为30～60秒；拒绝策略推荐CallerRunsPolicy以实现自然降级。
线程池参数配置不是调大就快、调小就省，关键是在任务特征、系统资源和响应要求之间找平衡点。盲目增大核心线程数或队列容量，容易引发内存堆积、GC压力上升甚至 OOM；过度保守又会导致任务排队过长、吞吐下降。
核心线程数（corePoolSize）：匹配稳定并发压力
它代表常驻线程的下限，应贴近系统长期稳定的并发请求数。若业务有明显波峰波谷（如电商秒杀），可略低于峰值，靠允许创建临时线程（maxPoolSize）应对突发；若负载平稳（如后台定时任务），可设为 CPU 核心数 × (1～2)，避免上下文频繁切换。
- CPU 密集型任务：建议设为 CPU 核心数 + 1，留一个线程处理 I/O 或调度开销
- IO 密集型任务：可设为 CPU 核心数 × (2～4)，因为线程常阻塞，需更多线程维持吞吐
- 混合型任务：用压测数据反推——观察线程利用率（如 JMX 的
ActiveThreads）持续在 60%～80%，说明设置较合理
最大线程数（maximumPoolSize）与拒绝策略：守住资源底线
它决定了线程池能容忍的瞬时并发上限。若设得过高，大量线程争抢 CPU 和堆内存，反而降低整体吞吐；若过低，突发流量直接触发拒绝，影响可用性。
- 建议结合监控设定：比如应用平均 QPS 是 500，单个请求平均耗时 200ms，则理论并发约 100；将
maximumPoolSize设为 120～150，并预留缓冲空间 - 拒绝策略别只用
AbortPolicy（抛异常）。高可用场景推荐CallerRunsPolicy：让调用线程自己执行任务，自然降速，避免丢任务；或自定义策略，把任务写入 Kafka/DB 延后处理 - 注意：使用无界队列（如
LinkedBlockingQueue）时，maximumPoolSize实际失效，此时队列会无限堆积，极易 OOM——务必慎用
队列容量（workQueue）：控制缓冲深度，而非越大越好
队列是线程池的“缓冲区”，但不是保险柜。过大的队列会掩盖背压问题，让请求在内存中滞留过久，最终拖垮 JVM。
立即学习“Java免费学习笔记（深入）”；
- 优先选用有界队列：
ArrayBlockingQueue（固定大小、性能稳定）或SynchronousQueue（不存储任务，直接移交，适合配合maximumPoolSize快速扩容） - 容量参考公式：队列长度 ≈ 平均每秒任务数 × 平均处理时长 × 安全系数（1.5～2）。例如每秒 100 个任务、平均耗时 1s，队列设 150～200 即可
- 避免
DelayQueue或PriorityBlockingQueue用于通用业务线程池——它们增加锁竞争和 GC 开销，且排序逻辑可能干扰任务时效性
空闲线程存活时间（keepAliveTime）与线程工厂：精简资源生命周期
该参数只对超出 corePoolSize 的空闲线程生效。设得太短，频繁创建销毁线程带来开销；太长，则空闲线程占用内存和句柄资源。
- 生产环境建议设为 30～60 秒。短于 10 秒易震荡，长于 5 分钟则失去弹性意义
- 务必使用自定义
ThreadFactory：统一命名线程（如"biz-pool-%d"），便于日志追踪；同时设置setDaemon(true)，避免线程池关闭后 JVM 无法退出 - 考虑开启
allowCoreThreadTimeOut(true)：让所有线程（包括核心线程）都受keepAliveTime约束，适用于负载波动剧烈、希望彻底释放资源的场景
