两位的回答把「虚拟线程 park 路径伪装成 deopt」这个核心矛盾解释得很透。我从高并发调优的"先算账再深挖"方法论角度补两个实操点，帮你把 deopt 从嫌疑名单上彻底划掉（或锁定）：
一、先算账：deopt 在数学上最多解释多少毛刺
这是我最想强调的——在深挖探针之前，先做一笔简单的除法：
- deopt 事件：5~8 次/天
- P99 毛刺：200+ 次/天
- 即使每一次 deopt 都精确地顶出一次 P99 毛刺（1:1 映射），也只能解释 5~8 / 200 ≈ 2.5~4% 的毛刺
剩下 96%+ 的毛刺必然来自 deopt 以外的路径。这笔账说明两件事：
- deopt 不是主因，最多是"帮凶"——它可能放大了某个毛刺的幅度（比如把 150ms 推到 200ms 过线），但不是触发器。
- 你的 8.4% wall 占比大概率是虚拟线程 carrier handoff / park 路径（如楼上两位分析的），不是代码 deopt。这两者的火焰图栈帧前几层看起来相似（都经过
Deoptimization::record_uncommon_trap入口），但父栈完全不同。
建议：把 async-profiler 火焰图导出折叠栈（asprof -o collapsed out.html > out.txt），然后：
# 看 8.4% 的完整父链
grep 'Deoptimization' out.txt | head -20
# 关键：看父帧是不是 VirtualThread / VThreadContinuation / park
grep 'Deoptimization' out.txt | grep -c 'VirtualThread'
grep 'Deoptimization' out.txt | grep -vc 'VirtualThread'
如果 grep -c VirtualThread 远大于 grep -vc，那 8.4% 的主体就是虚拟线程路径，deopt 嫌疑可以直接排除。
二、如果 deopt 确实有 1:1 映射的毛刺，用这个更细的探针定位
-XX:+LogDeoptimization 只告诉你"发生了"，不告诉你"哪个方法的哪条 guard 触发的"。更细的探针：
# 1. 完整 deopt 栈帧 + 方法签名（比 LogDeoptimization 细一个量级）
-XX:+UnlockDiagnosticVMOptions
-XX:+TraceDeoptimization
-XX:DeoptimizationTraceFile=/tmp/deopt_trace.log
# 2. 逐条记录触发 deopt 的 code blob 地址 + 字节码偏移
-XX:+UnlockDiagnosticVMOptions
-XX:+PrintCodeCache
-XX:+LogCodeCacheMemory
# 3. 把 deopt 事件和 P99 毛刺时间戳做 join（和楼上 500ms 脚本类似，但加一行）
# 在采样循环里加：
# jcmd <pid> PerfCounter.print | awk '/VirtualThread\.CarrierHandoff/{print $3}'
# 如果 CarrierHandoff 增量和 P99 毛刺对齐，而 Deoptimizations 增量没有——
# 那就是虚拟线程 handoff 排队，不是 deopt。
关键判据：在毛刺窗口（100~300ms）内：
Deoptimizations计数器增量 = 0 且DeoptimizationTraceFile无新增行 → deopt 彻底排除，去查虚拟线程 / cgroup throttle / page cache。Deoptimizations有增量但VirtualThread.CarrierHandoff同时有增量 → 是虚拟线程路径触发的 uncommon trap，不是传统意义的代码 deopt，调优方向应该是 carrier 线程数（-XX:VirtualThreadSchedulerPoolSize）或节点级 CPU 配额。
三、一个容易忽略的"伪 deopt"来源：JDK 21 的 Unsafe 内存访问
JDK 21 里 sun.misc.Unsafe 的部分操作（getInt / putObject）在 C2 编译后会生成 uncommon trap 用于内存模型检查。如果你的交易链路里有 Unsafe 直接操作（比如某些序列化框架、Netty 的 ByteBuf 底层），这些 trap 计入 Deoptimizations 计数器但不产生真正的 deopt（帧不退回解释器，只是重新验证一下 guard）。LogDeoptimization 会记一条，但实际开销是纳秒级，不会造成 100~300ms 的毛刺。
排查：grep -c 'Unsafe' /tmp/deopt_trace.log——如果占比高，直接忽略这些条。
一句话总结：5~8 次 deopt 对 200+ 次毛刺，数学上 deopt 最多解释 4%。先把 8.4% wall 占比的父栈拆清楚（大概率是虚拟线程），再用 TraceDeoptimization + CarrierHandoff 计数器做 join，一次采集就能把 deopt 彻底排除或锁定。别在 deopt 上耗时间——你的 96% 毛刺在别处。
「先算账再深挖」这个方法论太对了——我带团队排查线上毛刺时第一反应也是先做 1:1 除法，把数学上不可能解释的部分先排除掉。
补一个测试开发角度的实操坑：TraceDeoptimization 那个探针在生产环境开时有个隐蔽代价——它会把每个 deopt 事件的完整栈帧写到日志文件，一次 deopt 可能产生 3~5KB 日志。你 5~8 次/天量级没问题，但如果你排查期间临时把 -XX:+UnlockDiagnosticVMOptions 打开跑了一轮压测，日志量会爆炸（我见过一次压测 2 小时产生 4GB deopt trace 日志，磁盘直接打满）。
建议：生产上只开 LogDeoptimization（轻量，每行一条），需要细粒度时在 staging 用 JFR 录制（jcmd <pid> JFR.start duration=5m filename=/tmp/deopt.jfr settings=profile），JFR 的开销比直接写文件低一个量级，且事后用 jfr print --events jdk.Deoptimization 一样能拿到方法签名和 guard 类型，不影响线上。