压测阶段jit预热的核心目标是精准触发真实业务路径热点方法完成c1→c2升级并固化优化代码到code cache，使首批用户请求直接执行已优化机器码，消除p95/p99延迟毛刺。
压测阶段做 JIT 预热插桩，核心目标不是“让所有方法都编译一遍”，而是**精准触发真实业务路径上的热点方法完成 C1→C2 升级，并固化高命中率的优化代码到 Code Cache**。这样首批用户请求进来时，直接执行已优化的机器码，跳过解释执行和首次编译等待，从而消除 P95/P99 延迟毛刺。
明确预热范围：只插桩真实高频、有优化价值的路径
盲目调用所有 public 方法会导致无效编译、Code Cache 污染，甚至挤出真正热点代码。应聚焦三类方法：
- 压测脚本中实际调用的主干服务方法（如
OrderService.createOrder()） - 被这些主干方法高频内联或深度调用的计算密集型子方法（如
PriceCalculator.applyDiscount()） - 涉及对象分配、分支预测、虚函数分派的关键节点（如泛型集合操作、策略模式
doHandle()实现）
采用分层预热策略：先 C1 快速落地，再促 C2 充分优化
JIT 编译是分阶段的。预热需模拟真实负载节奏，不能一蹴而就：
- 启动后立即执行 1–2 轮轻量调用（每方法 50–100 次）：触发 C1 编译，生成带基础优化（如简单内联、寄存器分配）的本地代码，并开始插桩收集分支频率、类型流等数据
- 在压测正式开始前 30–60 秒，以 3–5 倍于线上均值的 QPS 持续调用 10–20 秒：推动计数器越过 TieredStopAtLevel3 阈值（HotSpot 默认约 1500 次调用），将方法提交至 C2 队列；此时 JVM 已积累足够 profiling 数据，C2 生成的代码具备激进优化（如循环展开、公共子表达式消除、逃逸分析优化）
-
确认 C2 编译完成：通过
jstat -compiler <pid></pid>观察total和failed差值，或用AsyncProfiler采样验证目标方法已运行在[Compiled]*帧而非[Interpreted]
绕过 JIT 编译干扰项，确保插桩有效
以下情况会导致预热失效，必须提前规避：
-
禁用字节码缓存干扰：Java 启动加
-Xshare:off，Python 加-B，.NET 加-p:PublishReadyToRun=false，防止预编译/共享归档覆盖运行时 JIT 结果 -
避免异常中断插桩：预热调用路径中不能出现未捕获异常、
System.exit()或线程中断，否则 profiling 数据清零，C2 编译退回到 C1 级别 -
容器环境预留足够共享内存：JVM 需
-XX:ReservedCodeCacheSize=512m，Python 3.14 需挂载/dev/shm并设shm_size: 2gb，否则 JIT 自动降级为解释执行
验证预热是否真正生效
仅看“方法被调用了”不等于成功。需交叉验证三项指标：
-
Code Cache 命中率 ≥ 95%：用
jcmd <pid> VM.native_memory summary</pid>查Code区 usage，或 Python 中检查sys._jit_info['cache_hit_ratio'] -
目标方法已无解释执行帧：用
async-profiler -e cpu -d 30 -f profile.html <pid></pid>采样，搜索方法名，确认全部出现在 Compiled 栈帧中 - 首批 100 请求 P95 ≤ 预热后稳定值 × 1.05：若预热后压测 P95 是 42ms，上线后首批用户 P95 应 ≤ 44ms；超出门槛说明仍有路径未覆盖或编译未固化
