K8s 里 JVM Full GC 假死被 Kafka 当"真死"踢出组：session.timeout.ms 到底该按最大 STW 还是按故障检测速度来定？

背景

• Kafka 3.4（3 broker KRaft），topic order-event 48 分区，消费组 10 实例（K8s Deployment，3 副本 × 多 AZ，每实例约 5 分区）。
• 消费端是 JVM，存在偶发 Full GC（G1 晋升失败 / 大对象），单次 STW 实测 3~9s，一天 1~5 次。
• 我参考社区里 cooperative + static membership 的方案做了配置（见引用 1）：CooperativeStickyAssignor + group.instance.id 固定 + rebalance.timeout.ms=60s；心跳侧 session.timeout.ms=10s、heartbeat.interval.ms=3s、max.poll.interval.ms=300s；broker group.min.rebalance.interval.ms=5s。

现象

1. 每次 Full GC 超过 10s，broker 就判该实例死亡，触发一次组内 rebalance（cooperative 下只迁该实例持有的 ~5 分区），中断 3~8s。
2. 更糟的是：因为用了 static membership，GC 结束后实例还活着，但它的分区已被分走；要等下一次 rebalance 才收回，于是出现"GC 结束后 30s~2min 该实例空转不消费、分区被别的实例扛着"的窗口。
3. 一天累计 3~5 次这种"假死"rebalance，下游 P99 周期性抖动。

已尝试

• 把 session.timeout.ms 从 10s 调到 30s：rebalance 次数降了，但真死实例（OOMKilled）要等 30s+ 才被踢，故障恢复明显变慢——两头不讨好。
• 调 JVM（G1 调大 Heap、MaxGCPauseMillis=200、限制 Humongous）：Full GC 从 9s 降到 3~4s，但仍有 1~2 次/天超 10s。
• 加了 group.min.rebalance.interval.ms 防抖：治标不治本。

期望得到的答案形态

1. session.timeout.ms 到底该按"最大可容忍 STW"还是按"故障检测速度"来定？有没有经验公式（比如 ≈ 2×(maxGC + heartbeat) 这种量级）？
2. broker / group-coordinator 端有没有机制能区分"心跳断但进程还活"（GC 假死）和"进程真死"？static membership 的 rebalance.timeout 在这里到底起什么作用？
3. 有没有更工程化的做法：消费端在预测到长 GC 前主动发"我要假死"的延长信号？还是干脆用 K8s liveness 探针做兜底、把"判死"权从 broker 挪到 K8s，两者解耦？

想听听踩过这坑的同学给的具体配置数字 + 取舍依据。