Java异常处理与K8S存活检查技巧

Java应用在K8S中频繁崩溃、健康检查误判、OOM无堆dump、日志缺失异常等“玄学”问题，根源往往不在业务代码或异常处理本身，而在于JVM容器化配置与K8S探针机制的错配——K8S只机械响应HTTP状态码、进程信号和响应延迟，对Spring的友好错误页、业务异常语义或默认健康端点完全“视而不见”；真正决定稳定性的，是那几行容易被忽略的关键细节：显式设置500状态码而非依赖/error端点、为JVM预留内存并启用容器感知、分离liveness/readiness检查路径、用exec探针替代脆弱的HTTP健康接口、确保PID 1是Java进程以正确接收SIGTERM……掌握这些底层协同逻辑，才能让Java从容活在云原生世界。

Spring Boot应用里，@ControllerAdvice捕获异常后K8S livenessProbe仍失败？

根本原因不是没捕获异常，而是HTTP状态码没改对。K8S默认把非2xx响应全当健康检查失败，哪怕你返回了友好的JSON错误页。

实操建议：

• @ControllerAdvice里用@ExceptionHandler处理全局异常时，必须显式设置response.setStatus(500)或返回ResponseEntity并指定HttpStatus.INTERNAL_SERVER_ERROR
• 不要依赖Spring Boot默认的/error端点——它返回404/500但HTML响应体，K8S探针只看状态码，不解析内容
• 存活探针路径建议单独暴露一个轻量接口（如/health/liveness），只做内存/线程池等本地检查，不走业务逻辑链路
• 若必须复用业务接口做探针，确保该接口在异常时返回明确的2xx状态码（比如200 OK带{"status":"degraded"}），并在livenessProbe中配置failureThreshold和periodSeconds容忍短暂波动

Java应用容器化后，OutOfMemoryError导致Pod反复重启，但日志里看不到堆dump？

因为JVM默认不会在容器内存限制下自动触发OOM dump，且K8S kill进程时可能直接终止JVM，来不及写文件。

实操建议：

• 启动参数加-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/heap.hprof，同时挂载emptyDir卷到/tmp，避免dump写入不可写的根文件系统
• 容器resources.limits.memory设为1Gi时，JVM堆最大值（-Xmx）别直接设成1G——要预留至少200MB给元空间、直接内存、JIT等，推荐-Xmx768m
• K8S的livenessProbe别用httpGet检查/actuator/health，它可能在GC卡顿期间返回503，误判为故障；改用exec探针执行ps -p $PID确认Java进程是否存活更可靠
• 开启JVM容器感知：-XX:+UseContainerSupport -XX:MaxRAMPercentage=75.0，避免JVM按宿主机内存估算堆大小

Spring Boot Actuator的health端点返回DOWN，但业务请求完全正常？

这是Actuator默认聚合所有HealthIndicator的结果，只要有一个（比如数据库连接池耗尽、Redis超时）就整体标为DOWN，而K8S存活探针会因此杀掉Pod。

实操建议：

• 区分liveness和readiness：用/actuator/health/liveness只检查JVM本地状态（线程数、内存使用率），用/actuator/health/readiness检查下游依赖
• 禁用非关键依赖的健康检查：在application.yml里配management.health.redis.show-details=never或直接移除spring-boot-starter-data-redis的自动配置
• 自定义LivenessStateHealthIndicator，检查Runtime.getRuntime().freeMemory()是否低于阈值，比单纯依赖DB连接更贴近真实存活条件
• 别让health端点调用任何远程服务——它本该是毫秒级响应，否则会拖慢K8S探针频率，引发级联失败

Java应用在K8S里频繁CrashLoopBackOff，kubectl logs -p却显示“Started Application”，没异常堆栈？

说明进程启动成功，但随后被外部信号杀死。最常见的是JVM没收到SIGTERM，直接被K8S发SIGKILL强杀，导致来不及打印Shutdown Hook日志。

实操建议：

• 确保Dockerfile里用exec java ...启动（不是java ... &），否则PID 1不是Java进程，无法接收信号
• 加JVM参数-XX:+PrintGCDetails -XX:+PrintGCTimeStamps，GC日志会输出到stdout，即使应用崩溃也能从kubectl logs看到最后几秒发生了什么
• 检查livenessProbe.initialDelaySeconds是否太小——Spring Boot启动慢（尤其带Hibernate初始化），探针在应用Ready前就失败，反复重启
• 在preStop生命周期钩子里加sleep 10，给JVM留出时间执行Shutdown Hook和优雅关闭线程池

Java异常本身不难捕获，难的是让容器平台“理解”你的异常语义。K8S只认状态码、进程退出码、HTTP响应延迟这些硬指标，业务层抛出的BusinessException对它毫无意义。真正卡住人的，永远是JVM参数和K8S探针配置之间那几行容易漏掉的细节。

本篇关于《Java异常处理与K8S存活检查技巧》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！