登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  科技周边 >  业界新闻

Oracle Java 2026 年 7 月 CPU 后如何核对运行时

来源:17golang原创

时间:2026-09-11 14:27:05 419浏览 收藏

Oracle 2026 年 7 月 Critical Patch Update(CPU)在 7 月 21 日发布。核对 Java 运行时不能只看“机器上有没有更新”,而要完成两次对照:先按主版本找到官方安全基线,再确认业务进程实际加载的 Java 是否已经达到这个基线。

官方更新入口:https://www.oracle.com/java/technologies/javase/jdk-relnotes-index.html

要点速览
  • Java 26、25、21、17、11 的 7 月基线分别是 26.0.2+10、25.0.4+7、21.0.12+7、17.0.20+7、11.0.32+7。
  • Java 8 要按 1.8.0_501-b08 这种旧式版本格式比较,不能只看“Java 8”。
  • 最终证据来自业务进程的可执行文件、java.home 和完整构建号,JAVA_HOME 只能算线索。

先把 CPU 公告基线变成一张对照表

Oracle 的 Java Management 更新说明列出了本次 CPU 对应的运行时版本;JDK 26.0.2 发布说明还给出了完整构建字符串。可以先把它整理成一张“主版本—目标版本—构建号”表,再去看服务器。

Java 主版本7 月 CPU 目标版本比对重点
2626.0.2+10版本和 build 都要一致
2525.0.4+7长期支持线不要错看成 21
2121.0.12+7确认实际启动的 21.x 更新号
1717.0.20+7确认发行版是否提供同等更新
1111.0.32+7不要只记录 11.0
81.8.0_501-b08按 8u501 和完整 build 比较

这张表是升级核对目标,不等于只凭一条命令就能完成完整风险评估。Oracle 的 CPU 公告仍应作为漏洞范围和安装说明的入口。

Java 8、11、17、21、25、26 与 2026 年 7 月 CPU 基线的对应关系说明图
图1:先按 Java 主版本找到对应的 2026 年 7 月 CPU 基线,再核对完整构建号。

先查命令看到的版本和构建号

第一轮检查针对当前 shell。它适合发现 PATH 指向了哪一个 Java,也适合把结果保存进变更记录,但它还不能证明 systemd、容器或应用服务器使用的是同一个运行时。

# 合并 stderr,避免 java -version 的版本信息只出现在错误输出流
java -version 2>&1

# 查看包含构建标识的完整版本;Java 8 的输出尤其需要保留
java -fullversion 2>&1

# 记录当前命令解析到的路径,便于和服务启动配置比较
command -v java
readlink -f "$(command -v java)"

# 查看运行时属性,确认版本、完整运行时版本和 java.home
java -XshowSettings:properties -version 2>&1 | grep -E 'java.version|java.runtime.version|java.home|java.vendor'

Oracle 对版本字符串的说明中,java.version 表示产品版本,java.runtime.version 还可能包含构建标识。记录时不要把输出截成“Java 17”或“Java 8”,否则后续无法判断是否达到目标基线。

不要只看 JAVA_HOME,要追到业务进程

最常见的误判是:登录 shell 已经切换到新 JDK,但服务仍由旧路径启动;或者镜像里的 /usr/bin/java 已更新,正在运行的 JVM 却还没有重启。Linux 上可以沿着 PID 查看真实可执行文件:

# 替换为实际 Java 服务 PID;先确认进程归属,避免误查其他 JVM
pid=12345
ps -fp "$pid"

# /proc/PID/exe 指向当前进程真正加载的 java 可执行文件
readlink -f "/proc/$pid/exe"

# 读取进程启动时继承的 JAVA_HOME,只作辅助线索
tr '\0' '\n' &1

如果服务运行在容器里,应在目标容器内部执行同样的检查;如果是 systemd 服务,还要同时查看 ExecStart、环境文件和最近一次重启时间。最终记录应至少包含服务名、PID、可执行文件绝对路径、java.home、完整版本和检查时间。

从 shell 命令、服务启动到 Java 业务进程的运行时核对路径说明图
图2:版本核对要落到业务进程实际加载的 java 可执行文件,而不只是环境变量。

升级后的复核与常见误区

升级完成后,先比对进程级输出,再观察服务是否已经完成滚动重启。只有新 PID 对应的新路径和新构建号同时出现,才算这次运行时升级真正生效。旧进程仍在运行时,磁盘上的新 JDK 不能替代它。

  • 把 8u501 和 1.8.0_501-b08 当成两种版本:它们是同一条 Java 8 更新线的不同写法,留档时保留完整字符串。
  • 只看大版本:Java 17.0.19 与 17.0.20 不是同一个 CPU 基线。
  • 只改环境变量:服务可能在启动脚本中写死了 JDK 路径,或由容器镜像提供自己的 Java。
  • 升级后不重启:运行中的 JVM 不会因为磁盘上的 Java 文件变化而自动换成新运行时。

建议把版本输出和发布单绑定保存,并在下一个 CPU 周期重复这套检查。这样每次只需替换基线表,不必重新猜测某个服务到底加载了哪套 Java。

相关问题

Java 17 只显示 17.0,还能判断是否达到基线吗?

不能。应补充 java -fullversionjava.runtime.version,至少看到 17.0.20 及对应构建号,再与发布说明比较。

JAVA_HOME 指向新 JDK,为什么服务仍是旧版本?

服务可能使用了写死的绝对路径、容器内路径或旧进程。优先查 PID 的 /proc/PID/exe,再确认服务是否完成重启。

不同发行版的 Java 版本号不完全一样怎么办?

先确认发行版对应的上游 Java 主版本和补丁说明,再保留厂商追加的 build 标识;不要只按字符串相等判断,必要时以供应商安全公告补充解释。

参考入口:https://docs.oracle.com/en-us/iaas/releasenotes/java-management/jdk-cpu-july-2026.htmhttps://www.oracle.com/security-alerts/cpujul2026.html

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>