corepoolsize过小会导致高并发下任务积压队列、响应延迟飙升，应按平均并发量（如8）或io密集型场景（cpu核数×2～4）合理设置，避免盲目采用“cpu核数+1”。
corePoolSize设太小，任务一多就卡住
线程池刚创建时只维持corePoolSize个空闲线程，新任务来了如果没空闲线程，就往队列里塞；但队列又不是无限快的缓冲区——它得等前面的任务被消费完。很多人以为“反正有队列兜底”，把corePoolSize设成1或2，结果高并发下大量任务在队列里排队，响应延迟飙升。
实操建议：
- 按业务平均并发量预估：比如常驻5–10个HTTP请求同时处理，
corePoolSize至少设为8 - 若任务是IO密集型（如调外部API、查DB），可适当放大，比如CPU核数 × 2～4
- 别盲目跟风“CPU核数+1”，那是针对纯计算任务的粗略经验，不适用于多数Web服务
- 用
getActiveCount()和getQueue().size()实时观察，发现长期getActiveCount() == corePoolSize且队列持续增长，说明corePoolSize已成瓶颈
maxPoolSize没生效？可能是队列类型选错了
maxPoolSize只有在队列满了之后才起作用：当队列无法接纳新任务（offer()返回false），线程池才会尝试创建新线程，直到达到maxPoolSize。但如果你用的是LinkedBlockingQueue且没指定容量（即默认Integer.MAX_VALUE），那队列永远“不满”，maxPoolSize就彻底失效，所有超额任务全堆在队列里。
实操建议：
- 慎用无界队列：
new LinkedBlockingQueue()≈ 自找OOM，改用有界队列，比如new LinkedBlockingQueue(100) - 想让
maxPoolSize真正参与调度，推荐SynchronousQueue：它不存储任务，每个submit()都必须立刻有空闲线程接手，否则就触发扩容 - 若用
ArrayBlockingQueue，注意它的offer()是非阻塞的，配合CallerRunsPolicy能避免任务丢失，但会拖慢提交方线程
拒绝策略不是摆设，选错等于掩盖问题
当线程数已达maxPoolSize且队列也满了，新任务就会被拒绝。默认的AbortPolicy直接抛RejectedExecutionException，很多同学 catch 住就完事，结果掩盖了资源水位真实过载的事实。
实操建议：
-
CallerRunsPolicy看似“温和”，但会让业务线程自己执行任务，可能拖垮上游（比如Tomcat线程跑着跑着开始执行数据库操作） -
DiscardOldestPolicy会丢掉队列头任务，适合有明确时效性的场景（如实时行情推送），但要注意被丢的是最老的，不一定是“不重要”的 - 真要自定义，优先记录日志+上报指标（如Prometheus counter），而不是静默吞掉或重试——重试可能引发雪崩
- 别在生产环境用
DiscardPolicy，除非你确认丢任务完全无影响（极少见）
keepAliveTime对非核心线程的实际影响很有限
keepAliveTime只控制**超出corePoolSize的那些线程**的存活时间。也就是说，即使设成1秒，只要当前活跃线程数 ≤ corePoolSize，所有线程都会一直活着；只有当负载下降、空闲线程数 > corePoolSize时，多出来的线程才可能被回收。
实操建议：
- 设太短（如100ms）意义不大：线程创建销毁本身有开销，频繁启停反而增加GC压力
- 设太长（如60分钟）也不合理：低峰期空转线程占内存，还可能持有无用连接（如未关闭的JDBC连接）
- 常见合理值是60秒左右，配合监控看
getPoolSize()波动，如果长期高于corePoolSize，说明corePoolSize可能偏低或任务有长尾 - 注意：
allowCoreThreadTimeOut(true)能让核心线程也受keepAliveTime约束，但一般不建议开启，除非你确定所有任务都能容忍冷启动延迟
参数之间不是独立配置的，corePoolSize、队列容量、maxPoolSize三者构成一个联动系统。调其中一个，另外两个的行为很可能跟着变；最容易被忽略的是队列的选择——它直接决定了maxPoolSize有没有机会被触发。
