根本原因是k8s livenessprobe仅依据http状态码判断健康，非2xx即失败；需在@controlleradvice中显式设500状态码或返回responseentity，避免依赖默认/error端点。
Spring Boot应用里，@ControllerAdvice捕获异常后K8S livenessProbe仍失败？
根本原因不是没捕获异常，而是HTTP状态码没改对。K8S默认把非2xx响应全当健康检查失败，哪怕你返回了友好的JSON错误页。
实操建议：
立即学习“Java免费学习笔记（深入）”；
-
@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，来不及写文件。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 启动参数加
-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。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 区分
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日志。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 确保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探针配置之间那几行容易漏掉的细节。
