请求进线程池队列排队后 deadline 被耗尽：「排队耗时是否计入剩余预算」的准入判断，有没有可落地的做法？

背景 我在做订单中台的一个聚合接口（Java 17 + Spring Boot，8C16G，4 实例），入口 QPS 峰值约 2k，P99 SLO 500ms。链路是：网关（800ms）→ 本服务（预算 500ms）→ 并行调 2 个下游 RPC（各自 P99 约 150ms）+ 1 次 MySQL 查询。本服务内部用了一个业务线程池承接入口请求（core=32, max=64，有界队列 256，拒绝策略是 AbortPolicy），RPC 调用用异步非阻塞提交，deadline 用 Resilience4j 的 timeout + CompletableFuture.orTimeout 实现。

现象 上周一次下游 GC 抖动（持续约 40s），本服务没挂，但 P99 从 120ms 直接顶到 500ms 全部超时，且超时的请求里有一大半实际「业务处理只花了 80ms」——时间全耗在线程池队列里排队等 worker 了。具体数据：

• 队列峰值深度 253/256（打满），worker 全忙；
• 被 orTimeout 500ms 杀掉的请求中，抽样 200 条：168 条的「执行耗时」<100ms，但「入队到开始执行」的等待中位数 420ms；
• 更糟的是：这些被杀掉的请求，其下游 RPC 有些其实已经发出去了（进入「已提交未确认」窗口），超时取消没有真正取消 in-flight 调用，下游白跑了一轮。

已尝试的排查与结果

1. 把队列从 256 缩小到 64，期望快速触发 AbortPolicy 拒绝——结果 P99 确实更「干净」了（要么 120ms 要么直接 429），但拒绝率从 0.3% 涨到 2.1%，业务方不接受；
2. 把拒绝策略换成 CallerRunsPolicy——直接踩了嵌套池的坑，网关线程被拖去跑业务，P99 一度飙到 3.2s，已回滚（和 id=672 那篇复盘的现象基本一致）；
3. 在业务代码入口加了个粗判断：queue.size() > 128 时直接 429——能用，但 128 是拍的，且它没考虑「队列里每个任务还要跑多久」，队列浅但任务重时照样超时。

想请教的具体问题 社区里 deadline 传播（id=625）、背压归属（id=1395）、拒绝策略选型（id=137）都讨论过了，但有一个缝隙没人正面回答：**「入队前的准入判断」到底该用什么信号？**我纠结的是三套方案的取舍：

• 方案 A：按队列深度拒绝（现状的加强版）。简单，但深度 ≠ 等待时间，队列里堆的是快任务还是慢任务完全未知；
• 方案 B：按剩余 deadline 反推可接受等待。入队前估算「队列排空预估耗时 + 本任务预估执行耗时 < 剩余 deadline」才放行。问题是两个「预估」从哪来——用 EWMA 维护每个 task type 的平均执行时间可行吗？队列排空时间用 queue.size() / 平均吞吐 这种粗估在负载波动时会不会系统性偏乐观？
• 方案 C：干脆不要队列（core=max，无队列，直接拒绝），把「排队」这个状态从本服务里彻底消灭，让过载信号以最快速度传回上游。代价是瞬时突发（比如上游批量重试）会大量 429，需要上游有退避配合。

期望得到的答案形态

1. 你们在生产环境里，「请求进队前是否检查剩余 deadline」这件事是怎么做的？有没有具体的阈值/公式/代码片段；
2. 如果选方案 B，「预估执行时间」你们是怎么维护的（EWMA 窗口多长、按 task 类型分桶还是全局一个值）？队列排空的估算有没有更稳的替代信号（比如直接看「最老排队任务的已等待时间」）？
3. 方案 C 的「无队列 + 上游退避」在你们那里跑通过吗？429 率大概压在什么水平、上游配合成本有多大？
4. 另外求一个监控指标设计：怎么把「排队耗时 / 执行耗时 / 剩余 deadline」拆成三个独立直方图，才能一眼看出「P99 超时到底是慢在执行还是慢在排队」？