内存泄漏导致中间件“假活”，需配置业务感知型livenessprobe：检查真实业务路径、按启动特征调优参数、协同readinessprobe摘流，并通过stress-ng压测验证探针有效性。
内存泄漏导致中间件“假活”——进程还在，但响应变慢、超时、卡死，是生产中最隐蔽也最危险的问题之一。LivenessProbe 不是万能药，但配得对、用得准，就能在服务彻底不可用前秒级触发重启，把影响控制在单实例内。
关键：让探针真正感知业务层僵死
很多团队只配置了基础 HTTP 探针，却忘了中间件（如 Kafka Connect、Nginx 反向代理、Spring Boot Admin Server）常因 GC 阻塞或线程池耗尽而无法处理新请求，此时 /healthz 仍可能返回 200——因为健康接口本身轻量、不压测资源。必须让探针检查真实业务路径：
- 不要只查
/actuator/health，改用带业务语义的端点，例如/actuator/health?show-details=always并解析响应体中"diskSpace"或"db"子项状态 - 对代理类中间件（如 Envoy、Traefik），探测应走真实 upstream 路由，比如
GET /ping?backend=auth-service，避免绕过后端连接逻辑 - Java 中间件可暴露 JMX 指标检查点，用
Exec探针调用jcmd $PID VM.native_memory summary，当 committed 内存持续 >90% 且 5 分钟内无 GC 回收时主动失败
参数设置要匹配中间件启动与退化特征
默认 10 秒一检、3 次失败即重启，对慢启动或高负载中间件极易误杀。需按实际行为调优：
-
initialDelaySeconds：设为中间件冷启动完成时间 + 20%，例如 Kafka Connect 加载 connector 配置平均耗时 48 秒，建议设为
60 -
periodSeconds：内存泄漏通常有渐进过程，太密（如 5 秒）易受瞬时 GC 影响；建议设为
15~30，兼顾灵敏度与稳定性 -
failureThreshold：不设为默认 3。若探测路径含远程依赖（如 DB 连接池检测），建议提高到
5，避免网络抖动引发连锁重启
配合 readinessProbe 切断流量再重启
光靠 liveness 重启不够——新 Pod 启动瞬间若直接承接全量流量，可能因初始化未完成而雪崩。必须协同使用 readinessProbe：
- readiness 探针检查更轻量的就绪信号（如本地端口监听、临时文件存在），确保容器已进入运行态
- liveness 探针检查更重的业务健康（如下游连通性、内存水位、请求 P95 延迟），专治“挂起”
- 两者 failureThreshold 建议错开：readiness 失败仅摘流，liveness 失败才重启，避免“边重启边导流”的混乱
验证是否真生效：三步快速压测
上线前务必模拟内存泄漏场景验证闭环：
- 用
stress-ng --vm 1 --vm-bytes 2G --timeout 5m在容器内制造内存压力 - 观察
kubectl describe pod xxx中Liveness行是否出现reason: Liveness probe failed和Restart Count上升 - 检查服务日志是否在重启前后出现 OOMKilled 或长时间 GC pause 记录，确认是探针主动干预而非系统 Kill
