简介jdk-7u80-linux-x64.tar.gz 是 Oracle 官方发布的 JDK 1.7 Update 80 Linux 64 位正式版面向需要在 Linux 服务器或桌面环境搭建 Java 开发/运行环境的工程师与运维人员。相比 32 位版本64 位 JDK 可分配超过 4GB 内存更适合大数据处理、高并发服务端等场景。压缩包共包含 2000 个文件约 126.45MB其中以 714 个 jar 类库文件、230 个 xml 配置、59 个 so 动态链接库为主体同时提供 javac、java、jarsigner、jvisualvm 等完整的命令行工具以及时区数据库、cacerts 安全证书等组件。解压后通过配置 JAVA_HOME、PATH 即可直接使用免去在线下载与编译的麻烦。目前已有 1903 人学习下载适合因兼容性或遗留项目需求仍使用 JDK 7 的团队。资源保留标准 JDK 目录结构便于平滑替换或升级现有环境是搭建 Java 服务的基础组件。1. 还在用 JDK 7 的团队多半卡在兼容性这道坎上老项目不升级不是不想动是动了就出问题。很多跑了几年的业务系统代码还是用 JDK 7 写的里面掺杂着老的第三方库、老的中间件配置一换新版本就报各种奇怪的 ClassNotFoundException 或者 NoSuchMethodError。JDK 7 的最后一个官方更新是 7u80这也是目前能稳定拿到的 x64 Linux 版本。对还在维护老系统的人来说这个 tarball 就是标准的“后悔药”既能装回去跑老项目又不会引入新版本的坑。本文从选型、校验、安装、配置到排错完整拆一遍 jdk-7u80-linux-x64.tar.gz 的落地过程适合运维、后端开发和需要复现老环境的技术人员。2. 为什么必须是 7u80版本边界与选型逻辑2.1 7u80 是 JDK 7 的最后一个公开版本Terminal 之后没有官方补丁JDK 7 的更新节奏是在 2015 年 4 月发布的 7u80 之后Oracle 就不再向公众提供 JDK 7 的补丁了。也就是说7u80 是你能拿到的、不需要商业授权的最后一份 JDK 7 官方版本。对于内部系统和离线环境来说这是一个关键的分界线再往后没有官方修复只有付费支持往前7u75、7u72 之类版本修了哪些问题在 Release Notes 里能查到但没有实质差异。选型的逻辑很简单如果你确定要跑 JDK 7 生态那就直接选 7u80而不是 7u60 或 7u72。原因是 7u80 修复了 7u79 之前暴露的一批安全漏洞包括一些反序列化相关的风险项。虽然版本老但至少是最后的“官方完整体”。现在的很多下载站里散落着 7u71、7u51 等旧版本那些是早期文件没有必要下。注意 7u80 和 7u79 的发布时间相差很短但 7u80 是明确标记为 Java SE 7 Update 80 的文件名后面带 u80 的才是。这里有个常见的误区有人会把 JDK 7u80 和 OpenJDK 7 混为一谈。两者的代码基础同源但二进制来源、许可证和更新策略不同。如果团队对 Oracle JDK 的兼容性有依赖比如用到一些未公开的 sun.* 内部类那还是老老实实用 Oracle JDK 7u80 的包。2.2 Linux x64 版 tarball 与 rpm 的区别为什么选 tar.gz同样在 7u80 里Oracle 提供了两类 Linux 安装包rpm 和 tar.gz。rpm 适合红帽系的 CentOS、Fedora装完自动写系统路径升级卸载走 rpm 命令管理。tar.gz 则是绿色的方式解压即用不需要 root 权限就能装到任意目录。对多数内部服务器环境来说我更倾向 tar.gz。原因是可控性更好尤其是机器上可能同时存在多个 JDK 版本时。一个团队内不同项目分别用 JDK 7 和 JDK 8如果都走 rpm装的时候会互相覆盖和干扰还需要频繁改 alternatives 命令切换。用 tar.gz 解压到独立目录再通过 JAVA_HOME 和 PATH 去指就不会动不动就把系统自带的 Java 版本给换了。而且要迁移到新机器时tar.gz 包整个拷走就行rpm 还得重新安装一遍。需要注意jdk-7u80-linux-x64.tar.gz 这个文件只对应 Linux x64不适用于 32 位系统或 ARM 架构。32 位机器需要找 jdk-7u80-linux-i586.tar.gzARM 需要用其他版本。检查服务器架构时用 uname -m 看输出如果是 x86_64那就对了。2.3 检查现有环境先看清机器上已装的 Java 再动手安装之前必须先确认服务器当前 Java 的情况不然容易出现装完以后发现系统里有两个 java 命令在打架。操作很简单java -version which java echo $JAVA_HOME第一条命令查看当前默认使用的 Java 版本第二条命令定位 java 可执行文件所在的目录第三条检查环境变量是否已经设置过。如果 which java 指向 /usr/bin/java系统里通常有系统自带的 OpenJDK 或者之前安装过的版本后续安装时需要注意 PATH 优先级的覆盖。我见过不少同事在已经装了 JDK 8 的机器上直接解压 JDK 7然后发现 java -version 显示的还是 1.8。原因很简单因为 /usr/bin/java 是 alternatives 管理的软链接指向别处直接改 /etc/profile 里的 JAVA_HOME 并没有真正覆盖命令优先级。这一步在装之前检查好后面会省很多事。3. 下载与校验拿到值得信的 7u80 文件3.1 从官方归档路径获取安装包不碰第三方二次打包Oracle 官方对 JDK 7 的下载入口已经调整过现在的页面入口指向的是 Java Archive 页面也就是历史版本归档区。直接搜 jdk-7u80-linux-x64.tar.gz 会找到一堆第三方下载站但我不建议从那些地方拿文件原因很实际你不知道文件是不是被改过甚至有被捆绑修改的风险。毕竟老版本的 JDK 在内部系统里具有较高的信任权限被植入恶意代码的后果很严重。最稳妥的路径是进 Oracle 的 Java Archive 下载页面选择 Java SE 7然后找 7u80 对应的 Linux x64 版本。下载之前需要接受 Oracle 的 License 协议一般点一下同意即可。这个页面允许直接下载 tar.gz会得到一个文件名为 jdk-7u80-linux-x64.tar.gz 的包。如果你在一个完全内网的环境需要从有网环境先下载然后传到内网服务器上。传输方式可以用 scp 或者 rsync注意校验文件完整性。不要用 FTP 明文传输容易被篡改。3.2 用 sha256 校验文件完整性这一步不能省从任何渠道下载完文件后都应该先计算哈希值再解压。7u80 官方发布时提供了对应的校验值在下载页面或者 Oracle 的官方文档里能看到 SHA256 值。Linux 下用 sha256sum 命令即可sha256sum jdk-7u80-linux-x64.tar.gz把输出的 64 位十六进制字符串与官方页面上的值比对。如果一致说明文件内容完整如果不一致立即删除重新下载。我这里再强调一遍这一步看起来繁琐但确实能避开很多问题。常见的情况是下载过程断点续传造成的文件损坏或者使用了某些下载工具导致内容被截断。这两种情况都会在解压时报错通过先校验就能提前发现。校验通过之后用 tar 命令解压tar -zxvf jdk-7u80-linux-x64.tar.gz -C /usr/local/参数说明-z 表示通过 gzip 解压-x 表示解包-v 是显示过程-f 指定文件名-C 指定解压到 /usr/local/ 目录。执行完以后/usr/local/ 下会出现 jdk1.7.0_80 目录。3.3 推荐目录规范统一放在 /usr/local/jdk 下我自己的习惯是把 JDK 解压后手动做一个软链不直接使用带版本号的目录名。比如ln -s /usr/local/jdk1.7.0_80 /usr/local/jdk7这样做的好处是当以后需要切换到 7u85如果有或者回退版本时只需要改变软链接的指向而不用改一堆脚本里的 JAVA_HOME 路径。很多自动化部署脚本里写死了 JAVA_HOME统一用 /usr/local/jdk7 这种路径升级 JDK 时只要修改软链并重启服务即可不用翻遍所有配置文件去改路径。4. 配置 JAVA_HOME 与 PATH三个文件的坑与正确写法4.1 全局配置 /etc/profile 的推荐写法配置环境变量是安装 JDK 之后最关键的一步。最常见的方式是在 /etc/profile 末尾追加内容export JAVA_HOME/usr/local/jdk7 export PATH$JAVA_HOME/bin:$PATH export CLASSPATH.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar注意这里有个顺序问题我把 $JAVA_HOME/bin 放在 $PATH 之前是为了确保 shell 找到的是我们指定的 JDK 7 的 java 命令而不是系统原有的其他版本。CLASSPATH 这个变量在 JDK 1.5 之后其实可以不手动设置因为 JVM 会默认加载当前目录和 rt.jar 等核心类库。但在老项目里很多历史文档仍要求设置。如果项目里有老的依赖管理方式比如直接 javac 编译时找不到第三方 jar那八成就是 CLASSPATH 没配好。CLASSPATH 开头加一个 . 是标准做法代表把当前目录加入类路径不加的话用 javac 编译当前目录下的类可能报找不到类。配置完以后用 source 命令让配置立即生效source /etc/profile验证配置是否正确java -version echo $JAVA_HOME输出应该显示 java version 1.7.0_80且 JAVA_HOME 指向 /usr/local/jdk7。4.2 用户级配置和系统级配置的优先级问题/etc/profile 是全局生效的对所有用户都有效。但有些环境只需要对某个部署用户生效比如以 tomcat 用户运行 Java 应用。这种情况下不建议改全局配置可以在用户的 ~/.bashrc 或 ~/.bash_profile 里单独写配置。export JAVA_HOME/usr/local/jdk7 export PATH$JAVA_HOME/bin:$PATH这里容易踩坑的地方是bash 的启动文件加载顺序是 /etc/profile、~/.bash_profile、~/.bashrc。如果 /etc/profile 已经配置了一个 JAVA_HOME用户级配置再设一个后加载的会覆盖先加载的。如果你的部署账号 ssh 登录后 java -version 显示的还是老版本先看是哪个文件最后覆盖了 PATH。一个实用的排查命令是type -a java这个命令会列出所有与 java 相关的命令路径。如果输出多个路径就会清楚看到当前 shell 到底命中哪一个。4.3 修改系统 alternatives 或手动软链两套方案对比有些机器上安装了 rpm 版的 JDK系统里 /usr/bin/java 是通过 alternatives 管理的。安装 tar.gz 版时/usr/bin/java 可能依然指向老的版本。两种处理方式方案一修改 alternatives 指向alternatives --install /usr/bin/java java /usr/local/jdk7/bin/java 100 alternatives --config java第一句命令注册一个新的 java 候选优先级设为 100100 通常意味着比默认值更高。第二句会列出所有候选输入编号选择要用的那个。方案二直接替换软链接rm -f /usr/bin/java ln -s /usr/local/jdk7/bin/java /usr/bin/java这个方式简单粗暴但风险在于如果以后要切回其他版本需要记得改回去。我一般更推荐 alternatives 方式因为它是系统级的管理机制切换版本时有据可查。不过在一些简化的容器镜像里alternatives 可能没装那就用手动软链没毛病。5. 避坑与常见问题排查装完不等于能用5.1 现象解压后运行 java -version 报错 bash: java: command not found这个现象多出现在刚配置完 PATH 之后看起来和配置无关实际是 shell 没有重新加载配置或者 PATH 写错了。原因有两个。一是改完 /etc/profile 后没有执行 source新开的终端才会自动加载。二是 export PATH 的时候把 $JAVA_HOME 拼错了比如写成了 /usr/local/jdk7/bin: 末尾多了冒号或者 $JAVA_HOME 变量名拼错导致路径为空。解决方法是先检查 PATH 的值echo $PATH如果输出里根本没有 jdk 路径回过去看 /etc/profile 里的 export 语法。如果是变量拼写问题重新编辑后 source 即可。还有一个容易被忽略的如果改了 /etc/profile 但用的是 su 切换用户而不是重新登录bash 不会重新读取该文件必须退出重新登录一次。5.2 现象java -version 显示 1.8.0不是 1.7.0_80这个在我经手的服务器里出现频率最高。原因是 system 里默认的 java 是 alternatives 管理的而我们改的 JAVA_HOME 只对 shell 环境变量有效但 /usr/bin/java 的软链接依然指向老的 JDK。解决方式是走 alternatives 命令切换版本alternatives --config java输入对应的编号选择 jdk1.7.0_80 即可。如果没有该选项先用 --install 把 7u80 注册进去再执行切换。切换完以后 both java -version 和 $JAVA_HOME 保持一致。5.3 现象启动老项目报 UnsupportedClassVersionError看到这个错误时十有八九是项目代码由 JDK 8 编译的 class 文件跑在了 JDK 7 的 JVM 上。Java 版本向下兼容不成立高版本编译的字节码无法在低版本运行时执行。解决方式是明确项目的编译目标版本。如果有源码用 javac -source 1.7 -target 1.7 重新编译没有源码则需要换用与 class 文件对应的 JDK 版本。Java 7 的 class 文件 major version 是 51Java 8 是 52用 javap 可以查看javap -verbose ClassName | grep major5.4 现象JAVA_HOME 配置正确但 TOMCAT 启动报错Tomcat 类的中间件有自己的启动脚本默认会读取 setenv.sh 里的 JAVA_HOME 设置。如果系统全局配置了 JAVA_HOME但 Tomcat 的 setenv.sh 里写死了另一个路径那启动时用的还是老路径。解决方式是在 Tomcat 的 bin/setenv.sh 中显式覆盖export JAVA_HOME/usr/local/jdk7 export CATALINA_OPTS-Xms512m -Xmx1024m -XX:MaxPermGen128m注意 JDK 7 常用永久代参数 -XX:MaxPermSizeJDK 8 改成了 -XX:MaxMetaspaceSize。如果启动脚本里是 JDK 8 时代的参数跑在 7u80 上可能不生效但也不报错不过资源限制会失效容易导致内存持续上涨。5.5 现象使用 -XX:UseConcMarkSweepGC 时日志报错或者被忽略JDK 7 时期常用的 CMS 垃圾回收器在 7u80 里还支持但 7u80 对参数的校验比早期版本更严格。有些早期能静默忽略的参数在 7u80 里会直接报 Unrecognized option。解决方式是检查 JDK 7 的参数列表确认每一个 -XX 参数是否存在。用命令java -XX:PrintFlagsFinal -version 21 | grep -i UseConcMarkSweepGC如果输出中该参数值为空或直接抛异常说明这个参数不支持。做参数迁移时从 JDK 6 升到 7u80 最容易碰到这种边界问题。6. 验证安装与老项目兼容性检测两小时跑完的回归清单安装完成后我不直接扔给业务测而是先跑一遍自检脚本。这里给出一套验证流程完整跑完大概一个半小时到两小时能覆盖大多数老项目的启动与运行边界。第一步是验证 Java 编译器的版本与 JVM 参数javac -version java -XX:PrintFlagsFinal -version 21 | head -30javac 输出必须和 java 一致显示 1.7.0_80。PrintFlagsFinal 能看到默认堆大小、垃圾回收器类型和默认参数值方便与项目期望比对。第二步是跑一个最小化 JAR 包的加载测试验证基本的类加载链路没问题mkdir -p /tmp/jtest cd /tmp/jtest cat Hello.java EOF public class Hello { public static void main(String[] args) { System.out.println(System.getProperty(java.version)); System.out.println(System.getProperty(java.home)); } } EOF javac Hello.java java Hello第三行和第四行创建了一个简单的 Java 类打印 java.version 和 java.home用于确认运行时环境确实是刚装的 JDK 7。如果这里的输出与 java -version 一致说明编译和运行都走的是同一套 JDK。第三步是对老项目的关键 JAR 做类文件版本扫描find /path/to/old-project/WEB-INF/lib -name *.jar | while read jar; do unzip -p $jar *.class 2/dev/null | head -c 8 | od -An -tx1 | grep -q 51 echo $jar is Java 7 compatible || echo $jar may need check done这条命令过于粗糙只适合快速扫描。更精确的方式是用 javap 检查每个 jar 中 class 文件的 major version。超过 51 的 class 文件需要特别标注。第四步是针对项目配置文件中涉及的 GC 参数和内存参数做一次冒烟验证。常见做法是启动应用观察前 30 分钟的 GC 日志java -Xms512m -Xmx1024m -XX:PrintGCDetails -XX:PrintGCDateStamps -jar /path/to/old-app.jarGC 日志详细输出每次回收前后的堆变化以及回收耗时。如果发现频繁 Full GC 且回收后内存仍持续增长则需要检查代码里是否有内存泄漏而不是 JDK 的问题。JDK 7 和 JDK 8 的默认堆内存策略略有不同老项目在 7u80 上跑出与以前不一致的内存表现优先看是否少了 -XX:PermSize 和 -XX:MaxPermSize 的配置。最后一步是部署到预发环境跑一轮核心功能冒烟测试。对于老项目我习惯把回归重点放在类加载、数据库连接池初始化和外部接口调用三块。这三块是最容易暴露 JDK 兼容性差异的地方。如果这三块测试全部通过基本可以放心上线。很久以前接手过一个老项目第一次部署 7u80 时启动一切正常结果运行三天后频繁 Full GC查到最后是 JDK 6 时代遗留下来的 -XX:MaxPermGen 参数在 7u80 里被静默忽略永久代涨满后触发了持续 GC。从那以后每次安装完 JDK 7我都会强制走一遍参数扫描和 GC 日志观察流程宁可多花两小时也不在生产环境赌运气。希望这套流程也能帮到你。本文还有配套的精品资源点击获取
简介jdk-7u80-linux-x64.tar.gz 是 Oracle 官方发布的 JDK 1.7 Update 80 Linux 64 位正式版面向需要在 Linux 服务器或桌面环境搭建 Java 开发/运行环境的工程师与运维人员。相比 32 位版本64 位 JDK 可分配超过 4GB 内存更适合大数据处理、高并发服务端等场景。压缩包共包含 2000 个文件约 126.45MB其中以 714 个 jar 类库文件、230 个 xml 配置、59 个 so 动态链接库为主体同时提供 javac、java、jarsigner、jvisualvm 等完整的命令行工具以及时区数据库、cacerts 安全证书等组件。解压后通过配置 JAVA_HOME、PATH 即可直接使用免去在线下载与编译的麻烦。目前已有 1903 人学习下载适合因兼容性或遗留项目需求仍使用 JDK 7 的团队。资源保留标准 JDK 目录结构便于平滑替换或升级现有环境是搭建 Java 服务的基础组件。1. 还在用 JDK 7 的团队多半卡在兼容性这道坎上老项目不升级不是不想动是动了就出问题。很多跑了几年的业务系统代码还是用 JDK 7 写的里面掺杂着老的第三方库、老的中间件配置一换新版本就报各种奇怪的 ClassNotFoundException 或者 NoSuchMethodError。JDK 7 的最后一个官方更新是 7u80这也是目前能稳定拿到的 x64 Linux 版本。对还在维护老系统的人来说这个 tarball 就是标准的“后悔药”既能装回去跑老项目又不会引入新版本的坑。本文从选型、校验、安装、配置到排错完整拆一遍 jdk-7u80-linux-x64.tar.gz 的落地过程适合运维、后端开发和需要复现老环境的技术人员。2. 为什么必须是 7u80版本边界与选型逻辑2.1 7u80 是 JDK 7 的最后一个公开版本Terminal 之后没有官方补丁JDK 7 的更新节奏是在 2015 年 4 月发布的 7u80 之后Oracle 就不再向公众提供 JDK 7 的补丁了。也就是说7u80 是你能拿到的、不需要商业授权的最后一份 JDK 7 官方版本。对于内部系统和离线环境来说这是一个关键的分界线再往后没有官方修复只有付费支持往前7u75、7u72 之类版本修了哪些问题在 Release Notes 里能查到但没有实质差异。选型的逻辑很简单如果你确定要跑 JDK 7 生态那就直接选 7u80而不是 7u60 或 7u72。原因是 7u80 修复了 7u79 之前暴露的一批安全漏洞包括一些反序列化相关的风险项。虽然版本老但至少是最后的“官方完整体”。现在的很多下载站里散落着 7u71、7u51 等旧版本那些是早期文件没有必要下。注意 7u80 和 7u79 的发布时间相差很短但 7u80 是明确标记为 Java SE 7 Update 80 的文件名后面带 u80 的才是。这里有个常见的误区有人会把 JDK 7u80 和 OpenJDK 7 混为一谈。两者的代码基础同源但二进制来源、许可证和更新策略不同。如果团队对 Oracle JDK 的兼容性有依赖比如用到一些未公开的 sun.* 内部类那还是老老实实用 Oracle JDK 7u80 的包。2.2 Linux x64 版 tarball 与 rpm 的区别为什么选 tar.gz同样在 7u80 里Oracle 提供了两类 Linux 安装包rpm 和 tar.gz。rpm 适合红帽系的 CentOS、Fedora装完自动写系统路径升级卸载走 rpm 命令管理。tar.gz 则是绿色的方式解压即用不需要 root 权限就能装到任意目录。对多数内部服务器环境来说我更倾向 tar.gz。原因是可控性更好尤其是机器上可能同时存在多个 JDK 版本时。一个团队内不同项目分别用 JDK 7 和 JDK 8如果都走 rpm装的时候会互相覆盖和干扰还需要频繁改 alternatives 命令切换。用 tar.gz 解压到独立目录再通过 JAVA_HOME 和 PATH 去指就不会动不动就把系统自带的 Java 版本给换了。而且要迁移到新机器时tar.gz 包整个拷走就行rpm 还得重新安装一遍。需要注意jdk-7u80-linux-x64.tar.gz 这个文件只对应 Linux x64不适用于 32 位系统或 ARM 架构。32 位机器需要找 jdk-7u80-linux-i586.tar.gzARM 需要用其他版本。检查服务器架构时用 uname -m 看输出如果是 x86_64那就对了。2.3 检查现有环境先看清机器上已装的 Java 再动手安装之前必须先确认服务器当前 Java 的情况不然容易出现装完以后发现系统里有两个 java 命令在打架。操作很简单java -version which java echo $JAVA_HOME第一条命令查看当前默认使用的 Java 版本第二条命令定位 java 可执行文件所在的目录第三条检查环境变量是否已经设置过。如果 which java 指向 /usr/bin/java系统里通常有系统自带的 OpenJDK 或者之前安装过的版本后续安装时需要注意 PATH 优先级的覆盖。我见过不少同事在已经装了 JDK 8 的机器上直接解压 JDK 7然后发现 java -version 显示的还是 1.8。原因很简单因为 /usr/bin/java 是 alternatives 管理的软链接指向别处直接改 /etc/profile 里的 JAVA_HOME 并没有真正覆盖命令优先级。这一步在装之前检查好后面会省很多事。3. 下载与校验拿到值得信的 7u80 文件3.1 从官方归档路径获取安装包不碰第三方二次打包Oracle 官方对 JDK 7 的下载入口已经调整过现在的页面入口指向的是 Java Archive 页面也就是历史版本归档区。直接搜 jdk-7u80-linux-x64.tar.gz 会找到一堆第三方下载站但我不建议从那些地方拿文件原因很实际你不知道文件是不是被改过甚至有被捆绑修改的风险。毕竟老版本的 JDK 在内部系统里具有较高的信任权限被植入恶意代码的后果很严重。最稳妥的路径是进 Oracle 的 Java Archive 下载页面选择 Java SE 7然后找 7u80 对应的 Linux x64 版本。下载之前需要接受 Oracle 的 License 协议一般点一下同意即可。这个页面允许直接下载 tar.gz会得到一个文件名为 jdk-7u80-linux-x64.tar.gz 的包。如果你在一个完全内网的环境需要从有网环境先下载然后传到内网服务器上。传输方式可以用 scp 或者 rsync注意校验文件完整性。不要用 FTP 明文传输容易被篡改。3.2 用 sha256 校验文件完整性这一步不能省从任何渠道下载完文件后都应该先计算哈希值再解压。7u80 官方发布时提供了对应的校验值在下载页面或者 Oracle 的官方文档里能看到 SHA256 值。Linux 下用 sha256sum 命令即可sha256sum jdk-7u80-linux-x64.tar.gz把输出的 64 位十六进制字符串与官方页面上的值比对。如果一致说明文件内容完整如果不一致立即删除重新下载。我这里再强调一遍这一步看起来繁琐但确实能避开很多问题。常见的情况是下载过程断点续传造成的文件损坏或者使用了某些下载工具导致内容被截断。这两种情况都会在解压时报错通过先校验就能提前发现。校验通过之后用 tar 命令解压tar -zxvf jdk-7u80-linux-x64.tar.gz -C /usr/local/参数说明-z 表示通过 gzip 解压-x 表示解包-v 是显示过程-f 指定文件名-C 指定解压到 /usr/local/ 目录。执行完以后/usr/local/ 下会出现 jdk1.7.0_80 目录。3.3 推荐目录规范统一放在 /usr/local/jdk 下我自己的习惯是把 JDK 解压后手动做一个软链不直接使用带版本号的目录名。比如ln -s /usr/local/jdk1.7.0_80 /usr/local/jdk7这样做的好处是当以后需要切换到 7u85如果有或者回退版本时只需要改变软链接的指向而不用改一堆脚本里的 JAVA_HOME 路径。很多自动化部署脚本里写死了 JAVA_HOME统一用 /usr/local/jdk7 这种路径升级 JDK 时只要修改软链并重启服务即可不用翻遍所有配置文件去改路径。4. 配置 JAVA_HOME 与 PATH三个文件的坑与正确写法4.1 全局配置 /etc/profile 的推荐写法配置环境变量是安装 JDK 之后最关键的一步。最常见的方式是在 /etc/profile 末尾追加内容export JAVA_HOME/usr/local/jdk7 export PATH$JAVA_HOME/bin:$PATH export CLASSPATH.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar注意这里有个顺序问题我把 $JAVA_HOME/bin 放在 $PATH 之前是为了确保 shell 找到的是我们指定的 JDK 7 的 java 命令而不是系统原有的其他版本。CLASSPATH 这个变量在 JDK 1.5 之后其实可以不手动设置因为 JVM 会默认加载当前目录和 rt.jar 等核心类库。但在老项目里很多历史文档仍要求设置。如果项目里有老的依赖管理方式比如直接 javac 编译时找不到第三方 jar那八成就是 CLASSPATH 没配好。CLASSPATH 开头加一个 . 是标准做法代表把当前目录加入类路径不加的话用 javac 编译当前目录下的类可能报找不到类。配置完以后用 source 命令让配置立即生效source /etc/profile验证配置是否正确java -version echo $JAVA_HOME输出应该显示 java version 1.7.0_80且 JAVA_HOME 指向 /usr/local/jdk7。4.2 用户级配置和系统级配置的优先级问题/etc/profile 是全局生效的对所有用户都有效。但有些环境只需要对某个部署用户生效比如以 tomcat 用户运行 Java 应用。这种情况下不建议改全局配置可以在用户的 ~/.bashrc 或 ~/.bash_profile 里单独写配置。export JAVA_HOME/usr/local/jdk7 export PATH$JAVA_HOME/bin:$PATH这里容易踩坑的地方是bash 的启动文件加载顺序是 /etc/profile、~/.bash_profile、~/.bashrc。如果 /etc/profile 已经配置了一个 JAVA_HOME用户级配置再设一个后加载的会覆盖先加载的。如果你的部署账号 ssh 登录后 java -version 显示的还是老版本先看是哪个文件最后覆盖了 PATH。一个实用的排查命令是type -a java这个命令会列出所有与 java 相关的命令路径。如果输出多个路径就会清楚看到当前 shell 到底命中哪一个。4.3 修改系统 alternatives 或手动软链两套方案对比有些机器上安装了 rpm 版的 JDK系统里 /usr/bin/java 是通过 alternatives 管理的。安装 tar.gz 版时/usr/bin/java 可能依然指向老的版本。两种处理方式方案一修改 alternatives 指向alternatives --install /usr/bin/java java /usr/local/jdk7/bin/java 100 alternatives --config java第一句命令注册一个新的 java 候选优先级设为 100100 通常意味着比默认值更高。第二句会列出所有候选输入编号选择要用的那个。方案二直接替换软链接rm -f /usr/bin/java ln -s /usr/local/jdk7/bin/java /usr/bin/java这个方式简单粗暴但风险在于如果以后要切回其他版本需要记得改回去。我一般更推荐 alternatives 方式因为它是系统级的管理机制切换版本时有据可查。不过在一些简化的容器镜像里alternatives 可能没装那就用手动软链没毛病。5. 避坑与常见问题排查装完不等于能用5.1 现象解压后运行 java -version 报错 bash: java: command not found这个现象多出现在刚配置完 PATH 之后看起来和配置无关实际是 shell 没有重新加载配置或者 PATH 写错了。原因有两个。一是改完 /etc/profile 后没有执行 source新开的终端才会自动加载。二是 export PATH 的时候把 $JAVA_HOME 拼错了比如写成了 /usr/local/jdk7/bin: 末尾多了冒号或者 $JAVA_HOME 变量名拼错导致路径为空。解决方法是先检查 PATH 的值echo $PATH如果输出里根本没有 jdk 路径回过去看 /etc/profile 里的 export 语法。如果是变量拼写问题重新编辑后 source 即可。还有一个容易被忽略的如果改了 /etc/profile 但用的是 su 切换用户而不是重新登录bash 不会重新读取该文件必须退出重新登录一次。5.2 现象java -version 显示 1.8.0不是 1.7.0_80这个在我经手的服务器里出现频率最高。原因是 system 里默认的 java 是 alternatives 管理的而我们改的 JAVA_HOME 只对 shell 环境变量有效但 /usr/bin/java 的软链接依然指向老的 JDK。解决方式是走 alternatives 命令切换版本alternatives --config java输入对应的编号选择 jdk1.7.0_80 即可。如果没有该选项先用 --install 把 7u80 注册进去再执行切换。切换完以后 both java -version 和 $JAVA_HOME 保持一致。5.3 现象启动老项目报 UnsupportedClassVersionError看到这个错误时十有八九是项目代码由 JDK 8 编译的 class 文件跑在了 JDK 7 的 JVM 上。Java 版本向下兼容不成立高版本编译的字节码无法在低版本运行时执行。解决方式是明确项目的编译目标版本。如果有源码用 javac -source 1.7 -target 1.7 重新编译没有源码则需要换用与 class 文件对应的 JDK 版本。Java 7 的 class 文件 major version 是 51Java 8 是 52用 javap 可以查看javap -verbose ClassName | grep major5.4 现象JAVA_HOME 配置正确但 TOMCAT 启动报错Tomcat 类的中间件有自己的启动脚本默认会读取 setenv.sh 里的 JAVA_HOME 设置。如果系统全局配置了 JAVA_HOME但 Tomcat 的 setenv.sh 里写死了另一个路径那启动时用的还是老路径。解决方式是在 Tomcat 的 bin/setenv.sh 中显式覆盖export JAVA_HOME/usr/local/jdk7 export CATALINA_OPTS-Xms512m -Xmx1024m -XX:MaxPermGen128m注意 JDK 7 常用永久代参数 -XX:MaxPermSizeJDK 8 改成了 -XX:MaxMetaspaceSize。如果启动脚本里是 JDK 8 时代的参数跑在 7u80 上可能不生效但也不报错不过资源限制会失效容易导致内存持续上涨。5.5 现象使用 -XX:UseConcMarkSweepGC 时日志报错或者被忽略JDK 7 时期常用的 CMS 垃圾回收器在 7u80 里还支持但 7u80 对参数的校验比早期版本更严格。有些早期能静默忽略的参数在 7u80 里会直接报 Unrecognized option。解决方式是检查 JDK 7 的参数列表确认每一个 -XX 参数是否存在。用命令java -XX:PrintFlagsFinal -version 21 | grep -i UseConcMarkSweepGC如果输出中该参数值为空或直接抛异常说明这个参数不支持。做参数迁移时从 JDK 6 升到 7u80 最容易碰到这种边界问题。6. 验证安装与老项目兼容性检测两小时跑完的回归清单安装完成后我不直接扔给业务测而是先跑一遍自检脚本。这里给出一套验证流程完整跑完大概一个半小时到两小时能覆盖大多数老项目的启动与运行边界。第一步是验证 Java 编译器的版本与 JVM 参数javac -version java -XX:PrintFlagsFinal -version 21 | head -30javac 输出必须和 java 一致显示 1.7.0_80。PrintFlagsFinal 能看到默认堆大小、垃圾回收器类型和默认参数值方便与项目期望比对。第二步是跑一个最小化 JAR 包的加载测试验证基本的类加载链路没问题mkdir -p /tmp/jtest cd /tmp/jtest cat Hello.java EOF public class Hello { public static void main(String[] args) { System.out.println(System.getProperty(java.version)); System.out.println(System.getProperty(java.home)); } } EOF javac Hello.java java Hello第三行和第四行创建了一个简单的 Java 类打印 java.version 和 java.home用于确认运行时环境确实是刚装的 JDK 7。如果这里的输出与 java -version 一致说明编译和运行都走的是同一套 JDK。第三步是对老项目的关键 JAR 做类文件版本扫描find /path/to/old-project/WEB-INF/lib -name *.jar | while read jar; do unzip -p $jar *.class 2/dev/null | head -c 8 | od -An -tx1 | grep -q 51 echo $jar is Java 7 compatible || echo $jar may need check done这条命令过于粗糙只适合快速扫描。更精确的方式是用 javap 检查每个 jar 中 class 文件的 major version。超过 51 的 class 文件需要特别标注。第四步是针对项目配置文件中涉及的 GC 参数和内存参数做一次冒烟验证。常见做法是启动应用观察前 30 分钟的 GC 日志java -Xms512m -Xmx1024m -XX:PrintGCDetails -XX:PrintGCDateStamps -jar /path/to/old-app.jarGC 日志详细输出每次回收前后的堆变化以及回收耗时。如果发现频繁 Full GC 且回收后内存仍持续增长则需要检查代码里是否有内存泄漏而不是 JDK 的问题。JDK 7 和 JDK 8 的默认堆内存策略略有不同老项目在 7u80 上跑出与以前不一致的内存表现优先看是否少了 -XX:PermSize 和 -XX:MaxPermSize 的配置。最后一步是部署到预发环境跑一轮核心功能冒烟测试。对于老项目我习惯把回归重点放在类加载、数据库连接池初始化和外部接口调用三块。这三块是最容易暴露 JDK 兼容性差异的地方。如果这三块测试全部通过基本可以放心上线。很久以前接手过一个老项目第一次部署 7u80 时启动一切正常结果运行三天后频繁 Full GC查到最后是 JDK 6 时代遗留下来的 -XX:MaxPermGen 参数在 7u80 里被静默忽略永久代涨满后触发了持续 GC。从那以后每次安装完 JDK 7我都会强制走一遍参数扫描和 GC 日志观察流程宁可多花两小时也不在生产环境赌运气。希望这套流程也能帮到你。本文还有配套的精品资源点击获取
