JVM垃圾回收不支持按业务波峰预热，但可通过预热使JIT编译完成、堆结构收敛、对象生命周期固化及资源池就绪，从而减少波峰初期GC不确定性；分三阶段：0–2分钟基础资源就绪、2–8分钟GC结构稳定化、8–15分钟热点代码与内存模式固化。
JVM 垃圾回收本身不支持“按业务波峰预热”，但可以通过预热手段让 GC 环境提前进入稳定状态，从而在真实波峰到来时避免因冷启动引发的延迟尖峰。核心不是让 GC “等波峰”，而是让 JVM 在波峰前完成 JIT 编译、堆结构收敛、对象生命周期模式固化和资源池就绪——这些直接决定 GC 行为是否可控。
预热目标明确：减少波峰初期的 GC 不确定性
刚启动的服务常出现以下问题：
- 新生代 Eden 区未稳定，Minor GC 频率高且耗时波动大
- 对象晋升年龄未收敛，大量中年对象误入老年代，诱发 Mixed GC 或 Full GC
- Survivor 区过小或比例失衡，一次 Minor GC 就触发提前晋升
- 类加载未完成、JIT 编译未生效，导致临时对象激增（如反射、日志拼接）
这些问题叠加业务波峰，极易造成秒级卡顿。预热就是把这些“抖动”提前消化掉。
按波峰节奏设计预热阶段
把预热拆成三个可操作的时间段，匹配典型波峰前行为（如大促前 30 分钟、早高峰前 15 分钟）：
-
启动后 0–2 分钟：基础资源就绪
- 触发线程池预热：调用
prestartAllCoreThreads()，确保接收请求的线程已创建 - 初始化数据库/Redis 连接池：用最小空闲连接数主动建连，避免首个请求阻塞
- 加载核心类与 Spring Bean，触发类加载与静态初始化，减少后续反射开销
- 触发线程池预热：调用
-
启动后 2–8 分钟：GC 结构稳定化
- 模拟中等压力流量（约峰值 30%），持续 5 分钟左右
- 目标是让 G1 完成至少 2 轮并发标记周期，使
G1Ergonomics自适应策略收敛（可通过-XX:+PrintAdaptiveSizePolicy日志确认 Eden 大小不再频繁调整） - 观察
jstat -gc <pid> 2000，确认 YGC 次数下降、Eden 使用率波动收窄、Survivor 幸存率稳定（如 consistently 95%+ 对象在 S0/S1 间复制）
-
启动后 8–15 分钟：热点代码与内存模式固化
- 执行关键路径全链路调用（如下单、查缓存、写 DB），覆盖主要对象分配场景
- 强制触发 1–2 次 Minor GC（如通过
System.gc()不推荐；更稳妥的是分配可控大小的 byte[] 数组触发 Eden 满） - 检查 GC 日志中
Age分布：若age=3的对象占比显著上升且稳定，说明对象生命周期模型已成型，-XX:MaxTenuringThreshold=4类参数才真正起效
配合业务波峰的实操建议
- 不要等波峰前 1 分钟才开始预热——JVM 稳定需要时间，建议在服务发布后、流量接入前自动执行（K8s 中可用
startupProbe+ 脚本） - 预热流量必须真实：用线上采样 trace 或录制关键接口请求，避免只压测 Hello World 接口（它不触发实际 GC 压力）
- 关键指标看“变异系数”而非绝对值：比如连续 5 次 Minor GC 耗时标准差 < 15%，才算预热达标
- 若使用 ZGC/G1，预热后应关闭
ZCollectionInterval或G1PeriodicGCInterval，防止后台 GC 干扰波峰响应
预热不是魔法，它只是把本该在用户请求里暴露的问题，挪到无人关注的准备阶段解决。真正决定波峰表现的，还是对象分配速率是否可控、大对象是否规避、老年代是否干净——这些靠代码，不靠预热。
