容器“假死”本质是探针仅验证端口或进程存活，无法反映业务真实处理能力；需结合语义化健康接口、进程状态深度监控（z/d状态、cgroup资源压力）及业务级心跳自检三重机制精准识别。

心跳检测显示正常但容器内进程实际已卡死，本质是“探针只管通路、不管业务”——它验证的是端口可达或命令返回码，而非服务真实处理能力。要真正解决这个问题，得从探针设计、进程状态监控和业务级自检三方面入手。

别只用基础HTTP/TCP探针

默认的 curl -f http://localhost:8080/health 或 TCP 连通检查，只要端口开着、进程没退出，就认为健康。但很多卡死场景下，进程仍占着端口（比如陷入 D 状态、goroutine 全阻塞、线程池耗尽），HTTP 服务器能 accept 连接却无法 dispatch 请求。

• 改用带语义的 HTTP 探针：路径指向真实业务逻辑接口，比如 /api/v1/status?full=true，该接口内部需主动检查数据库连接、缓存连通性、关键队列长度
• 避免静态响应：不要写 return "OK"，而应执行一次最小闭环操作（如查一条带索引的记录 + 写入临时日志）
• 对非 HTTP 服务（如消息消费者），用 exec 探针调用轻量脚本：sh -c 'pgrep -f "consumer.py" | wc -l | grep -q "1" && timeout 3s curl -sf http://localhost:9000/metrics | grep -q "processed_total"

监控容器内真实进程状态

仅靠 docker ps 显示 UP 不可信。需深入容器内部确认主进程是否真在工作：

• 进容器看进程树：docker exec -it [容器ID] ps auxf，重点找是否有大量 Z（僵尸）或 D（不可中断睡眠）状态进程
• 查系统调用阻塞：docker exec [容器ID] cat /proc/1/stack，若输出停留在 call_rwsem_down_read_failed 或 nfs_wait_bit_killable，说明卡在文件系统或网络挂载上
• 看线程数是否异常：docker exec [容器ID] ls /proc/1/task | wc -l，对比正常值；Java 应用可加 -XX:+PrintGCDetails 观察 GC 是否频繁 Full GC 后停顿

加一层业务心跳+超时兜底

在应用代码里埋点，让健康接口本身成为“业务脉搏”：

• 启动时记录 startup_time = time.time()，健康接口返回当前时间与 startup_time 的差值；若超过 30 分钟无更新，说明主线程可能卡住
• 用独立 goroutine / thread 每 5 秒写一个时间戳到共享内存或文件，健康接口读取并校验该时间戳是否在 10 秒内更新过
• 配合 Docker 的 healthcheck 配置超时和重试：timeout: 5s; retries: 3; start_period: 60s，避免因瞬时抖动误判

用 cgroup 实时感知资源僵局

很多卡死源于资源调度冻结，比如 CPU 被限死、内存接近 OOM 边界但未触发 killer：

• 宿主机上查容器 cgroup 内存压力：cat /sys/fs/cgroup/memory/docker/[容器ID]/memory.pressure，持续 high 表示内存严重争抢
• 看 CPU throttling：cat /sys/fs/cgroup/cpu/docker/[容器ID]/cpu.stat | grep throttled，若 throttled_time 持续增长，说明进程被 cgroup 强制节流，响应必然迟滞
• 结合 Prometheus + cAdvisor 抓取这些指标，设置告警：当 container_cpu_cfs_throttled_periods_total > 100 且 container_memory_usage_bytes / container_spec_memory_limit_bytes > 0.95 同时成立，触发人工介入