微服务容器线程耗尽时，pod 仍为 running 但 readinessprobe 持续失败、ready=false、流量被 service 自动摘除；典型迹象包括线程数逼近 cgroup 限制、健康端点超时无报错、日志中现线程池拒绝或 goroutine 堆积；需通过 jstack/ps/pprof 分析阻塞源，并调优 probe 配置与线程池大小。
微服务容器内部线程耗尽时，应用可能仍处于 Running 状态，但已无法响应健康检查请求——表现为 ReadinessProbe 持续失败、Pod Ready=false、流量被 Service 自动摘除。这类问题隐蔽性强，日志中往往无明显报错，需结合资源行为与探针逻辑交叉验证。
确认线程耗尽的典型迹象
线程耗尽不等于 CPU 打满，而是应用无法创建新线程（如 Java 的 java.lang.OutOfMemoryError: unable to create new native thread，或 Go 的 goroutine 调度阻塞）。关键线索包括：
- 容器内进程线程数接近系统限制：执行
kubectl exec -it <pod> -- sh -c 'cat /proc/1/limits | grep nproc'</pod>查看最大进程/线程数；再用ps -eLf | wc -l统计当前线程总数，若接近上限（如 1024 或容器 cgroup 限制值），即为高危信号 - 健康检查端点响应极慢或超时，但 HTTP 状态码不是 500（如返回 0 byte、连接挂起、或 probe 日志显示 timeout）
- 应用日志中出现大量线程池拒绝、定时任务堆积、异步回调未触发等间接表现
检查探针配置是否放大了线程压力
不当的就绪探针本身会加剧线程耗尽，尤其当探测频率高、路径涉及重负载逻辑时：
- 避免将
/health探针指向实际依赖数据库或远程调用的端点（如 Spring Boot 默认/actuator/health在某些 profile 下会检查所有组件）；应使用轻量级端点（如/health/ready，仅检查内存与本地状态） - 确认
periodSeconds不小于 10 秒，timeoutSeconds不小于 3 秒——过短的超时会导致 probe 频繁重试，持续抢占线程资源 - 若应用启动阶段需预热（如 JVM JIT、连接池填充），确保
initialDelaySeconds足够长（建议 ≥60 秒），防止 probe 在线程尚未稳定时介入
定位线程占用源头
在容器内快速抓取线程快照，识别高消耗线程：
- Java 应用：执行
kubectl exec -it <pod> -- jstack 1 > jstack.out</pod>，查看线程堆栈中是否存在大量WAITING或BLOCKED状态，重点关注线程池满、锁竞争、DNS 解析阻塞等模式 - Go 应用：运行
kubectl exec -it <pod> -- kill -SIGUSR1 1</pod>（若启用 runtime/pprof），再通过/debug/pprof/goroutine?debug=2获取完整 goroutine 列表 - 通用方法：用
top -H -p $(pgrep -f 'your-app.jar')查看各线程 CPU/运行时间，结合cat /proc/<tid>/stack</tid>分析阻塞点
验证并缓解线程资源瓶颈
临时绕过问题并验证判断：
- 降低探针频率或临时禁用 readinessProbe（仅用于诊断），观察 Pod 是否自动恢复 Ready 状态
- 进入容器，手动 curl 健康端点多次：
kubectl exec -it <pod> -- curl -v http://localhost:8080/health</pod>，对比首次与后续响应时间变化——若越调越慢，大概率是线程池或连接池泄漏 - 检查容器是否受 cgroup 限制：运行
kubectl exec -it <pod> -- cat /sys/fs/cgroup/pids.max</pod>，若为小数值（如 512），需在 Pod spec 中显式设置resources.limits.pids（Kubernetes 1.20+ 支持）或调整应用线程池大小匹配该上限
