容器启动超时主因是依赖就绪判断逻辑错误，而非jvm问题；k8s探针需合理配置failurethreshold与periodseconds组合，并区分liveness/readiness端点，java应用应通过框架原生机制（如applicationreadyevent）控制就绪状态，避免sleep野路子。
容器启动超时不是JVM问题，是依赖就绪判断逻辑问题
Java应用在Docker或K8s中“启动超时”，90%以上跟JVM本身无关，而是服务启动流程卡在等待外部依赖（数据库、配置中心、其他微服务）就绪上。K8s的livenessProbe或startupProbe默认等待时间太短，而Spring Boot等框架又默认同步初始化所有Bean，一卡就超时被杀。
startupProbe里别只看timeoutSeconds，得配failureThreshold和periodSeconds
单纯调大timeoutSeconds没用——它只控制单次探测的最长等待时间，真正决定“总共等多久”的是failureThreshold × periodSeconds。比如：
-
startupProbe: { failureThreshold: 30, periodSeconds: 10, timeoutSeconds: 5 }→ 最多等300秒 -
startupProbe: { failureThreshold: 10, periodSeconds: 2, timeoutSeconds: 1 }→ 最多等20秒，哪怕应用实际要45秒才ready
生产环境建议至少设failureThreshold: 60、periodSeconds: 5，覆盖JVM类加载+Spring上下文刷新+连接池预热全链路。
Java端必须暴露/actuator/health端点并区分LIVENESS和READINESS
K8s探针依赖HTTP健康检查，但默认/actuator/health返回200不代表服务真能处理请求。Spring Boot 2.3+起必须显式启用两个端点：
management.endpoint.health.show-details=when_authorizedmanagement.endpoints.web.exposure.include=health,liveness,readiness-
startupProbe应指向/actuator/liveness（只确认进程存活） -
readinessProbe应指向/actuator/readiness（确认可接收流量）
否则K8s可能把还没连上DB的实例提前加入Service Endpoint，导致503。
别信“加个sleep 30s”这种野路子
在ENTRYPOINT里写sleep 30 && java -jar app.jar看似简单，实则破坏了K8s对进程生命周期的管理：容器PID 1变成shell，JVM变成子进程，OOM时K8s杀不掉真正占内存的Java进程；且无法响应SIGTERM优雅停机。
正确做法是让Java应用自己控制就绪状态：
- Spring Boot：用
@EventListener(ApplicationReadyEvent.class)触发自定义就绪逻辑 - Quarkus：启用
quarkus-smallrye-health并实现LivenessCheck/ReadinessCheck - 裸Spring：通过
SmartLifecycle接口延迟发布服务
复杂点在于：健康检查逻辑必须能区分“暂时性失败”（如DB连接池正在重试）和“永久性故障”（如配置错误），否则探针会持续误判。
