企业官网建设流程全解析

简介：jdk1.7-linux 是面向 Linux 平台开发者打包的 Oracle JDK 1.7（Java 7）安装包，适合需要在服务器或本地环境搭建 Java 7 开发、编译与运行环境的工程师、运维人员及 Java 初学者。该版本引入钻石操作符、try-with-resources、多重 catch、String 类型 switch、Fork/Join 并行框架等特性，是维护老项目或学习 Java 语言演进的重要工具。资源以 gz 压缩包形式提供，整体约 133MB，解压后可直接配置 JAVA_HOME、PATH 与 CLASSPATH 完成环境搭建，并支持通过 update-alternatives 或 SDKMAN! 等工具进行多版本管理。目前已有 241 人学习下载，适合需要快速获取稳定 JDK 1.7 发行版、搭建 Java 7 开发环境或进行版本兼容性验证的读者参考使用。

1. 装 jdk1.7 之前，先把这台 Linux 的底细摸清楚

很多人以为在 Linux 上装 jdk1.7 就是解压、配环境变量、java -version三步收工，结果真到生产机上跑起来才发现，系统自带的 OpenJDK 和你要装的 Oracle JDK 打架，alternatives指向混乱，JAVA_HOME被别的脚本覆盖，最后应用启动报UnsupportedClassVersionError。jdk1.7-linux 这套环境在老旧业务系统里出镜率极高，尤其是那些还在跑tomcat7、weblogic10或者自研中间件的机器，版本选错一个补丁号，可能连编译都过不去。这篇笔记面向的是需要在 CentOS 6/7、Ubuntu 14.04/16.04 这类老系统上把 jdk1.7 装稳、配好、能验证的开发者，也适合那些接手了遗留系统、需要快速复现一套可运行环境的运维。下面按「先看清环境、再动手装、最后验证跑通」的顺序走一遍，中间会穿插我踩过的坑和参数取舍。

2. 环境准备与版本选择：jdk1.7-linux 到底该下哪个包

2.1 确认系统架构和 glibc 版本

jdk1.7 的 Linux 安装包分 32 位和 64 位，下错了连解压都跑不起来。先看机器架构：

uname -m # x86_64 表示 64 位系统，i686 表示 32 位

再看 glibc 版本，jdk1.7 对 glibc 有最低要求，CentOS 6 默认 2.12，CentOS 7 是 2.17，都能满足。如果 glibc 低于 2.5，基本可以放弃，换系统比换 JDK 更省事。

ldd --version | head -1 # 输出类似 ldd (GNU libc) 2.17

常见做法是：64 位系统一律选jdk-7u80-linux-x64.tar.gz，这是 jdk1.7 最后一个公开更新版本，补丁最全，兼容性最好。32 位系统选jdk-7u80-linux-i586.tar.gz，但 32 位机器内存寻址受限，跑大堆应用容易 OOM，能换 64 位就换。

2.2 卸载系统自带的 OpenJDK

很多 Linux 发行版预装了 OpenJDK，直接装 Oracle JDK 会导致java命令指向不明。先查再卸：

rpm -qa | grep -i java # CentOS/RHEL 系用 rpm 查 dpkg -l | grep -i java # Debian/Ubuntu 系用 dpkg 查

如果看到java-1.7.0-openjdk或openjdk-7-jre之类的包，用包管理器卸掉：

yum remove java-1.7.0-openjdk* # CentOS/RHEL apt-get remove openjdk-7-* # Debian/Ubuntu

卸完后java -version应该提示 command not found，说明旧环境清干净了。这一步别偷懒，我见过太多因为 OpenJDK 残留导致JAVA_HOME指向/usr/lib/jvm下错误目录的案例。

2.3 下载与校验安装包

jdk1.7 的安装包从官方归档渠道获取，下载后先校验大小和哈希，避免传输损坏。常见做法是：

ls -lh jdk-7u80-linux-x64.tar.gz # 正常大小约 150MB 左右 sha256sum jdk-7u80-linux-x64.tar.gz # 和官方公布的哈希值比对

如果哈希对不上，重新下载，别硬着头皮解压，后面报错会更难查。

3. 安装 jdk1.7：解压、目录规划与 alternatives 配置

3.1 解压到统一目录并规划路径

我一般把 JDK 放在/usr/local/java/下，方便多版本共存和切换：

mkdir -p /usr/local/java tar -zxvf jdk-7u80-linux-x64.tar.gz -C /usr/local/java/ # 解压后得到 /usr/local/java/jdk1.7.0_80

解压完确认目录结构：

ls /usr/local/java/jdk1.7.0_80/ # 应该看到 bin、jre、lib、include 等目录

如果解压后目录名带空格或特殊字符，建议重命名成jdk1.7.0_80，避免后续脚本引用时出问题。

3.2 配置全局环境变量

