服务升级前先做哪些确认跨 JDK 升级不是换掉基础镜像、看到服务能启动就结束。JDK、GC、框架、字节码工具和容器限制会一起变化遗漏任何一项都可能在真实流量下才露出问题。升级前应能回答新进程实际使用了多少资源依赖是否支持目标版本异常出现时怎样暂停灰度并恢复服务。内存账不能只看 Java 堆Heap 没满不代表容器安全。常驻内存还包括 Metaspace、线程栈、Direct Buffer、Code Cache、JVM 结构和本地库分配cgroup 限制的是进程总量触顶时进程可能被终止而不一定留下常见的OutOfMemoryError。新旧基线应在相同请求类型和负载下比较堆、非堆、直接内存、线程数、RSS 与容器限制空载启动数据参考价值有限。Native Memory Tracking 能帮助拆分部分 JVM 原生内存但需要启动时开启也有成本并且看不到所有第三方原生分配。它适合与进程和容器指标交叉核对不能当成完整账本。Netty、压缩库、JNI 等组件还应分别确认兼容性和内存行为。旧启动参数逐项核验把当前生产启动命令保存下来放到目标 JDK 逐项验证并检查启动日志。CMS、永久代相关参数等旧选项可能已移除GC 日志格式可能需要迁移到统一日志--add-opens只应在确有依赖需求时保留不应变成通用补丁。能启动也不代表依赖兼容Spring、字节码生成、序列化、监控 Agent 与测试工具都可能受 class 文件版本或模块限制影响。GC 选择也没有通用答案。灰度应比较服务自身的吞吐、尾部延迟、分配速率、GC CPU 和内存回落趋势观察时间覆盖真实业务周期。版本标签必须进指标流量按阶段放大并在开始前写清继续、暂停和回滚条件。某些大对象请求、长连接或定时任务只会影响少量实例聚合平均值很容易把它们遮住。# 采样前显式确认目标重型堆转储不作为默认动作 jcmd $JAVA_PID Thread.print $DUMP_DIR/thread.txt || true jcmd $JAVA_PID VM.native_memory summary $DUMP_DIR/nmt.txt || true kubectl -n $NAMESPACE rollout undo deployment/$DEPLOYMENT排障与回滚要分优先级。Heap Dump 可能暂停应用、占用大量磁盘还包含业务数据故障扩大时应优先恢复流量是否采集重型转储由现场人员依据权限、磁盘和影响决定。脚本必须要求显式传入 PID、命名空间和发布对象不能靠模糊匹配选进程若使用 GitOps回滚也应服从既有发布控制面。最后留下可核对的升级清单目标 JDK 与镜像摘要、完整参数、依赖验证结果、新旧基线、灰度分组、停止条件和回滚责任人。这样的清单并不华丽却能让每一步在上线前被验证也能在问题出现时迅速界定下一步该做什么。