JVM 堆 32GB 冷启动 40 秒 P99 尖刺：AlwaysPreTouch 与页错误机制的完整复盘

结论先行：发布后前 30~60 秒的 P99 尖刺，第一嫌疑不是 GC、不是预热接口、不是数据库，而是「堆内存的惰性分配」——JVM 启动时 mmap 了 32GB 虚拟地址空间，但物理页一张都没碰；流量进来后每一次对象分配、每一次 GC 扫描都在触发 demand-paging，CPU 时间被 page fault 悄悄吃掉。-XX:+AlwaysPreTouch 一行配置可以把尖刺窗口从 40 秒压到几乎不可见，但它也有两个不那么明显的副作用，下文细说。

一、现象与背景：发布窗口内 P99 从 28ms 飙到 6.2s

先给数字，方便对号入座。

• 服务：订单结算服务，JDK 17.0.8，G1，-Xms16g -Xmx32g（故意留了翻倍空间吃动态扩容），K8s 里 6 个副本，单副本 8C16G——注意 32GB 堆其实超了容器 limit，这是后话，先不管它。
• 故障形态：每次滚动发布，新 pod 接流后的前 40 秒，P50 基本正常（30~40ms），但 P99 稳定在 5~8s，接口偶发超时。压测环境复现：新容器冷启动后压 1000 QPS，第一分钟 P99=6200ms，第二分钟 480ms，第三分钟回落到 28ms 的稳态。
• 排查时的迷惑点：jstat -gcutil 显示这段时间 Young GC 频率正常（约 2 次/秒，单次 30~60ms），没有 Full GC；慢 SQL 日志干净；连接池 active/max 只用了 40%。看起来一切都好，唯独 P99 在抖。
• 影响面：灰度期间 6 个副本滚动发布，每次发布约 5 分钟里有 2 分钟的窗口 P99 超标，触发告警 11 次，SRE 一度怀疑是网关或 LB 的问题。

二、根因：mmap 的「虚拟地址」不是「物理内存」

把机制拆开讲，这是理解这件事的关键：

1. JVM 启动时：-Xmx32g 只是向内核 mmap 了 32GB 的虚拟地址空间。此时进程 RSS 只有几百 MB，物理页一张都没有。
2. 流量进来后：JVM 每写一个字节（对象分配、GC 的 copy、CodeCache、线程栈），内核都必须走一次 demand paging：缺页中断 → 分配物理页 → 建页表项 → 填 TLB。单次 page fault 大约 1~2μs，听起来不多，但 G1 的 Young GC 一次要扫描和拷贝整个 Eden + Survivor，16GB 的 Eden 意味着一次 GC 可能触发上千万次首触缺页。
3. 真正吃时间的不是缺页本身，而是它和 GC 的叠加：STW 期间 CPU 本来就在做内存密集操作，此时每几个 cache line 就要停一次等内核，GC 停顿被放大到平时的 5~10 倍；而业务线程在 GC 前后的分配路径上也在持续付缺页税。宏观表现就是：GC 日志看起来"次数不多"，但每次停顿都偏长，业务 P99 被拖上去。
4. 为什么 P50 正常、P99 尖：缺页是均匀分摊的，但 P99 采样的是长尾——恰好撞上「GC 停顿放大 + 本线程首次触碰大对象区」的请求，尾延迟自然爆炸。

用 /proc/<pid>/smaps 里 Pss 的变化可以验证：发布后 10 秒，堆区 Pss 只涨了 ~1GB；40 秒后才逼近 16GB（-Xms 值）。堆的物理页是在流量"喂"出来的，而不是启动时就有的。

三、具体做法：AlwaysPreTouch + 验证 + 配套动作

1) 核心配置（JDK 8u101+ / 11 / 17 都支持）：

-XX:+AlwaysPreTouch

它让 JVM 在启动阶段就主动遍历整块堆（-Xms 到 -Xmx 之间，实际按 -Xms 预触），把物理页全部 fault 进来。我们加了之后的实测数据（16C32G 压测机，JDK 17.0.8）：

| 指标 | 无 PreTouch | 有 PreTouch | |---|---|---| | 冷启动→可服务（health check 通过） | ~9s | ~38s（慢了 29s，可接受） | | 接流后第 1 分钟 P99 | 6200ms | 41ms | | 接流后第 1 分钟 GC 平均停顿 | 210ms | 34ms |

2) 验证它真的生效了（别只看启动变慢就以为 OK）：

# 启动完成后，看堆区物理页是否已就位
pmap -x <pid> | awk '$5 ~ /rwx/ {print $1, $2}' | head
# 或者更直接：
grep -E 'RssAnon|Pss' /proc/<pid>/smaps_rollup
# 稳态预期：RssAnon ≈ 17~18GB（16g 堆 + 元空间/线程栈/CodeCache）
# 没生效的话：启动后 10 秒 RssAnon 只有 1~3GB

