线程池预热应调用prestartallcorethreads()而非setcorepoolsize，动态扩容推荐两级池架构或配置中心驱动重建，配合监控与callerrunspolicy实现闭环保障。
Java线程池在高并发场景下，光靠静态配置远远不够。预热能避免冷启动抖动，动态扩容则应对流量突增——但二者都需避开“直接调用 setCorePoolSize”这类危险操作，否则极易引发任务丢失、线程泄漏或状态不一致。
线程池预热：让核心线程提前就位
刚启动的线程池处于“空池”状态，首个高峰请求会触发线程逐个创建，带来明显延迟。预热就是主动触发核心线程初始化，使其提前进入就绪状态。
- 最简单方式：提交
corePoolSize个空任务（如Runnable::new），并用awaitTermination等待它们被调度执行一次； - 更稳妥做法：调用
prestartAllCoreThreads()—— 这是ThreadPoolExecutor提供的官方预热方法，它会立即启动所有核心线程（即使队列为空），且线程保持空闲等待任务； - 注意：预热应在应用启动完成、监控已就绪后执行，避免与初始化逻辑争抢资源；若使用 Spring，可放在
@PostConstruct或ApplicationRunner中。
动态扩容：不改参数，换思路
高并发下强行修改 corePoolSize 或 maximumPoolSize 是反模式。JVM 不保证这些 set 方法的原子性，多线程并发调用可能覆盖彼此、状态错乱，且无回调确认是否生效。
- 推荐采用“两级池”架构：主池固定承载基线流量（如
core=max=8），另配一个独立的扩展池（如newCachedThreadPool或短生命周期ThreadPoolExecutor）；当监控发现队列积压 > 50 或平均响应超 200ms 时，将溢出任务路由至扩展池；负载回落后再优雅关闭它； - 若必须重建，走配置中心驱动：用 Nacos/Apollo 监听配置变更，在回调中执行「先 drain 队列 → 调用
shutdownNow()→ 等待终止 → 创建新池」全流程；适用于允许秒级重建窗口的业务； - 对短时突发任务，优先考虑
SynchronousQueue + 较大 <code>maximumPoolSize的组合，配合CallerRunsPolicy控制背压，比频繁调参更稳定。
配套保障：监控与拒绝策略协同
没有监控的动态扩容等于盲调。关键指标必须实时采集并告警：
- 活跃线程数（
getActiveCount()）持续接近maximumPoolSize，说明容量逼近瓶颈； - 队列长度（
getQueue().size()）持续增长，提示任务消费慢于生产，需干预或限流； - 拒绝任务数（需自定义
RejectedExecutionHandler计数）突增，是扩容失败或策略失配的明确信号； - 搭配
CallerRunsPolicy可天然形成反压：当线程池满载，由业务线程同步执行任务，客观上降低上游提交速率，为扩容争取时间窗口。
预热解决启动延迟，动态扩容解决峰值压力，而监控和拒绝策略是让这两者真正落地的闭环保障。不复杂，但容易忽略。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