编辑/etc/profile.d/java.sh，这样对所有用户生效，也避免直接改/etc/profile造成污染：

cat > /etc/profile.d/java.sh <<'EOF' export JAVA_HOME=/usr/local/java/jdk1.7.0_80 export JRE_HOME=$JAVA_HOME/jre export CLASSPATH=.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar:$JRE_HOME/lib export PATH=$JAVA_HOME/bin:$JRE_HOME/bin:$PATH EOF

参数说明：JAVA_HOME指向 JDK 根目录，很多中间件启动脚本靠它定位；CLASSPATH里的.表示当前目录，dt.jar和tools.jar是编译和工具类需要的；PATH把 JDK 的 bin 放在最前面，确保java、javac优先走新装的版本。

改完让配置生效：

source /etc/profile.d/java.sh

3.3 用 alternatives 管理多版本

如果机器上还有其他 JDK，用alternatives注册一下，切换更规范：

alternatives --install /usr/bin/java java /usr/local/java/jdk1.7.0_80/bin/java 1 alternatives --install /usr/bin/javac javac /usr/local/java/jdk1.7.0_80/bin/javac 1 alternatives --config java # 按提示选择 jdk1.7.0_80 对应的编号

这一步不是必须的，但多版本共存时能省很多事。注意alternatives的优先级数字越大越优先，我一般给 jdk1.7 设 1，给新版本设 2，默认走新版本，需要时手动切回 1.7。

4. 避坑与排查：jdk1.7-linux 安装后最容易翻车的五个点

4.1 现象：java -version显示的还是旧版本

原因：PATH里旧 JDK 路径排在前面，或者 shell 缓存了旧的命令位置。解决：先which java看实际指向，再echo $PATH确认顺序，必要时hash -r清缓存，重新登录终端。

4.2 现象：应用启动报UnsupportedClassVersionError

原因：编译时用了高版本 JDK，运行时用了 jdk1.7，class 文件版本不兼容。解决：统一编译和运行环境，或者用javac -target 1.7 -source 1.7重新编译。检查JAVA_HOME是否被其他脚本覆盖，尤其是catalina.sh里可能硬编码了路径。

4.3 现象：JAVA_HOME在 cron 或 systemd 里不生效

原因：/etc/profile.d/只对交互式登录 shell 生效，cron 和 systemd 不读这个。解决：在 cron 脚本里显式source /etc/profile.d/java.sh，或者 systemd unit 里用Environment=JAVA_HOME=/usr/local/java/jdk1.7.0_80单独指定。

4.4 现象：解压后bin/java无法执行

原因：下载的是 RPM 包却按 tar.gz 解压，或者文件权限丢失。解决：确认包格式，tar.gz 包解压后chmod +x bin/*补权限，RPM 包用rpm -ivh安装。

4.5 现象：tools.jar找不到导致编译失败

原因：只装了 JRE 没装 JDK，或者CLASSPATH没包含tools.jar。解决：确认JAVA_HOME/lib/tools.jar存在，检查CLASSPATH配置，必要时手动加上绝对路径。

5. 验证 jdk1.7 是否装好：从命令行到实际编译跑通

5.1 基础命令验证

先看版本和路径：

java -version # 期望输出：java version "1.7.0_80" javac -version # 期望输出：javac 1.7.0_80 echo $JAVA_HOME # 期望输出：/usr/local/java/jdk1.7.0_80

三个输出一致，说明基础环境没问题。如果java -version正常但javac找不到，多半是只装了 JRE 或者PATH没包含bin。

5.2 写一个最小可运行类做编译验证

光看版本号不够，实际编译跑一个类才能确认工具链完整：

mkdir -p /tmp/jdk7test && cd /tmp/jdk7test cat > HelloJDK7.java <<'EOF' public class HelloJDK7 { public static void main(String[] args) { System.out.println("jdk1.7 runtime ok, version=" + System.getProperty("java.version")); } } EOF javac HelloJDK7.java java HelloJDK7 # 期望输出：jdk1.7 runtime ok, version=1.7.0_80

这一步能同时验证javac编译、java运行和JAVA_HOME指向。如果编译报错，看javac是否来自 jdk1.7；如果运行报错，看java是否指向同一个 JDK。

5.3 检查关键目录和文件

最后确认几个关键文件存在：

ls $JAVA_HOME/bin/java $JAVA_HOME/bin/javac $JAVA_HOME/lib/tools.jar $JAVA_HOME/jre/lib/rt.jar # 四个文件都应该存在且可读

rt.jar是运行时核心类库，tools.jar是编译工具类库，缺任何一个都说明安装包不完整。我习惯在装完后把这几个路径记到部署文档里，下次换机器直接对照检查。

从那以后我每次装完 jdk1.7，都强制走一遍「版本号 + 编译运行 + 关键文件」三连验证，不再只看java -version就收工。希望帮到你。

本文还有配套的精品资源，点击获取