OpenShift中pod发生OOM异常后不重启，如何关闭健康端点触发重启

问题根因 #

1. 异常捕获范围不全：OutOfMemoryError属于Error类，不是Exception的子类，你现有Consumer代码里只捕获了Exception，无法捕获OOM错误
2. 线程残留导致JVM不退出：HTTP服务默认运行在非守护线程，哪怕运行consumer的主线程因为未捕获的OOM崩溃，HTTP线程仍会继续运行，JVM不会主动退出，所以shutdownHook永远不会触发，健康检查持续返回200
3. 核心业务退出无兜底：consumer作为核心业务逻辑，退出后没有强制触发健康状态更新和资源回收的逻辑

解决方案 #

方案一：代码逻辑修复（优先实现） #

1. 调整主流程兜底逻辑
   给主函数的consumer.run()调用加外层try-finally，确保无论consumer因为任何原因退出，都主动标记健康状态为死、关闭HTTP服务、强制退出JVM：

fun run() {
    val consumer = createKafkaConsumer()
    val server = buildServer(log)
    val future = server.start()
    future.join()
    Runtime.getRuntime().addShutdownHook(
        Thread {
            log.info("Closing down...")
            server.close()
            healthService.die()
        }
    )
    // 新增外层兜底逻辑
    try {
        consumer.run()
    } finally {
        log.info("Consumer exited, triggering pod restart...")
        healthService.die()
        runCatching { server.close() } // 忽略关闭过程中可能抛出的异常
        System.exit(1) // 强制退出JVM，避免线程残留
    }
}

2. 扩大Consumer异常捕获范围
   将Consumer的捕获范围从Exception改为Throwable，确保包括OOM在内的所有错误都能被捕获到，留下错误日志方便排查：

class Consumer() {
    val cache = Cache()
    val name = "myConsumer"
    fun run() {
        try {
            val pollDuration = config.kafka.pollDurationSeconds
            while (true) {
                val records = consumer.poll(Duration.ofSeconds(pollDuration))
                addToCache(records)
            }
        } catch (e: Throwable) { // 修改捕获范围为所有Throwable
            log.error("Unexpected event happened. e=$e", e)
        } finally {
            log.info("Closing down $name consumer...")
            runCatching { consumer.close() }
            runCatching { cache.close() }
        }
    }
}

修改后只要consumer退出，不管是正常还是异常，都会触发健康状态更新为dead，返回503错误，OpenShift的liveness探针检测到失败后就会触发pod重启，就算HTTP服务没来得及关闭，探针失败也会触发重启逻辑。

方案二：JVM参数兜底（必加，极端场景保险） #

给JVM添加启动参数，OOM发生时直接强制杀掉进程，避免代码逻辑因为内存不足无法执行的极端情况：

-XX:OnOutOfMemoryError="kill -9 %p"

这个参数是JVM内置的OOM兜底机制，只要发生OOM错误，就会直接执行指定命令杀死当前进程，进程退出后OpenShift会自动检测到pod异常，触发重启，完全不需要依赖业务代码的执行逻辑。

额外优化建议 #

你现在liveness和readiness探针共用同一个/health端点，建议拆分：

• readiness探针用来判断服务是否准备好接收流量，返回alive的时候才接入流量
• liveness探针用来判断服务是否存活，除了看静态状态，还可以加consumer的心跳检测：consumer每轮poll成功后更新一次心跳时间，liveness检查时如果心跳时间超过阈值（比如2倍poll间隔）就返回503，避免consumer假死但没抛出异常的场景。

内容的提问来源于stack exchange，提问作者hermanjakobsen