JDK 21 虚拟线程用 Semaphore 限流 gRPC 扇出，P99 从 45ms 飙到 2.3s 的根因排查

【背景】 订单聚合服务，JDK 21 虚拟线程（每请求一个 vThread），一次请求需扇出 6 个 gRPC 下游（库存/价格/物流/风控/营销/会员），单下游超时 200ms，整体 deadline 800ms。 上游 Nginx 压测目标 3000 QPS，压测机 16C64G，gRPC 下游共 12 个实例（每个 2C4G）。

【现象】

• 不限流时（即 3000×6=18000 并发 gRPC call）：P50=38ms，P99=45ms，但下游 CPU 打到 92%，GC 频繁。
• 用 Semaphore(500) 做全局并发限流（acquire 在 fan-out 前、release 在 thenAccept 里）：P50=42ms 正常，P99 间歇性飙到 2.3s，且出现大量 "call timeout after 200ms" 日志——即请求在信号量上等待的时间 + 实际调用时间超过了 deadline，但 gRPC 超时计时是从 acquire 之后才开始算的。
• 把 Semaphore 换成 FixedThreadPool(500) 做限流（submit 到池里跑 gRPC call）：P99 降到 180ms，但 P50 从 42ms 涨到 78ms，且 CPU 利用率只有 61%（怀疑池内排队导致 vThread 切换开销）。

【已尝试的排查】

1. jstack + jcmd Thread.dump_to_file 确认无 pin（无 synchronized 块包裹 gRPC call，无 Unsafe park）；
2. gRPC 侧开启 retry（maxAttempts=2, retryDelay 50ms），P99 反而更差（重试占住信号量 slot）；
3. 把 Semaphore 换成 Resilience4j Bulkhead（maxConcurrentCalls=500）：行为与 Semaphore 一致，P99 仍 2.3s；
4. 怀疑是 vThread 被 suspend 在 Semaphore.acquire 时，carrier 线程被释放，但 500 个 vThread 同时 resume 导致 thundering herd——用 -Djdk.tracePinnedThreads=full 跑 30s 没有 pin 日志，但能看到大量 "virtual thread unmounted" 事件。

【期望得到的回答】

1. 虚拟线程在 Semaphore.acquire 上挂起/恢复，是否真的会产生「500 个 vThread 同时 resume → 同时发 gRPC 请求 → 下游瞬间 500 并发」的惊群效应？有没有平滑放行的方案（比如令牌桶 + 随机 jitter）？
2. 对于这种「一个请求扇出 N 个下游、全局有并发上限」的场景，Semaphore（vThread 友好）vs FixedThreadPool（线程亲和）vs 令牌桶（平滑）的取舍，大家生产上怎么选？有没有踩过类似坑的复盘？
3. gRPC deadline 的计时起点是否应该从 acquire 之前就开始（即把等信号量的时间也算入 deadline）？社区里有没有统一的 timeout-budget 实践？