刚把一台老旧测试机从内网翻出来的时候我发现系统里连个像样的 Java 环境都没有。项目代码是好几年前留在一台虚拟机上没舍得删的老工程编译和运行都依赖 JDK 7一旦换了高版本就会出现类库冲突和中间件跑不起来的问题。折腾了一圈之后最稳的方案还是手动下载jdk-7u25-linux-x64.tar.gz解压安装然后把环境变量配好。整个过程并不复杂但里面有几个容易踩的细节值得完整记录一遍。1. 为什么要动用 JDK 7u25先确认它适合什么场景1.1 这类老版本 JDK 的真实用途JDK 7u25 发布距今已经很久了正常情况下新项目完全没必要选它。不过如果你是在维护老系统或者要还原一个多年前的运行环境那它依然是不可替代的。我手头这个老工程的情况就是典型的例子框架版本停留在旧分支里面用到的某些字节码操作工具在 JDK 8 之后会直接报错而应用服务器那边也只认 7 这个主版本。强行升版本要么改代码要么重换中间件代价远比装一个老 JDK 大得多。另外还有个常见场景是软件兼容性验证。某些厂商的遗留设备管理平台或者定制化插件官方适配表里明确写了只支持 Java 7你拿高版本去跑就是跑不起来。所以 CentOS 7 配上 JDK 7u25在测试环境里做恢复验证实际需求并不少。1.2 安装方式对比为什么不直接用 yum 或 rpm同样是在 CentOS 7 上装 Java至少有三条路可以走这里我把它们放在一起对比一下。安装方式优点缺点适合场景yum install java-1.7.0-openjdk命令简单自动处理依赖装的是 OpenJDK部分老软件对 Oracle JDK 有依赖版本被系统仓库固定不挑 JDK 发行版、只求能用rpm 包安装安装和卸载有系统记录需要自己找 Oracle JDK 的 rpm且安装位置被包管理接管多版本共存不方便单 JDK 环境够用tar.gz 手动解压目录完全可控多版本共存简单卸载就是删目录环境变量要自己配老版本 JDK、多版本切换、维护遗留系统我个人在装 JDK 7u25 的时候只考虑 tar.gz 方式。原因有两个第一老版本 JDK 用 rpm 装容易和系统的 OpenJDK 产生软链接冲突清理起来很麻烦第二tar.gz 解压出来的目录自带完整的jdk1.7.0_25文件夹放哪里、叫什么名字都由自己决定出问题直接删掉不会污染系统。对一台需要长期维护的服务器来说这个特性太重要了。2. 安装包获取与安装前的系统检查2.1 从哪找 jdk-7u25-linux-x64.tar.gz怎么校验Oracle 官网早就把 JDK 7u25 从普通下载页面拿掉了现在要获取这个文件一般是通过归档站访问旧版本列表或者是用团队内部留存的安装包。无论从哪里拿文件第一件事永远是校验完整性。我拿到文件之后会这样做md5sum jdk-7u25-linux-x64.tar.gz sha1sum jdk-7u25-linux-x64.tar.gz然后把计算出来的哈希值和发布方提供的哈希值做对比。这一步不能省。老版本 JDK 的压缩包在网上流传很广不排除有被修改的可能。如果哈希对不上宁可不装也不要冒险解压否则后续出现的诡异报错会耗费大量排查时间。顺带说一句如果是从第三方镜像下载的优先挑那些提供官方哈希对照的镜像源。光有文件名对不上内容的情况我在实践中遇到过不止一次。2.2 确认系统架构和现有多余 JavaCentOS 7 的 x86_64 版本默认情况下不带任何 Java但如果是别人用过的一台机器情况就不一定了。所以安装之前先检查两件事。# 查看系统架构 uname -m # 查看当前能否调用 java 命令 which java java -versionuname -m如果输出x86_64那说明和linux-x64这个包是对得上的。which java这一步要特别留意很多老机器上会残留一些半截的 Java 环境比如装了一半的 OpenJDK或者/usr/bin/java这个软链接还指着一个不存在的路径。如果发现系统里已经存在 OpenJDK我建议先处理好再继续装。不要急着卸载因为某些系统组件可能依赖它更合理的做法是把它的环境变量屏蔽掉让后续配置的新 JDK 直接生效。如果确认没有组件依赖那直接用 yum remove 移除 openjdk 相关包也是可以的。yum list installed | grep java yum remove java-1.7.0-openjdk java-1.7.0-openjdk-headless还有个隐藏检查项是 glibc 版本。JDK 7u25 在 CentOS 7 上运行依赖系统的 C 库CentOS 7 默认的 glibc 是 2.17完全满足要求。想确认也很简单执行ldd --version看一下即可。如果未来要装到特别老的 CentOS 6 上这一步就得更谨慎。3. 解压安装与目录规划3.1 为什么建议统一放在 /usr/local/java在 Linux 服务器上JDK 适合放在一个集中的、和系统包管理无关的目录下我会选择/usr/local/java。这样做的好处有三个。第一多个 JDK 版本可以同时存在于同一个父目录下比如/usr/local/java/jdk1.7.0_25和/usr/local/java/jdk1.8.0_202之后切换版本时只需要改环境变量路径不需要移动任何文件。第二这个目录是系统管理员约定俗成的软件安装位置基本上所有服务脚本里提到手动安装的 Java 都会优先看这里不容易出现权限和路径不一致的问题。第三删除 JDK 的时候直接rm -rf这个目录不会留下任何系统和包管理痕迹。不要直接解压到/root或者某个用户的 home 目录。服务器上的应用往往以独立用户身份运行如果 JDK 放在个人目录下其他用户和系统服务根本访问不到后面写 service 脚本时就会遇到一堆权限问题。3.2 解压、移动、确认权限的完整操作假设安装包已经上传到了/opt目录下下面是一整套操作# 进入安装包所在目录 cd /opt # 先看一眼压缩包内容确认顶层目录名 tar -tzf jdk-7u25-linux-x64.tar.gz # 解压 tar -xzf jdk-7u25-linux-x64.tar.gz # 创建集中的 JDK 目录 mkdir -p /usr/local/java # 移动过去 mv jdk1.7.0_25 /usr/local/java/ # 确认移动后的目录结构 ls -la /usr/local/java/jdk1.7.0_25tar -tzf这一步很容易被跳过但它能提前告诉你解压出来的顶层目录叫什么。万一压缩包里的目录名不是标准的jdk1.7.0_25而你用默认路径执行了移动就会把文件放错位置。解压之后还需要确认 Java 可执行文件真的存在/usr/local/java/jdk1.7.0_25/bin/java -version如果这里能正常输出版本信息说明解压没出问题可以放心进入环境变量配置环节。顺便说一个细节JDK 7 的目录结构里bin目录下同时有java和javacjre目录是一个独立的运行环境。如果你的应用只运行不编译理论上只需要jre但大部分遗留项目在启动过程中还是要用到javac或其他bin下的工具所以我建议保留完整 JDK 目录不要精简。4. 环境变量配置JAVA_HOME、PATH、CLASSPATH 逐个拆解4.1 三个变量的职责分别是什么所有安装 JDK 的教程都会让你配置三个东西但它们各自的作用很多人并没有真正搞明白。JAVA_HOME是给其他程序和构建工具看的。像 Maven、Tomcat、Ant 这类工具启动脚本里会自动读取JAVA_HOME来定位 Java 可执行文件的路径不设置的话它们就会报找不到 JDK。对于老版本的中间件这一步尤其关键很多应用在启动脚本里写死了$JAVA_HOME/bin/java这种调用方式。PATH是给 shell 找命令用的。当你敲java -version的时候系统会在PATH里列出的目录中逐一搜索可执行文件。把$JAVA_HOME/bin加进PATH就等于告诉系统优先从这里找 java。这也是为什么java -version能直接执行的原因。CLASSPATH是给 JVM 找类用的。在 JDK 1.5 之后如果不手动设置CLASSPATHJVM 会默认把当前目录作为查找路径所以新项目根本不配这个变量也能跑。但老教程里普遍会配置它原因是更早版本的 JDK 必须手动指定才能正确加载类库。如果你在配置 JDK 7u25 时看到老教程让你设置CLASSPATH可以按照一套兼容写法来做但心里要清楚它已经不是必需的。4.2 写入 /etc/profile.d/java.sh 还是 /etc/profile配置环境变量有两个常见位置直接改/etc/profile或者在/etc/profile.d/下新建一个专用脚本。我更推荐后者。原因是/etc/profile是系统全局登录脚本如果多个软件都在里面追加内容文件会变得很难维护。而/etc/profile.d/java.sh是 CentOS 专门留给软件包初始化时使用的目录它会在登录时由/etc/profile自动加载逻辑清晰升级或卸载时直接删除这个文件就完事。新建/etc/profile.d/java.sh写入如下内容export JAVA_HOME/usr/local/java/jdk1.7.0_25 export PATH$JAVA_HOME/bin:$PATH # 如果使用老项目需要兼容传统 CLASSPATH 写法可以加上下面这一行 export CLASSPATH.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar写完之后执行source /etc/profile这里我要特意提醒一下export PATH$JAVA_HOME/bin:$PATH的写法。冒号左边是$JAVA_HOME/bin冒号右边是原来的$PATH这种顺序意味着新 JDK 的 bin 目录会被优先查找。万一系统里还有其他 Java 残留这个顺序能保证调用的版本符合预期。如果写反了java -version很可能还是会输出来自 OpenJDK 或系统自带 Java 的信息而且非常难排查。4.3 source 与登录 shell 的加载顺序很多人在source /etc/profile之后明明在当前窗口验证 java 命令没问题过一天再登录却发现 java 又不见了。这个现象的根本原因是环境变量加载顺序问题。/etc/profile只会在登录 shell 启动时被读取一次。你手动执行source /etc/profile只对当前这个终端会话生效。新开的 SSH 连接会重新加载整个登录流程正常情况下/etc/profile.d/java.sh会被自动读取但如果你的 shell 是sh或dash加载机制会有差异就可能出现配置不生效的情况。更崩溃的情况是用su切换用户。比如从 rootsu -到某个应用账号这时候会重新加载目标用户的登录脚本但不会重新加载 root 的/etc/profile.d/java.sh于是 Java 环境变量又丢了。解决方式是在应用账号的.bashrc里同样 export 一次或者直接写一行source /etc/profile.d/java.sh保证切换到该账号时也有完整的 Java 环境。5. 验证安装与多版本切换管理5.1 用三连验证确认安装真的成功了配置完环境变量验证不是只跑一个java -version就完事。我通常做三件事# 1. 确认 JAVA_HOME 路径正确 echo $JAVA_HOME # 2. 确认 java 命令指向的路径 which -a java # 3. 确认版本和 javac 都正常 java -version javac -versionwhich -a java这个命令能列出所有出现在 PATH 里的 java 可执行文件并带有路径。如果看到/usr/local/java/jdk1.7.0_25/bin/java排在最前面那就说明环境变量顺序没有问题。如果java -version是 1.7但javac -version报的是别的版本说明 PATH 里混进了多个 JDK得重新检查环境变量的优先级。另一个检查点是直接调用全路径/usr/local/java/jdk1.7.0_25/bin/java -version /usr/local/java/jdk1.7.0_25/bin/javac -version如果全路径能正常输出版本而普通命令不行那是 PATH 的问题如果全路径本身执行就报错那得回头查解压和文件权限而不是环境变量的锅。这一招能快速定位问题方向建议每次都试一下。5.2 alternatives 用还是不用CentOS 7 里自带一套alternatives管理工具用于维护/usr/bin/下的软链接。你可能看到过这种配置方式alternatives --install /usr/bin/java java /usr/local/java/jdk1.7.0_25/bin/java 3 alternatives --config java这套机制本身是好的但对于手动 tar.gz 安装的 JDK 7u25我通常不主动用它除非系统里本来就已经有人在用alternatives管理 Java。原因很简单alternatives控制的是/usr/bin/java这条软链接但如果你用/etc/profile.d/java.sh配置环境变量PATH 中的/usr/local/java/jdk1.7.0_25/bin会排在/usr/bin前面那么alternatives里即使切换了版本实际执行的依然是自己配置的 JDK。这种“表面切换成功、实际没生效”的状态特别容易误导人。如果你的服务器上存在多套 Java而且使用者众多维护者有统一用alternatives管理的习惯那我建议环境变量里只配置JAVA_HOME不调整 PATH让/usr/bin下的软链接来决定实际使用的 java。但如果你只是想给自己的项目搭一个可靠环境直接改 profile.d 文件更直观。5.3 多版本 JDK 切换的完整流程日常维护中经常出现同一个服务器需要同时跑 JDK 7 和 JDK 8 项目的情况。我当前的目录是这样的/usr/local/java/jdk1.7.0_25 /usr/local/java/jdk1.8.0_202默认环境变量写成 JDK 7export JAVA_HOME/usr/local/java/jdk1.7.0_25 export PATH$JAVA_HOME/bin:$PATH需要切到 JDK 8 时只需要编辑/etc/profile.d/java.sh把两处jdk1.7.0_25改成jdk1.8.0_202然后source /etc/profile java -version实测下来这个切换方式最稳定。它不改变任何系统目录下的文件只影响未来的登录会话和环境变量解析即使切换后发现问题也能立刻切回去没有任何风险。要注意的是切换之前那个旧项目如果有常驻进程还在跑那些进程用的是启动时的 JDK不会因为环境变量改变而自动切换。这种情况只能重启对应服务。6. 安装过程中最容易被忽略的几个坑6.1 系统自带 OpenJDK 的残留引发了版本错乱有一台机器我在配置完环境变量后执行java -version输出的不是刚装的 1.7.0_25而是openjdk version 1.8.0_161。一开始以为环境变量没生效检查了echo $JAVA_HOME确认没问题又查了which java结果路径确实指向了/usr/local/java/jdk1.7.0_25/bin/java。后来才发现问题出在系统里还留着一条软链接/usr/bin/java - /etc/alternatives/java而alternatives又指向了 OpenJDK 8 的安装路径。明明 PATH 优先为什么还会这样原因是有些服务脚本里有绝对路径/usr/bin/java的调用根本没有经过 PATH 查找。所以遇到版本错乱时不能只看当前 shell 的输出还得确认系统全局路径下是否有其他 java 可执行文件。清理方式就是调整alternatives的指向或者干脆删除那条/usr/bin/java软链接让所有调用统一走环境变量。6.2 环境变量写错了文件重启后配置丢失还有一次图省事把export JAVA_HOME...直接写到了当前用户的~/.bashrc里当时source了一下挺好用。结果运维重启了服务器自动化脚本用 root 身份登录去检查服务java 没了。因为~/.bashrc是某个用户自己的配置root 用户压根不会读它服务脚本自然拿不到 Java 环境。教训就是如果是系统级服务或者多用户环境环境变量优先写在/etc/profile.d/java.sh这类全局位置。如果只管自己本地调试个人配置文件也能用但要清楚它的生效范围。6.3 service 脚本和 cron 里找不到 Java 命令这是另一个高发问题。Tomcat 或者自研服务的启动脚本正常运行没问题但用service xxx start或者添加到 crontab 后日志里总是报“command not found: java”。原因很简单service命令和cron在执行时不一定加载用户级的 shell 环境变量非登录 shell 的环境非常简陋。/etc/profile.d/java.sh虽然是全局配置但 service 脚本如果在非交互模式下运行某些环境加载机制下依然不会主动读取它。规避办法有两个。一个是服务脚本里显式指定全路径JAVA_HOME/usr/local/java/jdk1.7.0_25另一个是在脚本开头手动 source 环境配置文件source /etc/profile.d/java.sh这也是我在所有老项目 service 脚本里最终采用的做法。不要迷信系统会自动加载全局配置Java 环境在多用户、多服务的场景下显式声明永远比隐式依赖可靠。6.4 老 JDK 与新的安全协议兼容问题装好 JDK 7u25 不代表万事大吉。这个版本的 JDK 太老了默认的 TLS 协议只支持到 TLSv1.2 的部分早期配置对现在很多新部署的服务端可能会有握手失败的问题。如果项目里需要向外请求某些 HTTPS 接口大概率会遇到证书或协议不匹配的报错。针对这种情况不要指望通过改 JDK 配置就能一劳永逸。最务实的做法是在 JVM 层面添加协议参数例如在启动脚本中加入-Dhttps.protocolsTLSv1.2如果接口方已经强制要求 TLSv1.3那 JDK 7u25 就真的无能为力了只能考虑用代理层做协议转换或者在项目所在子网内搭一个支持新旧协议转换的转发服务。这也是为什么我会建议JDK 7u25 可以作为遗留系统的运行环境但新一点的外部对接需求尽量还是走一台独立的高版本 Java 服务。根据我多次安装 JDK 7u25 的经验这套流程最值得记住的就四个字目录清晰。只要把安装包放在明确位置、解压到统一管理目录、环境变量写在全局配置文件里、验证时用全路径确认这台服务器的 Java 环境基本就不会再出幺蛾子。以后万一要加装其他版本的 JDK无非就是重复一遍解压和环境变量切换的操作风险完全可控。