核心线程数应按任务类型合理配置：CPU密集型设为CPU核数+1，IO密集型设为CPU核数×2~3，混合型建议起步值为CPU核数×2，并结合监控（Active Count、Queue Size、Completed Task Count）动态调优，配以有界队列（如ArrayBlockingQueue，容量为核心数×2~4）和CallerRunsPolicy拒绝策略，辅以预热与告警机制。

核心线程数设得太小，哪怕并发量不高，也会让线程池“反应不过来”，任务还没来得及被处理就排队、堆积，最后触发拒绝策略——这不是流量大才出问题，而是配置和业务节奏不匹配。

看真实负载，别只盯QPS数字

高频小并发 ≠ 高吞吐，但可能有短时脉冲或任务执行偏慢。比如每秒10个请求，每个耗时800ms，实际需要至少8个线程才能不积压（10 × 0.8 ≈ 8）。只配2~4个核心线程，任务就会持续进队列，稍一波动就满队列触发拒绝。

• 用监控查 Active Count 是否长期接近 corePoolSize
• 查 Queue Size 是否稳定在高位（如 ArrayBlockingQueue 容量100，常驻80+）
• 对比 Completed Task Count 和提交频次，确认是否存在“提交快、完成慢”的错配

按任务类型重设核心线程数

不能统一拍脑袋定值，要结合任务性质算：

• CPU密集型（如加解密、图像处理）：设为 CPU核心数 + 1，避免上下文切换损耗
• IO密集型（如HTTP调用、DB查询）：设为 CPU核心数 × 2 ~ 3，利用等待时间提升吞吐
• 混合型（多数业务场景）：先按IO密集型起步（如8核配16），再根据监控微调

配对使用有界队列 + 合理拒绝策略

无界队列（如 LinkedBlockingQueue）会掩盖线程数过小的问题，让任务无限堆积，最终OOM；必须改用有界队列，并选能兜底的拒绝策略：

• 队列推荐 ArrayBlockingQueue，容量建议设为 核心线程数 × 2 ~ 4（如 core=12，queue=32～48）
• 拒绝策略优先用 CallerRunsPolicy：让提交线程自己执行任务，天然限流，避免丢任务
• 若需记录与降级，可自定义策略，在拒绝时打告警日志 + 走本地缓存或默认值

加轻量级预热与动态观察机制

新服务上线或配置变更后，线程池不会立刻“满员”，初始任务仍可能因线程未创建而进队列。可主动触发一次预热：

• 应用启动后，提交1~2个空任务并 await，促使核心线程提前就位
• 接入 Prometheus + Grafana，重点看 rejected task count 和 pool active threads 曲线是否同步尖峰
• 设置告警：连续5分钟 rejected > 0，或 queue size > 80% 容量，立即通知