Linux下安装配置JDK 1.6.0_45：老项目环境搭建与运维指南

简介：这是一份面向 Linux 平台的官方原版 Java 开发工具包（对应 JDK 1.6.0_45），主要适合因历史项目、企业系统或旧应用兼容要求而仍需使用 Java 6 的开发者、运维人员和技术支持人员。压缩包为 gz 格式，整体约 81MB，包含近 2000 个文件，其中以 html 帮助文档、jar 类库、xml 配置、so 动态库以及 java/class 源文件与编译产物为主，同时也带有大量时区数据、字符集和证书类文件，目录结构较为完整。资源内含编译、运行、调试、打包、文档生成和监控诊断等常用组件，如 javac、java、javadoc、jar、jdb、jvisualvm、jconsole 等工具，并提供 rt.jar、charsets.jar 等核心运行库与多种开发辅助脚本，可满足离线安装部署和本地文档查阅需求。目前已有 1053 人学习或下载，能够作为旧版 Java 环境的官方原版来源。需要留意的是，该版本发布较早，安全补丁相对陈旧，部署后应结合业务场景加强安全加固，并合理规划升级时间。 提到 jdk1.6.0_45 这个版本，很多刚碰 Linux 服务器的朋友可能都会愣一下：都什么年代了还装 Java 6？但在不少存量项目里，它就是那个“不能动”的底座。银行老系统、政务内网项目、旧版 WebLogic 集群，甚至一些工业设备的嵌入式控制台，跑的还是这套 JDK。换版本不是不行，而是编译目标、中间件兼容性、代码里用过期的 API，一换就是连环坑。所以与其讨论“该不该换”，不如把这套老环境的安装、配置、验证一次性弄扎实。

这篇文章只干一件事：用官网原版 jdk1.6.0_45 在 Linux 上完成部署，从下载校验、目录规划、环境变量配置，到多 JDK 切换、老项目启动参数、常见报错排查，全程按我实际维护过的服务器经验来说。适合接手存量项目的运维、做信创适配的研发，以及被领导要求“别动生产环境 JDK”的倒霉同学参考。

1. 为什么还在用 JDK 1.6.0_45：版本价值与现实约束

1.1 这个版本到底特殊在哪

Java 6 的公开更新止步于 Update 45，也就是我们常说的 1.6.0_45，这个版本之后官方就不再提供免费的公共补丁。从时间线上看它确实老了，但从稳定性角度看，它是整个 Java 6 生命周期里修复累积最多、行为最可预期的一个版本。很多老项目的编译目标直接写死成 1.6，字节码版本对应 50.0，你拿新 JDK 去跑，轻则报Unsupported major.minor version 50.0，重则在类加载阶段出现各种诡异异常。除了代码层面的兼容性，老中间件和 JDK 版本也是强绑定的：WebLogic 10.3.6 官方支持的就是 JDK 6，JBoss 4.x/5.x 时代的大量部署也跑在 1.6 上面。所以不是大家不想升，而是升不动。

1.2 哪些场景还在依赖它

我经手的项目里，还在用 1.6.0_45 的主要有三类。第一类是传统企业应用，比如老 OA、ERP 的门户端，代码里大量使用java.util.Date、Hashtable这类旧 API，换了新 JDK 虽然也能编过，但部分反射调用在模块化之后直接失效。第二类是旧版中间件集群，部署在 Linux 上的 WebLogic、WebSphere 的旧版本，官方对 JDK 版本有严格限定。第三类是嵌入式或信创过渡环境，系统底层 glibc 版本比较老，新 JDK 反而跑不起来，1.6 对系统库的依赖更低。在这些环境里，官网原版 JDK 是最稳妥的选择，因为它没经过第三方裁剪，目录结构、动态库、时区数据都是官方原样，出问题时排查路径最清晰。

1.3 为什么坚持用“官网原版”

这个问题我吃过亏。早期图省事，从某些下载站找的“绿色版”JDK，解压出来目录少了几层，连jre/lib/rt.jar都是被精简过的，跑 Swing 老程序缺字体、跑 JMX 缺管理扩展，问题非常难查。还有的“一键安装包”会往/etc/profile里塞私货，或者注册自启动服务，装完 JDK 反而把系统环境搞乱了。官网原版的 tar.gz 或自解压 bin 包，目录结构是固定的，jre/lib/rt.jar、jre/lib/management/、bin/java这些关键路径都在预期位置，后续写启动脚本、做基准校验都方便。用官网原版还有一层意思：你在网上搜到的老项目部署文档，大多是基于官方目录结构写的，路径对得上，才能照着走。

