JDK21 虚拟线程把 carrier 池压到 CPU 核数后，JSON 反序列化段 P99 反升：carrier 大小到底怎么定？

【背景】 我负责一个支付回调服务：Spring Boot 3.2 + JDK 21（spring.threads.virtual.enabled=true，未额外调 carrier）+ MySQL 8.0 + Redis 7 + gRPC（下游风控）。容器 8C16G（K8s cpu limit=8），入口 QPS 约 1500，单请求链路：解析回调报文（Jackson 反序列化，报文 8~15KB，平均 2.3ms，P99 8ms）→ 落 MySQL 幂等表 → 调风控 gRPC（P99 35ms）→ 写结果。

【现象】 切到虚拟线程之前（Tomcat 线程池 200），整体 P99 稳定 60ms。切虚拟线程后压测 QPS 拉到 2000：DB 与 gRPC 段 P99 确实从 12ms / 40ms 降到 6ms / 25ms（IO 段收益明显），但JSON 反序列化段 P99 从 8ms 涨到 42ms，且 async-profiler 看到的 CPU 时间反而涨了约 35%。整机 CPU 利用率只到 62%，说明不是绝对算力不够，更像是调度/上下文切换放大。-Djdk.tracePinnedThreads=short 干净，JFR 里 jdk.VirtualThreadPinned 事件 0 条。

【已尝试的排查】

1. 显式设 -Djdk.virtualThreadScheduler.parallelism=16（2×核数）：P99 没变，反而多 5% 抖动；
2. 设到 4（小于核数）：P99 反而降到 18ms，但 QPS 上限掉到 1600，说明 carrier 少了会饿；
3. 把报文解析从 Jackson 换成 Aeron 风格的紧凑结构（仅压测用）：P99 回到 9ms，确认是「CPU 密集段 + 虚拟线程」组合问题，不是 Jackson 本身；
4. 怀疑是 GC 或 safepoint，关 -Xlog:safepoint 看 STW 都在 0.3ms 内，排除。

【期望得到的答案形态】

1. 在「IO 为主 + 少量 CPU 密集段（JSON / 加密 / 序列化）」的服务里，carrier 线程池大小有没有比「默认 = CPU 核数」更靠谱的估算方法？比如按 CPU 密集段占比 / 单请求 CPU 时间 / 目标 P99 反推？
2. 这种混合负载下，业界常见的两种取舍——「调大 carrier 让 CPU 段并行」 vs 「把 CPU 密集段拆出虚拟线程、用独立池跑」——各自在 P99 / QPS / 复杂度上的实测数据有人分享过吗？
3. 有没有可落地的 profiling 指标（JFR 事件名、async-profiler 火焰图里看哪个栈帧）能直接定位「CPU 密集段在虚拟线程下被挤压」？

欢迎有相同迁移经验的同学贴具体参数（核数、carrier、QPS、P99）与数据。