Java 服务 P99 长尾但 CPU/内存/网络全绿，如何用 async-profiler + perf 定位是 GC、page cache 抖动还是 JIT 去优化

【背景】 我们是 8 年线上经验团队，核心交易链路 Spring Boot 3 + JDK 17（ZGC，-Xmx8g）+ MySQL 8 + Redis 7，部署在 K8s（cgroup v2，cpu limit=4）。今年开始把 P99 纳入 SLO，目标是 P99 < 300ms。

【现象】 过去两个月，某个订单查询接口 P99 从 210ms 漂到 480ms，P50 稳定在 90ms 没动。但传统监控全绿：

• 节点 CPU 利用率峰值 55%（cgroup 维度），load 1m < 2
• JVM heap 占用 40%，ZGC 单次 pause < 5ms，GC log 里几乎看不到长 pause
• 网络 retransmit 接近 0，磁盘 IOPS 平稳
• MySQL slow log 没有新增，Redis 命中 99.8%
• 没有发布、没有配置变更

也就是说：CPU、内存、网络、磁盘、DB、缓存六个维度都"看起来正常"，但用户侧 P99 翻倍。

【已尝试的排查与结果】

1. 抓了 24h 的 JFR + 火焰图（async-profiler 默认 wall 模式），对比 P99 尖刺时刻与平稳时刻的火焰图，top 10 方法占比差异 < 3%，看不出明显差异。
2. 开了 -XX:+UnlockDiagnosticVMOptions -XX:+PrintCompilation，grep 编译日志没看到目标方法反复 deopt。
3. 用 perf top -p <pid> 在尖刺时刻抓了 30s，发现 native 里 mmap / page_fault 类符号占比从 1% 升到 7%，但不确定是不是噪声。
4. 怀疑是 cgroup cpu.max 限流（throttling），但 cgroup v2 的 cpu.stat 里 nr_throttled 几乎为 0，基本排除。
5. 怀疑是 page cache 抖动 / 大页回收，但没有直接证据。

【期望得到的答案形态】 想请教社区里在类似"六绿一长尾"场景下有实战经验的同学：

1. 你们通常用什么组合拳（工具 + 采样窗口 + 关键指标）把"JIT 去优化 / 大对象分配 / page cache 抖动 / cgroup 隐性限流"这四类嫌疑逐一证伪或证实？
2. async-profiler 是建议用 wall 模式还是 cpu 模式做对比？有没有推荐的对比基线（比如同时段 P50 时段 vs P99 尖刺时段的火焰图 diff）？
3. JDK 17 + ZGC 下，哪些 -XX 诊断参数 / JFR 事件（如 jdk.ZGCPhase、jdk.AllocationOutsideTLAB）值得常开？
4. 在 K8s cgroup v2 下，有没有比 cpu.stat 更敏感的限流指标（比如 pressure stall information / PSI）可以直接纳入大盘？
5. 如果最后定位到是 page cache / 大页回收，你们线上是怎么缓解的（mlock？hugepages？调整 vm.vfs_cache_pressure？）？

希望有真实案例或可复现命令的同学分享，谢谢。