注意：1.6.0_45 之后 Oracle 对 Java 6 的商用授权政策有变化，这个版本原则上只建议用于存量系统维护，不要在公网新项目里引入。技术文档归技术文档，该做的风险控制不能省。

2. 安装前的环境确认与安装包准备

2.1 服务器架构和基础环境怎么看

拿到一台 Linux 服务器，别急着下载安装包。先确认三个东西：CPU 架构、发行版版本、glibc 版本。JDK 1.6 的安装包区分 x86 和 x64，uname -m输出x86_64就选 64 位包，输出i686或i386就选 32 位包。发行版版本用cat /etc/os-release看，CentOS 6/7、Ubuntu 14/16 这类老系统装 1.6 问题不大，如果是最新的发行版，反而可能出现老 JDK 依赖的库不存在的情况。glibc 版本用ldd --version查看，JDK 1.6 对 glibc 没有太苛刻的要求，2.5 以上基本都能跑，但知道版本有助于判断后续报错是不是系统库缺失引起的。确认完这三项，再决定下载哪个包。

2.2 下载官网原版与校验文件完整性

Oracle 官网的 Java 存档区可以找到jdk-6u45-linux-x64.bin、jdk-6u45-linux-i586.bin，也有对应的 tar.gz 版本。下载需要登录 Oracle 账号，这一步没办法跳过，属于官网正常流程。下载完先别急着安装，用官方页面提供的校验值核对文件完整性：

sha256sum jdk-6u45-linux-x64.bin md5sum jdk-6u45-linux-x64.bin

官网会给出 SHA-256 或 MD5 校验值，对比一致再进入下一步。这一步不是走过场，下载站、内网传输都可能造成文件损坏，装到一个坏包上，后面所有报错都会被误导。我遇到过解压到一半报gzip: invalid compressed data，重新下载后一切正常，就是没做校验的教训。

2.3 安装目录规划建议

安装目录看起来是小事，但直接影响后续脚本和维护。我习惯统一放到/usr/local/java/下面，版本号作为目录名，比如/usr/local/java/jdk1.6.0_45。这么做的好处是：目录语义清晰，多版本 JDK 可以并列存放；JAVA_HOME指向带版本号的完整路径，升级时只需新建目录并切换软链接，不污染旧环境。有些教程会让装到/usr/lib/jvm/，那个目录更多是发行版包管理器使用的约定，手动安装的 JDK 放那里反而不便于管理。还有一个原则：不要装在/root/下。生产环境通常用普通用户启动应用，JDK 装在 root 家目录里，其他用户没有访问权限，启动脚本权限控制非常别扭。

3. 安装与环境变量配置实操

3.1 bin 包与 tar.gz 包的区别与解压

官网提供了两种格式：.bin是自解压文件，本身带有二进制数据和一段解压逻辑；.tar.gz是纯压缩包。.bin格式在 Linux 上要先赋予执行权限再运行：

chmod +x jdk-6u45-linux-x64.bin yes | ./jdk-6u45-linux-x64.bin

执行过程中会提示阅读许可协议，yes |可以自动确认。需要注意，./jdk-6u45-linux-x64.bin最好在目标目录下执行，因为解压产物就在当前目录。也可以用tail等方式从 bin 文件里抽取 tar 部分，但没必要，官方格式直接跑就行。tar.gz 格式就简单了：

mkdir -p /usr/local/java tar -zxvf jdk-6u45-linux-x64.tar.gz -C /usr/local/java/

解压完成之后，检查一下关键目录：

ls -l /usr/local/java/jdk1.6.0_45/bin/java ls -l /usr/local/java/jdk1.6.0_45/jre/lib/rt.jar

这两个文件存在，说明安装包基本完整。如果你发现rt.jar缺失，那一定不是官网原版。

3.2 JAVA_HOME 与环境变量配置

环境变量配置有两种维度：系统级和用户级。系统级我建议不要直接改/etc/profile，而是在/etc/profile.d/下新建一个独立脚本，比如java.sh：

vim /etc/profile.d/java.sh

写入以下内容：

