corepoolsize设太小会导致频繁创建线程：当提交任务时，若当前线程数小于corepoolsize，会创建新线程执行任务，而非复用空闲线程或放入队列。
corePoolSize设太小会导致频繁创建线程
当提交任务时，若当前线程数 corePoolSize，线程池会直接新建线程执行，哪怕有空闲线程（因为还没达到核心数，不复用）。设得太小（比如 1 或 2），高并发下会反复触发线程创建，带来明显开销和上下文切换压力。
实操建议：
- 对 CPU 密集型任务，
corePoolSize≈ CPU 核数（Runtime.getRuntime().availableProcessors()）； - 对 I/O 密集型任务，可设为 2–4 倍核数，但需结合实际阻塞比例压测验证；
- 避免硬编码，用配置项或系统属性动态注入，便于不同环境调整。
keepAliveTime对非核心线程的实际影响常被误读
keepAliveTime 只作用于「超过 corePoolSize 的那些线程」，即非核心线程。一旦空闲超时，就会被销毁。但很多人忽略了：这个超时是从线程最后一次从 workQueue 取到任务后开始计时的，不是从线程创建起算。
常见错误现象：
立即学习“Java免费学习笔记（深入）”；
- 设了 60 秒
keepAliveTime，但线程池长期维持 20+ 线程 —— 很可能是因为队列里还有积压任务，线程一直在轮询取任务，没真正“空闲”； - 把
keepAliveTime设为 0L，配合allowCoreThreadTimeOut(true)，才能让所有线程（包括核心线程）都可超时回收； - 使用
SynchronousQueue时，keepAliveTime几乎无意义，因为该队列不缓存任务，线程必须立即处理，否则拒绝。
拒绝策略选错会掩盖真实瓶颈
默认的 AbortPolicy 直接抛 RejectedExecutionException，看似“严格”，但在生产中容易导致上游重试风暴或日志刷屏。更关键的是：它不提供任何线索说明为什么拒绝——是队列满了？还是线程数已达 maximumPoolSize？
推荐组合与注意点：
- 用
CallerRunsPolicy时，拒绝任务由调用线程自己执行，能自然降速，但要注意调用方是否能承受同步执行耗时； - 自定义策略中，务必记录
task.toString()、当前getPoolSize()、getQueue().size()，否则排查时只能猜； - 不要在拒绝策略里做复杂逻辑（如发 MQ、远程调用），它运行在任务提交线程中，可能拖慢整个提交链路。
workQueue类型决定线程池行为本质
很多人只改 corePoolSize 和 maximumPoolSize，却忽略队列才是线程池“性格”的决定者。不同队列让同一组参数表现完全不同：
-
ArrayBlockingQueue：有界，任务积压到上限后立刻触发拒绝策略，适合对资源消耗敏感、需强控并发量的场景； -
LinkedBlockingQueue（无参构造）：默认容量Integer.MAX_VALUE，等于“几乎无限”，此时maximumPoolSize失效（永远达不到），线程数锁死在corePoolSize，容易 OOM； -
SynchronousQueue：无缓冲，每个任务必须立刻被线程消费，否则走拒绝策略，适合追求低延迟、短任务、可控扩缩的场景。
最易被忽略的一点：队列容量不是“越大越好”。大容量队列会掩盖响应延迟问题，让监控看到的平均 RT 正常，但尾部延迟（P99）早已恶化——因为任务在队列里等了几秒才被处理，而你根本没告警。
