容器“假死”本质是探针仅验证端口或进程存活，无法反映业务真实处理能力；需结合语义化健康接口、进程状态深度监控（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同时成立，触发人工介入
