就绪检查应打 /actuator/health/readiness 端点，它专为判断依赖就绪与初始化完成设计；存活检查应打 /actuator/health/liveness 或极简端点，仅验证应用自身是否僵死，严禁查数据库等外部依赖，避免误重启。
OpenJDK 应用（比如 Spring Boot）在 Kubernetes 中做健康检查时，readinessProbe 和 livenessProbe 的核心区别不在 JVM 或 OpenJDK 本身，而在于你暴露的 HTTP 端点语义和探测目的——前者决定“能不能收流量”，后者决定“要不要重启容器”。
就绪检查（readinessProbe）该打哪个 endpoint？
就绪检查必须反映应用是否已加载完所有依赖、完成初始化、能安全处理请求。Spring Boot Actuator 默认提供两个独立 endpoint：
-
/actuator/health/readiness：专为就绪设计，会检查数据库连接、消息队列连通性、缓存服务等外部依赖是否 ready -
/actuator/health（或/actuator/health/liveness）：默认只检查进程存活，不查依赖
如果你用的是 Spring Boot 2.3+，readiness 和 liveness 是分离的；老版本需手动配置 HealthIndicator。别把 /actuator/health 同时配给两者，否则就绪失败会误触发重启。
存活检查（livenessProbe）为什么不能查数据库？
存活检查的目标是发现不可恢复的僵死状态，比如线程死锁、GC 持续卡顿、主线程挂起。它必须轻量、快速、只依赖应用自身状态：
- 查数据库会导致 false positive：DB 临时抖动 → 就绪失败 → 流量剔除（合理），但若配到
livenessProbe→ 容器被杀 → 重启 → 再次连 DB 失败 → 循环崩溃 - 推荐用
/actuator/health/liveness（Spring Boot 2.3+）或自定义一个只返回200的极简 endpoint，内部不做任何 I/O - 避免设置
initialDelaySeconds过短：JVM 启动 + Spring 初始化常需 10–30 秒，设成 5 秒大概率导致启动期就被 kill
startupProbe 能解决什么实际问题？
OpenJDK 应用冷启动慢（尤其带大量反射、类扫描、Hibernate 初始化的场景），livenessProbe 和 readinessProbe 一上来就探，容易误判。这时加 startupProbe 是关键：
- 它只运行一次，成功后才启用另外两个 probe
- 典型配置：
httpGet打/actuator/health，failureThreshold: 30，periodSeconds: 10→ 给足 5 分钟启动时间 - 没配
startupProbe时，只能靠拉长initialDelaySeconds，但这样会让真正出错的容器也延迟被发现
最容易被忽略的一点：Spring Boot 的 management.endpoint.health.show-details 默认是 NEVER，这意味着 /actuator/health 返回的 JSON 里不带具体组件状态——readinessProbe 即使连上了，也可能因无法判断 DB 是否 ready 而永远卡在 OUT_OF_SERVICE。务必设成 WHEN_AUTHORIZED 或 ALWAYS（配合权限控制）。
