简介这是一份面向 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 6JBoss 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 和 x64uname -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.shvim /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 -version3.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:MaxPermSize256m -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_HOMEjavac -version echo $JAVA_HOMEjavac输出 1.6.0_45JAVA_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:MaxPermSize256m -XX:UseConcMarkSweepGC-server表示使用服务端 JVM 编译器适合长时间运行的服务器程序-Xms和-Xmx控制堆内存初始值和最大值生产环境两者通常设为相同值避免运行时动态扩容带来的性能抖动-XX:MaxPermSize256m是给永久代留出余量具体大小根据应用的类数量调整一般 256m 到 512m 之间足够。-XX:UseConcMarkSweepGC是 1.6 时代比较稳的并发回收器虽然现在看老了但在当时的线上表现比默认的吞吐优先回收器更平滑。4.2 常见启动错误与排查顺序我在多个环境里踩过不同类型的坑整理下来大致是这几类错误现象可能原因解决办法bash: java: command not foundPATH 未生效或配错执行source /etc/profile.d/java.sh检查which java-bash: /usr/bin/java: No such file or directory动态链接器缺失或 32 位/64 位包和系统不匹配用file $JAVA_HOME/bin/java确认位数安装对应位数的 glibcError: could not open .../jre/lib/amd64/jvm.cfg安装目录被移动过相对路径失效解压后不要移动整个 JDK 目录重新解压到固定路径Unsupported major.minor version 50.0字节码版本高于 1.6用javac -target 1.6 -source 1.6重新编译或更换 JDKjava.lang.OutOfMemoryError: PermGen space永久代空间不足加大-XX:MaxPermSize排查顺序也有讲究别一上来就怀疑 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.encodingGBK -Dsun.jnu.encodingGBKfile.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 之后不要急着跑业务先执行一遍这个命令把基线信息留存下来后面对比分析会非常省事。本文还有配套的精品资源点击获取
简介这是一份面向 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 6JBoss 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 和 x64uname -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.shvim /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 -version3.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:MaxPermSize256m -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_HOMEjavac -version echo $JAVA_HOMEjavac输出 1.6.0_45JAVA_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:MaxPermSize256m -XX:UseConcMarkSweepGC-server表示使用服务端 JVM 编译器适合长时间运行的服务器程序-Xms和-Xmx控制堆内存初始值和最大值生产环境两者通常设为相同值避免运行时动态扩容带来的性能抖动-XX:MaxPermSize256m是给永久代留出余量具体大小根据应用的类数量调整一般 256m 到 512m 之间足够。-XX:UseConcMarkSweepGC是 1.6 时代比较稳的并发回收器虽然现在看老了但在当时的线上表现比默认的吞吐优先回收器更平滑。4.2 常见启动错误与排查顺序我在多个环境里踩过不同类型的坑整理下来大致是这几类错误现象可能原因解决办法bash: java: command not foundPATH 未生效或配错执行source /etc/profile.d/java.sh检查which java-bash: /usr/bin/java: No such file or directory动态链接器缺失或 32 位/64 位包和系统不匹配用file $JAVA_HOME/bin/java确认位数安装对应位数的 glibcError: could not open .../jre/lib/amd64/jvm.cfg安装目录被移动过相对路径失效解压后不要移动整个 JDK 目录重新解压到固定路径Unsupported major.minor version 50.0字节码版本高于 1.6用javac -target 1.6 -source 1.6重新编译或更换 JDKjava.lang.OutOfMemoryError: PermGen space永久代空间不足加大-XX:MaxPermSize排查顺序也有讲究别一上来就怀疑 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.encodingGBK -Dsun.jnu.encodingGBKfile.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 之后不要急着跑业务先执行一遍这个命令把基线信息留存下来后面对比分析会非常省事。本文还有配套的精品资源点击获取
