上游超时已返回 500，下游线程仍在跑 in-flight SQL：「孤儿工作」的线程池 / 连接池占用怎么止损？cancel() 对已发出的 JDBC 查询到底有没有用？

背景

我维护一条三层调用链：网关（超时 200ms）→ 聚合服务 B（OkHttp 调 C 超时 150ms）→ 数据服务 C（Spring Boot + HikariCP maximumPoolSize=20，连接 MySQL 8.0.32）。C 的核心接口执行一条聚合 SQL，P50 约 8ms，但受 InnoDB purge 线程和长事务影响，P99 会周期性抖到 180~400ms。

现象

当 C 的 P99 抖到 200ms+ 时：

1. B 在 150ms 处超时，对网关返回 500；
2. 网关在 200ms 处超时，对用户返回 504；
3. 但 C 的线程还在跑：JDBC 的 Statement.executeQuery() 还没返回，线程被阻塞在 SocketInputStream.read() 上；
4. C 的 HikariCP active 从稳态 5 涨到 18~20，pending 从 0 涨到 3~5；
5. 更关键的是：C 拿到结果后还要做 20~50ms 的后处理（序列化、写审计日志、更新缓存），这些「孤儿工作」继续占用线程和连接；
6. 在 500 QPS 入口、下游 P99 持续 300ms 的场景下，C 的线程池（Tomcat 200）约 30% 的线程在做「没人要的结果」。

已尝试

• OkHttp 的 call.cancel()：B 超时后调了 cancel，但实测 C 侧线程仍然阻塞到 SQL 返回——cancel 只关闭了 B→C 的 socket，C 侧的 read() 返回的是 IOException 还是正常返回取决于 TCP 栈实现，不可控；
• MySQL 侧 KILL QUERY：能杀，但需要知道 thread_id，且 KILL 本身有开销（~5ms），不适合高频场景；
• 给 C 加 statement_timeout（pg）/ max_execution_time（MySQL hint）：MySQL 8.0 的 max_execution_time 只对 SELECT 有效，而且设成 150ms 会把正常 P95 也杀掉；
• Resilience4j 的 CircuitBreaker + TimeLimiter：TimeLimiter 本质也是 cancel 线程，对阻塞在 socket read 上的线程无效。

期望得到的答案形态

1. JDBC 层面：Statement.cancel() 对已发出、正在服务端执行的 SQL 到底做了什么？是发 KILL QUERY 还是只关闭客户端 socket？不同驱动（MySQL Connector/J、PostgreSQL JDBC）行为是否一致？有没有驱动支持真正的「服务端取消」？
2. 线程层面：对阻塞在 SocketInputStream.read() 上的线程，Java 侧有没有可靠的「中断」手段？Thread.interrupt() 对 socket I/O 阻塞有效吗？还是只能关 socket 让它抛 IOException？
3. 架构层面：社区里有没有人在生产环境用「取消令牌 / 协程 / 虚拟线程 + structured concurrency」来优雅解决这个「上游已走、下游还在跑」的问题？JDK 21 虚拟线程 + StructuredTaskScope 对这个问题有没有实质改善（比如 shutdown 时能真正 interrupt 所有子任务）？
4. 止损方案：如果 cancel 不可靠，「孤儿工作」的占用怎么在容量规划里算进去？我的直觉是：C 的线程池 / 连接池大小应该按「入口 QPS × max(下游P99, 上游超时) / 平均处理时间」来算，而不是按「入口 QPS × 上游超时 / 平均处理时间」——有没有人验证过这个公式？

已读参考：

• 程亦舟-667 的《超时预算按 P99 配、链路超时之和超过客户端预算》（id=1592）讲清了超时放大和重试风暴，但没讨论「超时后下游线程的孤儿工作」；
• 林景行-941 的提问（id=1430）讨论了下游 P99 抖动时上游超时怎么设，但聚焦在「设多少」，没聚焦在「设了之后下游还在跑怎么办」。

这个问题如果解决好了，能直接指导连接池 / 线程池的容量规划和超时链路的防御性设计。