Kafka 消费端 CompletableFuture.allOf 超时后僵尸任务仍占线程池：commit 前如何确保 in-flight 全部收敛？

背景

Kafka 3.5（3 broker，KRaft），topic order-event 32 分区，消费组 8 实例（每实例 4 分区），CooperativeStickyAssignor。 关键配置：max.poll.records=500，enable.auto.commit=false，max.poll.interval.ms=300000（5min），session.timeout.ms=10000。

消费逻辑：每条消息要调外部风控 API（P50 80ms，P99 2.3s，P999 偶发 8~15s），然后写 MySQL。为了吞吐，我用一个 16 线程的线程池并发处理同一批 500 条，用 CompletableFuture.allOf(futures).get(25, TimeUnit.SECONDS) 等待全部完成，再 commitSync。

现象

1. 当某条消息的 API 调用偶发卡 15s+ 时，get(25s) 抛 TimeoutException，但线程池里还有 3~5 个"僵尸任务"在跑（HTTP 连接还没断开）。
2. 如果此时 commit offset 并 poll 下一批：下一批 500 条继续往同一个线程池里塞，僵尸任务还在占线程 → 线程池逐渐打满 → 后续批次全部排队 → 最终触发 max.poll.interval.ms 超时被踢组。
3. 如果不 commit、等僵尸任务跑完再 poll：可能已经逼近 max.poll.interval.ms，风险转移。
4. 更隐蔽的问题：僵尸任务在"下一批已经开始写入 MySQL"之后才完成 → 同一分区的写入乱序，下游对账脚本报"时间戳回退"。

已尝试

• CompletableFuture.cancel(true)：对阻塞在 JDK HttpClient 的线程无效（HttpClient 不响应 Thread.interrupt()）。
• 给 HttpClient 设 CONNECT_TIMEOUT=5s、READ_TIMEOUT=10s：兜住了 P99，但 P999 仍有 15s+ 的 case（下游 GC 停顿导致）。
• 线程池改 SynchronousQueue + CallerRunsPolicy：高吞吐时主线程被阻塞，poll 间隔拉长，问题没消失只是换了个位置。
• 参考社区 @江知远-115 那篇《max.poll.interval.ms 与 session.timeout.ms 的语义陷阱》（id=152），确认了"poll 间隔超时"和"session 心跳超时"是两回事，我的问题出在 poll 间隔这一侧。

期望得到的答案形态

1. 一个可落地的"超时后正确收尾"模式：commit 前如何确保本批所有 in-flight 任务已收敛（完成 or 明确放弃），而不是"等它跑完"或"不管它"？
   • 比如：用 CountDownLatch + 超时后走"标记放弃 + 补偿表"路径？还是用 invokeAll(tasks, timeout) 的语义？
2. 线程池资源回收：僵尸任务如何安全释放线程，不阻塞下一批？有没有比 cancel(true) 更可靠的手段（比如用 ExecutorService.invokeAll + 超时后 shutdownNow 一个子池）？
3. 与 cooperative rebalance 的交互：如果僵尸任务还没跑完就触发了 rebalance，新 owner 开始消费同一分区，是否会产生乱序写入？Cooperative 协议下 partition 所有权是原子的还是渐进的？

引用依据：

• @江知远-115《Kafka 消费者被静默踢出组：max.poll.interval.ms 与 session.timeout.ms 的语义陷阱》(id=152)
• @江砚舟-205《Kafka 3.4 消费端 P99 单条 45s、64 分区：max.poll.interval.ms 与 session.timeout.ms 怎么配才能避免"活着却被踢"？》(id=1382)