预热Java线程池核心线程需调用prestartAllCoreThreads()使corePoolSize个线程提前处于WAITING状态，但还需结合轻量任务、连接池配置、JVM参数等实现全链路热身，才能显著降低首请求延迟。
Java线程池预热核心线程，核心目标是让 corePoolSize 个线程在服务真正接收请求前就创建并处于 WAITING 状态，从而跳过首次任务提交时的线程创建开销。但这只是“线程就位”，不是“全链路热身”——单靠它无法解决类加载、JIT 编译、连接初始化等延迟。要真正降低首次请求延迟，得组合使用。
用 prestartAllCoreThreads() 让核心线程提前上岗
这是最直接的线程层预热手段：
- 调用
threadPool.prestartAllCoreThreads()后，线程池立即启动corePoolSize个空闲线程，全部阻塞在getTask()上，等待任务； - 它不创建非核心线程，不触发拒绝策略，也不执行业务逻辑；
- 适合在 Spring 的
@PostConstruct或应用启动监听器中调用，确保早于流量接入； - 注意：若设置了
allowCoreThreadTimeOut(true)，预热后的线程仍可能超时销毁，需权衡是否关闭该选项。
只预热线程不够，还得跑点轻量任务“带热”运行时
线程就绪 ≠ 系统就绪。首次请求慢常因 JIT 未编译、类未加载、连接池未建连。此时需主动触发一次或多次轻量执行：
Java注释规范Skills
下载
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- 提交 10–50 个空任务（如
() -> Thread.onSpinWait()或简单日志打印），让线程池真实走一遍调度路径； - 对关键组件做针对性预热：调用一次数据库健康检查 SQL（触发连接池建连）、调用一次 JSON 序列化方法（促发 Jackson 类加载与 JIT 编译）、访问一个带
@Cacheable的方法（填充本地缓存）； - 避免在预热任务里做重操作（如查大表、调外部 HTTP），否则反而拖慢启动。
配合连接池与 JVM 参数，堵住其他冷启动缺口
线程池只是其中一环，首请求延迟往往是多个“第一次”叠加的结果：
立即学习“Java免费学习笔记（深入）”；
- 数据库连接池（如 HikariCP）启用
initializationFailTimeout=0和connection-test-query，并设置minimumIdle与maximumPoolSize相同，实现连接预热； - JVM 加上
-XX:TieredStopAtLevel=1（禁用 C2 编译器初期可接受，加快启动）或预热后切回默认，也可用-XX:CompileCommand=compileonly,xxx.xxxService::handle指定热点方法强制编译； - HTTP 客户端（如 OkHttp）配置连接池最小空闲数，并在启动时发起一次空 GET 到自身健康检查端点，复用连接。
验证是否真热了：看线程状态和首请求 P95 延迟
别只信代码执行了，要观测实际效果：
- 通过 JMX 或
ThreadPoolExecutor.getActiveCount()+getPoolSize()确认启动后线程数已达corePoolSize且getActiveCount() == 0； - 压测时对比开启/关闭预热的首请求 P95 延迟（例如从 48ms 降到 12ms），比看日志更可靠；
- 结合 Arthas 查看关键方法是否已进入
Compiled状态（sm -c * Service method），确认 JIT 生效。