export JAVA_HOME=/usr/local/java/jdk1.6.0_45 export PATH=$JAVA_HOME/bin:$PATH export CLASSPATH=.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar

为什么这么配？JAVA_HOME是很多中间件（Tomcat、WebLogic）读取的固定变量，写死完整版本号路径，能保证环境不串；PATH把 JDK 的 bin 放在最前面，避免系统自带的 OpenJDK 抢先被执行；CLASSPATH里带上dt.jar和tools.jar，是应对老项目用 ant 或直接javac编译时出现“包不存在”的问题，虽然 1.6 之后类路径的默认逻辑已经有了变化，但老项目按这个配置最不容易出幺蛾子。配置完执行：

source /etc/profile.d/java.sh java -version

3.3 多 JDK 版本共存的切换方案

服务器上如果同时装了 OpenJDK 8，或者新项目需要 JDK 11，环境变量就不能写死了。推荐用alternatives管理命令级版本，这是 CentOS/RHEL 系的传统方案：

update-alternatives --install /usr/bin/java java /usr/local/java/jdk1.6.0_45/bin/java 300 update-alternatives --install /usr/bin/javac javac /usr/local/java/jdk1.6.0_45/bin/javac 300

数字 300 是优先级，数值大的优先级高。需要切换时执行：

update-alternatives --config java

它会列出所有已注册的 JDK，输入编号即可切换。但要注意，update-alternatives只管理/usr/bin/java这个命令级链接，管不了JAVA_HOME。所以更推荐的做法是：系统命令用alternatives控制，JAVA_HOME写入服务的独立启动脚本里，哪个服务用哪个 JDK 由脚本自己指定，互不干扰。用 Dubbo 老服务做例子，启动脚本里这样写：

export JAVA_HOME=/usr/local/java/jdk1.6.0_45 startCommand="$JAVA_HOME/bin/java -Xms256m -Xmx1024m -XX:MaxPermSize=256m -jar app.jar"

这样切换 JDK 只是改一行路径的事情。

3.4 验证安装是否生效

配置完环境变量，验证分为三步。第一步看版本：

java -version

正常的输出应该是：

java version "1.6.0_45" Java(TM) SE Runtime Environment (build 1.6.0_45-b06) Java HotSpot(TM) 64-Bit Server VM (build 20.45-b01, mixed mode)

看到Java(TM)字样，说明这是 Oracle 官方版；看到OpenJDK说明优先级没调整对。第二步看编译器和JAVA_HOME：

javac -version echo $JAVA_HOME

javac输出 1.6.0_45，JAVA_HOME指向/usr/local/java/jdk1.6.0_45，基本就稳了。第三步写一个最简单的 HelloWorld 测试编译运行，不要跳过去，后面排查问题会需要确认是“JDK 环境问题”而不是“业务代码问题”。

4. 老项目部署验证与常见故障排查

4.1 老项目的典型启动参数

JDK 1.6 时代的 JVM 参数和现在有一个重要区别：没有Metaspace，而是PermGen（永久代）。很多老项目在升级到新 JDK 后会报java.lang.OutOfMemoryError: PermGen space，就是因为 1.6 里永久代默认最大只有 64MB 或 128MB，而老项目加载的类一多就爆。用 1.6 跑老项目，启动脚本里这几个参数几乎是标配：

JAVA_OPTS="-server -Xms512m -Xmx2048m -XX:MaxPermSize=256m -XX:+UseConcMarkSweepGC"

-server表示使用服务端 JVM 编译器，适合长时间运行的服务器程序；-Xms和-Xmx控制堆内存初始值和最大值，生产环境两者通常设为相同值，避免运行时动态扩容带来的性能抖动；-XX:MaxPermSize=256m是给永久代留出余量，具体大小根据应用的类数量调整，一般 256m 到 512m 之间足够。-XX:+UseConcMarkSweepGC是 1.6 时代比较稳的并发回收器，虽然现在看老了，但在当时的线上表现比默认的吞吐优先回收器更平滑。

4.2 常见启动错误与排查顺序

我在多个环境里踩过不同类型的坑，整理下来大致是这几类：

排查顺序也有讲究，别一上来就怀疑 JDK 有问题。先跑了java -version确认基础环境，再跑 HelloWorld 确认编译运行链路，最后才启动业务应用。把问题锁定在“业务代码”还是“环境配置”，能省下大量时间。我见过一个典型案例：应用启动报类找不到，排查了半天，最后发现是 JDK 目录被某个清理脚本删了一半，rt.jar都残了，重装一次就好了。

