预热需调用prestartAllCoreThreads()提前拉起核心线程，动态扩容应避免直接修改参数，推荐两级池设计或配置中心驱动重建，并配套监控与CallerRunsPolicy反压机制。
预热和动态扩容不是“加几个线程”这么简单，关键在于让线程池提前就绪、按需伸缩，且全程可控不抖动。
预热：让核心线程提前进入待命状态
刚启动的线程池是空的，首个高峰来临时会逐个创建线程，造成明显延迟。预热就是把这步提前做完。
- 别用提交空任务再等执行的方式——容易受调度干扰，也不够可靠
- 直接调用
prestartAllCoreThreads()，这是 ThreadPoolExecutor 提供的官方方法，能立即拉起所有核心线程并保持空闲等待 - 预热时机很重要：必须在应用初始化完成、监控已就绪之后执行，避免和 Spring 启动逻辑抢资源
- Spring 环境下推荐放在
@PostConstruct或ApplicationRunner中，确保时机可控
动态扩容：不硬改参数，靠架构+策略兜底
运行时直接调 setCorePoolSize() 或 setMaximumPoolSize() 是危险操作——JVM 不保证原子性，多线程并发调用可能覆盖彼此、状态错乱。
- 优先采用“两级池”设计：主池（如 core=max=8）稳住基线流量；另配一个独立扩展池（如短生命周期的
ThreadPoolExecutor），当监控发现队列积压 > 50 或平均响应超 200ms 时，把溢出任务路由过去；负载回落再优雅关闭 - 若必须重建线程池，走配置中心驱动：用 Nacos/Apollo 监听变更，在回调里完整执行「先 drain 队列 →
shutdownNow()→ 等待终止 → 创建新池」，适用于允许秒级重建窗口的业务 - 对短时突发，更稳妥的是用
SynchronousQueue+ 较大maximumPoolSize，配合CallerRunsPolicy形成天然反压——线程池满时由业务线程同步执行任务，自动减缓上游提交速度
配套保障：监控和拒绝策略必须联动
没有监控的扩容等于蒙眼开车。以下指标要实时采集并设阈值告警：
-
getActiveCount()持续接近maximumPoolSize，说明容量逼近瓶颈 -
getQueue().size()持续增长，代表任务消费慢于生产，需干预或限流 - 自定义
RejectedExecutionHandler统计拒绝数，突增就是扩容失败或策略失配的明确信号 -
CallerRunsPolicy不仅是兜底，更是缓冲器：它让业务线程参与执行，客观上为扩容争取时间窗口
特别注意的坑
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 别用无界队列（如
new LinkedBlockingQueue<>()），任务持续堆积终将 OOM - 调大
corePoolSize后，必须紧跟prestartAllCoreThreads()，否则新增线程不会自动创建 - 调小
corePoolSize时，默认空闲核心线程永不回收，得提前设allowCoreThreadTimeOut(true)并配合理keepAliveTime - 所有调整都应在 RUNNING 状态下进行，SHUTDOWN 后只允许缩容，STOP 及之后状态下调用无效
不复杂但容易忽略