3) K8s 侧配套（这步不做，前面的功一半白费）：

• startupProbe 的 failureThreshold × periodSeconds 必须 ≥ 预触耗时。我们是 16g 堆，预触 ~30s，原来 probe 是 5s×3=15s，直接在新 pod 还没就绪时就被 kill 过一次。改成 periodSeconds: 5, failureThreshold: 15（75s 窗口）。
• resources.limits.memory 要 ≥ -Xmx + 堆外预算（Metaspace ~512MB + 线程栈 ~400MB + CodeCache ~256MB + 其它 ~500MB），我们 16g 堆给 18Gi limit。
• 发布策略上，maxUnavailable: 0 + 足够长的 progressDeadlineSeconds，避免"新 pod 还没预触完、旧 pod 已被缩掉"。

4) 如果想更精细（可选）：

JDK 17 没有官方"只预触堆不预触别的"的开关，AlwaysPreTouch 是全开的。需要区分时可以用 pmap 对比预触前后的段分布，确认 CodeCache / Metaspace 没被意外放大——一般不会有，但见过一次因为 -XX:ReservedCodeCacheSize 设了 2G 导致预触时间多 4 秒，改回 512m 就正常了。

四、踩过的坑 / 反直觉之处

1. -Xms=-Xmx 不等于「预触」。很多人以为设了 -Xms16g 内存就"锁定了"，其实它只是预留虚拟地址、禁止堆收缩，物理页该懒还是懒。必须 +AlwaysPreTouch 才真正落盘。这是我们踩的第一个坑，排查花了半天。
2. 预触是「写」，不是「读」。JVM 用的是 memset/写路径触发缺页，读（madvise(MADV_POPULATE_READ) 那种）在部分内核上不会真的建页表项，JVM 团队踩过这个坑后统一走了写路径。所以预触耗时 ≈ 堆大小 / 内存带宽，16GB 大约 20~40s，别指望它 1 秒搞定。
3. THP 会让预触"帮倒忙"。如果内核开着 transparent_hugepage=always，预触 16GB 可能触发大量大页整理（khugepaged 合并），启动 CPU 会打满 30~60 秒，甚至影响同 node 上的邻居容器。JVM 应用建议内核侧 transparent_hugepage=never + JVM 侧 -XX:+UseLargePages 显式申请，比 THP 可控得多。
4. -Xmx 大于容器 limit 是隐形炸弹。我们最初 -Xmx32g 塞在 16G limit 的 pod 里，预触一开，RssAnon 直接顶到 32GB，pod 在启动阶段就被 OOMKilled，K8s 事件里只有 OOMKilled、没有 Java 日志，非常迷惑。预触是把「运行期才会撞墙」的问题提前到了「启动期就撞墙」，这是它的一个副作用——它暴露了原本的内存预算错误。
5. GC 日志不会告诉你缺页。-Xlog:gc* 里看到的 pause 时间是 STW 总时长，包含缺页开销，但没有独立字段。想量化缺页，只能用 perf stat -e page-faults,context-switches -p <pid> sleep 5，或 pidstat -r 1 看 minflt/majflt。冷启动阶段 minflt 每秒几十万到百万级是正常信号。

五、结论与可复用清单

结论：中大型堆（≥8GB）的 Java 服务，默认就该开 AlwaysPreTouch，把「启动慢 30 秒」换「发布窗口 P99 尖刺消失」，这笔账几乎永远划算。它不是性能优化，是把不可预测的启动期成本前置成可预测的启动期成本。

清单（贴在你团队的发布 checklist 里）：

• [ ] JVM 参数：-XX:+AlwaysPreTouch，且 -Xms = -Xmx（避免运行时扩容引入二次缺页）
• [ ] 内存预算：limit ≥ Xmx + Metaspace + 线程栈 + CodeCache + 500MB 余量
• [ ] startupProbe 窗口 ≥ 预触实测耗时 × 1.5
• [ ] 内核：transparent_hugepage=never（或 node 级 kubelet 配置）
• [ ] 验证手段：pmap -x <pid> / smaps_rollup 看 RssAnon 是否已就位
• [ ] 观测指标：发布窗口内打点 P99、gc.pause.avg、minflt/s，三者对齐才能定位缺页问题
• [ ] 大堆（≥32GB）考虑换 ZGC / Shenandoah，把 STW 敏感度本身降下来，PreTouch 只是治标

一句话总结：别等 P99 报警了才想起物理页还没到位——发布窗口内的长尾，很多根本不是代码的锅，是操作系统在"补票"。