线程池参数需依任务类型、资源瓶颈和响应要求动态调整：计算型任务corePoolSize≈CPU核数，I/O型可设2倍及以上；keepAliveTime推荐I/O型60秒、计算型10~30秒；生产环境优先选用有界队列并合理估算容量；拒绝策略应避免AbortPolicy和DiscardPolicy，推荐CallerRunsPolicy或自定义熔断策略。
线程池参数不是套公式就能用的，得看你的任务类型、资源瓶颈和响应要求。盲目设大核心线程数或堆满队列，反而引发 OOM 或吞吐下降。
corePoolSize 和 maximumPoolSize 怎么定
这两个值决定线程“常驻”和“弹性扩容”的边界。关键不是 CPU 核数乘几倍，而是任务阻塞程度：
- 纯计算型任务（如加解密、图像处理）：建议
corePoolSize≈ CPU 核数，maximumPoolSize可等于corePoolSize，避免上下文切换开销 - I/O 密集型任务（如 HTTP 调用、DB 查询）：
corePoolSize可设为2 × CPU 核数或更高，因为线程常在等待；maximumPoolSize要结合下游承载力——比如调第三方 API 限流 100 QPS，那线程数再高也无意义 - 混合型任务：观察 GC 日志和
Thread.getState()分布，如果大量线程长期处于WAITING或TIMED_WAITING，说明 I/O 等待多，可适当提高corePoolSize
keepAliveTime 设太短或太长会怎样
keepAliveTime 控制空闲线程存活时长，只对 > corePoolSize 的线程生效。设错会导致两种典型问题：
- 设太短（如 10ms）：高峰过后线程频繁销毁重建，增加 JVM 创建线程开销，可能触发
java.lang.OutOfMemoryError: unable to create new native thread - 设太长（如 60 分钟）：低峰期仍保留大量闲置线程，浪费内存和句柄资源；尤其在容器环境（如 Kubernetes），可能被 OOMKilled
- 推荐值：I/O 型任务设 60 秒；计算型任务可设 10~30 秒；若使用
allowCoreThreadTimeOut(true)，则所有线程都受此影响，此时建议统一设 60 秒并配合监控
BlockingQueue 选哪种？ArrayBlockingQueue 还是 LinkedBlockingQueue？
队列类型直接影响拒绝策略触发时机和内存稳定性：
立即学习“Java免费学习笔记（深入）”；
-
ArrayBlockingQueue：有界队列，容量固定。适合明确吞吐上限的场景，能防止请求无限堆积导致 OOM；但容量设小了容易频繁触发RejectedExecutionException -
LinkedBlockingQueue（无参构造）：默认容量为Integer.MAX_VALUE，等效于无界队列。看似“不会拒绝”，实则把压力转嫁给堆内存——任务对象持续入队，GC 压力飙升，最终java.lang.OutOfMemoryError: Java heap space - 生产环境强烈建议用有界队列，容量根据平均单任务耗时 × 目标吞吐量 × 安全冗余（如 1.5 倍）估算；例如平均处理 200ms，目标 100 QPS，则队列至少预留
100 × 0.2 × 1.5 ≈ 30容量
拒绝策略（RejectedExecutionHandler）不能只用 AbortPolicy
默认的 AbortPolicy 直接抛异常，前端看到 500，监控告警炸锅。真实系统需要更务实的应对：
-
CallerRunsPolicy：让提交任务的线程自己执行，能自然降速，适合突发流量但允许延迟的场景；但要注意——若调用方是 Tomcat 的 worker 线程，它去执行耗时任务，会拖慢整个连接池 - 自定义策略：记录日志 + 上报指标（如 Prometheus counter），甚至触发熔断（如 Hystrix fallback）；注意日志别打太频，避免磁盘打满
- 千万别用
DiscardPolicy或DiscardOldestPolicy默默丢任务，除非你确认丢的是心跳或埋点这类非关键请求
真正难的不是记住参数名，而是把线程池当成一个黑盒服务来观测：看线程活跃数曲线是否贴合流量波峰，看队列长度是否缓慢爬升，看拒绝次数是否突增。这些信号比任何理论公式都准。
