1.背景因为Oracle宣布OracleJDK停止免费用于商业用途。经过评估，公司法务部担心以后会惹到广思，于是开始了JDK的升级——将Oracle的所有服务修改为OpenJDK。上周微服务JDK升级，本来只是一个基础组件的升级。由于业务代码没有变化，所以问题不大。但万万没想到，升级开始后，不断重启服务的异常想象会陆续出现。怎么了？2、问题暴露升级镜像后，java服务频繁重启，服务对外接口处于半不可用状态。具体表现为接口请求失败率5-10%（该接口对应的数据看板主要供内部人员使用，第一时间没有止损的原因）3.排查异常另外与更新基础JDK镜像相比，本次升级既没有改动业务代码，也没有修改配置。是什么原因？怀着十分迷茫的心情，我和团队开始了漫长的异常调查之旅。1）当时服务重启的时候，第一感觉是启动时间比较长，检测接口超时超过一定阈值，导致重启。于是在出现异常重启后的第一个小时内，我把检测超时时间从30s增加到60s，发现没有效果，于是又增加到90s，可惜还是不行，服务还是有想象空间的一直在重启。2）接下来怀疑是不是pod所在的host内存不足导致的？于是登录主机查看内存$free-m总内存128g，可用内存60多g，主机物理内存充足。3）主机内存也正常。请问JVM监控有没有明显的异常提示？此时，距离升级已经过去了2个小时。于是打开业务jvm的heap和gc频率监控板，发现fullgc比较规律，并没有详细的异常信息。此时，距离升级已经过去了将近3个小时。实在是找不到任何线索，只能回滚吗？4）最后想到查看系统级的日志，看看有没有异常提示，终于找到了OOM错误日志。dmesg-T结论：这里的问题很明显。pod内部的java服务异常申请内存超过内存限制（pod配置的内存限制为4g），触发系统killer保护进程kill掉pod进程。4、虽然根因定位确定是OOM引起的，但是为什么升级JDK会导致OOM？通过jinfo命令查看JVM启动参数后，终于找到了根源。原来，服务的重复OOM被kill掉是因为“-XX:MaxHeapSize”参数无效，导致Java进程使用默认值32g（物理机的1/4），超过了限制pod分配的8g。那为什么“-XX:MaxHeapSize”参数会失效呢？那是因为新镜像给JAVA_OPS赋了一个默认值，它覆盖了之前启动参数JAVA_OPS的值。要解决这个问题，需要取消OpenJDK镜像默认赋值给JAVA_OPS。jinfo-flags1再次确认MaxHeapSize的默认值。通过执行以下命令，可以看到MaxHeapSize的默认值确实是系统总内存的1/4。java-XX:+PrintFlagsFinal-版本|grepMaxHeapSize5.总结回顾结合本次发布引起的异常，做一个回顾，主要包括问题发生的时间和修复完成的时间，以及失败的原因和优化措施。见下表：