4.3 老项目的字符编码问题

Linux 服务器默认字符集一般是 UTF-8，但很多老项目内部用的是 GBK 编码，比如某些 OA 系统导出的 Excel 文件名、请求参数的 URL 编码。JDK 1.6 在没有显式指定字符集时，会取操作系统的默认字符集，Linux 上就是 UTF-8，这会导致老项目出现中文乱码。正确做法是在启动参数里显式指定：

JAVA_OPTS="$JAVA_OPTS -Dfile.encoding=GBK -Dsun.jnu.encoding=GBK"

file.encoding负责文件读写时的默认字符集，sun.jnu.encoding负责文件名编码和命令行参数解析。两个要一起设，否则可能出现“文件内容正常但文件名乱码”的割裂问题。如果项目代码本身用的是 UTF-8，那就不用改，保持系统默认即可。判断依据很简单：看老项目里有没有new String(bytes, "GBK")这类代码，或者配置管理系统中是否指定过编码。

4.4 权限与服务用户配置

官方原版 JDK 解压后，属主是执行解压命令的用户。如果使用 root 解压，再放到/usr/local/java/，普通应用用户可能无法读取。稳妥的做法是给整个 JDK 目录设置统一的访问权限：

chown -R root:root /usr/local/java/jdk1.6.0_45 chmod -R 755 /usr/local/java/jdk1.6.0_45

目录 755 意味着所有用户可读可执行，但不能写入。JDK 本身不需要写权限，这样设置既安全又能让所有服务账号正常调用。如果业务应用需要动态生成临时文件，它应该写到自己目录的temp下，而不是 JDK 目录里。还有一点，如果用/usr/bin/java软链接的方式启动服务，注意软链接指向的最终目标不能被移动，否则会出现No such file。

5. 运维心得与后续维护建议

5.1 建立 JDK 目录基线校验

老环境最怕“不动”，但真实运维里难免有人去动。我给存量服务器做基线管理时，会把关键文件算一遍哈希：

find /usr/local/java/jdk1.6.0_45 -type f -name "*.jar" -exec md5sum {} \; > /opt/jdk_baseline.md5

后续巡检时再执行一次md5sum -c /opt/jdk_baseline.md5，就能快速发现哪些 jar 包被篡改或误删。这个习惯在多人维护的服务器上尤其有用，曾经帮我抓出过一个“帮同事替换 rt.jar 内类文件”的现场。用 1.6 的团队通常运维流程不太规范，用这种轻量基线，能在不引入复杂平台的情况下提升可控性。

5.2 安全风险意识

1.6.0_45 已经是生命周期结束的版本，没有安全补丁，这是客观事实。如果项目无法升级，在运维上要额外做几个动作：禁止该 JVM 进程监听公网端口，必须监听时前面加代理或防火墙规则；关闭不必要的 JMX 远程端口；给启动脚本所在目录配置严格权限；定期备份整个 JDK 目录到离线存储。这些措施不能弥补漏洞，但能降低被外部触碰的概率。内部系统还要注意，其他团队如果做漏洞扫描，很可能会把老 JDK 标为高风险项，提前准备一份“业务现状说明”比临时解释更有用。

5.3 后续升级的一个过渡思路

如果实在有升级需求，不要指望一步从 1.6 跳到 17。比较平滑的路径是：先升到 JDK 8，因为 1.6 到 8 的 API 变化相对可控，rt.jar结构仍然存在，老代码的改动量最小；团队在 JDK 8 上跑通后，再用工具分析代码里对内部 API 的依赖，逐步往高版本迁移。升级期间，JDK 8 和 1.6 可以共存，用启动脚本指定各自的JAVA_HOME，先灰度几个边缘服务，稳定后再批量切换。给老项目留一条“能回滚”的路，比一步到位重要得多。

最后再分享一个实际运维里很有用的小技巧：遇到 JDK 相关疑难杂症，先看$JAVA_HOME/bin/java -XshowSettings输出，它能列出当前 JVM 读到的系统属性、文件编码和类路径默认值。很多乱码和类加载问题，一眼就能从这里找到症结。装了 1.6 之后不要急着跑业务，先执行一遍这个命令，把基线信息留存下来，后面对比分析会非常省事。

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