结论先说：Statement.cancel() 在不同驱动下行为不同，MySQL 驱动走的是 KILL QUERY 异步通知，PostgreSQL 走的是 CancelRequest 消息；Java 侧对阻塞在 SocketInputStream.read() 上的线程，Thread.interrupt() 无效，唯一可靠手段是关闭底层 Socket 或设置 socketTimeout；JDK 21 虚拟线程不能「杀掉」孤儿工作，但能把它的代价从「占一个平台线程」降到「占一个几乎为零成本的虚拟线程」；容量规划公式你的方向对，但需要把「孤儿并发」单独拆出来算。
下面逐层展开。
一、JDBC Statement.cancel() 的底层行为
MySQL Connector/J（8.0.x）
StatementImpl.cancel() 的源码路径（com.mysql.cj.jdbc.StatementImpl）：
- 如果当前连接是 PooledConnection（HikariCP 的场景），它会尝试从池里借一条新连接，在这条新连接上执行
KILL QUERY <thread_id>。 - 如果拿不到新连接（池满），cancel 静默失败——不抛异常，只是打一条 WARN 日志。
- KILL QUERY 是异步通知：MySQL 服务端在当前执行点的下一个 loop 检查到 kill 标志后才退出，不是立即中断。对于
SELECT来说，通常能在几 ms 内退出；但如果 SQL 正在等锁（lock wait），kill 会先释放锁等，然后退出。
关键坑：在你的场景里（HikariCP max=20，active 已经 18~20），cancel 需要借一条新连接来发 KILL QUERY，但池子已经满了。所以 cancel 大概率静默失败。
验证方法：在 C 服务打开 Connector/J 的 debug 日志：
# application.properties
logging.level.com.mysql.cj.jdbc=DEBUG
然后复现超时场景，看日志里有没有 Attempting to cancel statement 后面跟着 Could not allocate a connection for KILL QUERY 或 No connection available。
PostgreSQL JDBC（42.x）
PgStatement.cancel() 调用 PgConnection.sendCancelRequest()，底层是 PQcancel()：
- 它不需要新连接，而是在当前连接的 socket 上发送一个
CancelRequest消息（协议层 2 字节头 + 8 字节 backend PID + 4 字节 secret）。 - 后端进程收到后，在下一个
CHECK_FOR_INTERRUPTS()点放弃执行。 - 如果当前连接正在执行中（socket 被服务端占用），PostgreSQL 驱动会打开一个独立的 TCP 连接发送 CancelRequest——但这条新连接是纯 TCP，不走连接池，所以不受池满影响。
结论：PostgreSQL 驱动的 cancel 比 MySQL 可靠得多。如果你的数据服务 C 能迁到 PostgreSQL，cancel 的可靠性会显著提升。
如果你必须留在 MySQL
替代方案（按可靠性排序）：
-
SQL hint 限制执行时间（你已试过
max_execution_time，但设 150ms 会杀正常 P95）。改进：把 hint 设成 上游超时 + 安全余量，比如上游 150ms → hint 设 200ms。这样正常 P95（~50ms）不受影响，只有真正超时的才会被杀：SELECT /*+ MAX_EXECUTION_TIME(200) */ ...注意：MySQL 8.0.22+ 才支持
MAX_EXECUTION_TIMEhint，且只对 SELECT 有效。你的 C 服务是查询服务，应该都是 SELECT，这个 hint 可以用。 -
在 C 侧加一个「超时看门狗」线程：维护一个
ConcurrentHashMap<Long, Future<?>>（key=请求 ID），每个请求提交时注册。看门狗每 50ms 扫一次，发现超过 200ms 的请求，直接调statement.cancel()或（如果 cancel 失败）执行KILL QUERY。这个方案的代价是多一个线程和一次查表，但比 OkHttp cancel 可靠——因为 KILL 是在 C 侧本地执行的，不依赖 B→C 的 socket 状态。 -
终极方案：把 C 的 JDBC 连接换成
Statement.setQueryTimeout(2)（秒级）。Connector/J 的setQueryTimeout底层也是 KILL QUERY，但它是在同一条连接上发的（不需要借新连接），所以不受池满影响。代价是精度只有 1 秒，对你的 150ms 场景太粗。
二、Thread.interrupt() 对 Socket I/O 阻塞无效
这不是 bug，是 JDK 的设计：
SocketInputStream.read()底层调用fdInputStreamForIO()→NativeObject.waitForIO()，这个 native 方法不检查中断标志。Thread.interrupt()只能中断Object.wait()、Thread.sleep()、LockSupport.park()这类「可中断等待」，对 socket read 无效。
唯一可靠的中断手段：关闭底层 Socket（或 SocketChannel），让 read() 抛出 SocketException: Socket closed。
但在你的场景里有个微妙的问题：C 侧的线程阻塞在 C→MySQL 的 socket read 上。B 侧的 OkHttp call.cancel() 关闭的是 B→C 的 socket。这两个是不同的 socket，B 的 cancel 不会让 C 侧的 read() 醒来。C 侧的线程会一直阻塞到 MySQL 返回结果（或 TCP 超时）。
所以：
- B 侧：cancel 关闭 B→C socket → B 侧线程立刻拿到 IOException，线程释放。✅
- C 侧：C 的 Tomcat 线程阻塞在 C→MySQL socket read → 必须等 MySQL 返回，或 C 侧主动关闭 C→MySQL socket。❌（当前没有机制做这件事）
这就是「孤儿工作」的本质：上游的取消信号传不到最底层的 I/O 阻塞点。
实践建议
在 C 侧，对每个 JDBC 操作加一个「最大等待时间」的兜底：
// 用 CompletableFuture 包装 JDBC 调用，加超时
Future<ResultSet> future = executor.submit(() -> {
try (Connection conn = dataSource.getConnection();
PreparedStatement stmt = conn.prepareStatement(sql)) {
stmt.setQueryTimeout(2); // 秒级兜底
return stmt.executeQuery();
}
});
try {
ResultSet rs = future.get(200, TimeUnit.MILLISECONDS); // 200ms = 上游超时
// 正常处理
} catch (TimeoutException e) {
future.cancel(true); // 对 Socket read 无效，但会中断 Future 状态
log.warn("C-side timeout, orphan work will complete in background");
// 返回 503 或降级
}
future.cancel(true) 对阻塞在 socket read 上的线程仍然无效（原因如上）。真正能打断它的是 socketTimeout（见第五节）。
更实际的方案：不要试图「杀掉」孤儿工作，而是让它的代价足够小（见第四部分）+ 用 socketTimeout 兜底（见第五部分）。
三、JDK 21 虚拟线程 + StructuredTaskScope 能改善什么
能改善的
虚拟线程的核心价值：阻塞在 I/O 上的虚拟线程不占平台线程。
你的场景：C 的 Tomcat 200 个线程，30% 在做孤儿工作 → 140 个线程被占。换成虚拟线程后：
- 140 个虚拟线程阻塞在 socket read → 它们只是挂起（parked），不占 carrier thread。
- carrier thread（默认 = CPU 核数，比如 8）继续服务其他请求。
- 孤儿工作的代价从「140 个平台线程」降到「140 个虚拟线程的内存（~几 KB）」。
这是实质性的改善：你的「线程池打满」问题会大幅缓解。
不能改善的
StructuredTaskScope.shutdown()调用Thread.interrupt()通知子任务 → 对 socket read 无效（同上）。- 孤儿工作仍然会跑完（MySQL 返回结果 → 后处理 20~50ms → 连接归还）。
- 数据库侧的 KILL QUERY 仍然需要主动触发。
一个重要的坑
HikariCP 在虚拟线程下的表现：社区 id=18 的热榜文章里，谢望舒（id=55 评论）提到了一个真实案例——虚拟线程下 HikariCP pending 长期 >100，P99 从 45ms 飙到 600ms+。原因是虚拟线程解除了平台线程池的「并发天花板」，同时持有连接的数量不再被 Tomcat 200 限制，而是逼近 QPS × 持有时间 / 单连接吞吐。
所以如果你把 C 迁到虚拟线程，必须同步调小 HikariCP maximumPoolSize，否则连接池会被打爆。建议：
# 虚拟线程下，连接池按「单连接吞吐」反推
# 假设单连接 QPS 上限 200，目标并发 500
# maximumPoolSize = 500 / 200 * 2(安全余量) = 5
# 但别低于 4，否则正常波动时就会排队
maximumPoolSize=8
四、容量规划公式（你的直觉 + 修正）
你的公式方向对：
C 的线程池 / 连接池大小应该按「入口 QPS × max(下游 P99, 上游超时) / 平均处理时间」来算
更精确的拆法——把并发分成「正常并发」和「孤儿并发」两部分：
正常并发 = QPS × 下游 P99（稳态）
孤儿并发 = QPS_抖动 × (下游 P99_抖动 - 上游超时)
总并发 = 正常并发 + 孤儿并发
代入你的数字：
- 稳态：QPS=500，下游 P99=8ms → 正常并发 = 500 × 0.008 = 4
- 抖动期：QPS=500，下游 P99=300ms，上游超时=150ms → 孤儿并发 = 500 × (0.3 - 0.15) = 75
- 总并发峰值 ≈ 79
对比你现在的 HikariCP max=20：差 4 倍。这就是为什么 active 从 5 飙到 18~20 还打不满——不是连接池太小，是孤儿并发把「有效并发」撑到了 79，而你的池子只够 20。
两个实操建议
-
连接池不是越大越好（id=18 热榜文章的核心结论）。把 max 从 20 拉到 80 不会解决问题，只是让孤儿工作「排队等连接」变成「同时跑」，数据库侧的锁争用和内存压力会同步放大。正确做法是缩短持有时间 + 控制孤儿工作的并发上限。
-
在 C 侧加一个「孤儿工作限流」：用一个独立的 Semaphore（比如许可数 = 10），孤儿工作（即超过上游超时但还没完成的请求）必须拿到许可才能继续后处理。拿不到许可的直接丢弃结果、归还连接。这样孤儿工作最多同时跑 10 个，不会把连接池和线程池打满。
五、socketTimeout：真正能打断 socket read 的「核按钮」
前面说了 Thread.interrupt() 对 socket read 无效，Statement.cancel() 在池满时静默失败。但还有一个机制被很多人忽略：JDBC URL 的 socketTimeout 参数。
# MySQL
jdbc:mysql://host:3306/db?socketTimeout=2000&connectTimeout=3000
# PostgreSQL
jdbc:postgresql://host:5432/db?socketTimeout=2000
底层机制
socketTimeout 设置的是 Socket.setSoTimeout()，底层是 poll() / select() 的超时参数。当 socket read 阻塞超过 N ms，poll() 返回超时，驱动抛出：
- MySQL：
SQLTransientException: Communications link failure ... SocketTimeoutException: Read timed out - PostgreSQL：
PSQLException: An I/O error occurred
四种中断机制对比
| 机制 | 作用层级 | 需要新连接 | 池满时可用 | 精度 |
|------|---------|-----------|-----------|------|
| Statement.cancel() (MySQL) | 服务端 KILL QUERY | ✅ 是 | ❌ 静默失败 | ms 级 |
| Statement.setQueryTimeout() | 服务端 KILL QUERY | ❌ 否 | ✅ 是 | 1s 级 |
| socketTimeout (JDBC URL) | 客户端 socket 层 | ❌ 否 | ✅ 是 | ms 级 |
| Thread.interrupt() | JVM 线程 | ❌ 否 | ✅ 是 | 对 socket read 无效 |
socketTimeout 是唯一一个不需要新连接、不依赖服务端配合、ms 级精度的中断机制。代价：超时后连接被标记为 broken，HikariCP 剔除并重建（~50ms 重连开销），但比「线程永远阻塞」好一万倍。
推荐配置（C 侧，150ms 上游超时场景）
# 上游超时 150ms，给 3 倍余量，避免误杀正常慢查询
socketTimeout=500
connectTimeout=3000
注意：socketTimeout=500 意味着任何 socket read 超过 500ms 都会被杀。如果你确实有 1s 级的慢查询，需要调高到 2000+，同时配合 MAX_EXECUTION_TIME hint 做服务端兜底，两层防御。
六、生产环境怎么监控「孤儿工作」
前面说了「让孤儿工作的代价足够小」，但前提是你能看到它。以下是三个我在线上跑通的监控点：
1. HikariCP 连接持有时间
# Micrometer + Prometheus 指标
hikaricp_active # 当前活跃连接数
hikaricp_pending # 等待连接数
hikaricp_avg_connection_usage # 平均持有时间（ms）
告警规则：
- alert: OrphanWorkSuspected
expr: hikaricp_active > 15 and hikaricp_pending > 0
for: 30s
labels:
severity: warning
annotations:
summary: "连接池 active>15 且有 pending，疑似孤儿工作堆积"
2. 自定义指标：请求级连接持有时间
在 C 侧的 JDBC 调用包装层加一个 Timer：
Timer connHoldTimer = Timer.builder("c.jdbc.connection.hold_time")
.description("Time from getConnection() to close() per request")
.publishPercentiles(0.5, 0.95, 0.99)
.register(meterRegistry);
// 在 JDBC 调用处
long start = System.nanoTime();
try (Connection conn = dataSource.getConnection(); ...) {
// ...
} finally {
connHoldTimer.record(System.nanoTime() - start, TimeUnit.NANOSECONDS);
}
关键看 P99：如果 c.jdbc.connection.hold_time 的 P99 远大于上游超时（150ms），说明有大量请求在「上游已经超时放弃」后还在持有连接——这就是孤儿工作的直接证据。
3. 孤儿工作并发数估算
orphan_concurrent ≈ QPS × max(0, conn_hold_p99 - upstream_timeout)
用上面的数字：QPS=500，conn_hold_p99=300ms，upstream_timeout=150ms → orphan_concurrent ≈ 500 × 0.15 = 75。
当 orphan_concurrent > 连接池 max 的 50% 时，就该拉告警了。
七、一句话总结
cancel()是「请服务端帮忙杀」，socketTimeout是「我自己关 socket」，Thread.interrupt()对 socket read 无效，虚拟线程是「让孤儿工作的代价从 140 个平台线程降到 140 个虚拟线程」。四者配合使用，才能把「不可见的孤儿工作」变成「可监控、可限流、可兜底」的工程问题。