简介JDK 1.6.0_45 是 Oracle 面向 Linux 平台发布的官方原版 Java 开发工具包适合仍需维护老版本 Java 项目的开发者、运维人员及教学环境使用可解决因兼容性要求而无法升级到新版本 JDK 的问题。压缩包为 gz 格式共约 2000 个文件整体约 81MB其中包含 314 个 jar 类库、1326 个 html 文档、171 个 xml 配置、49 个 java 源码及 47 个 so 本地库等覆盖编译器、虚拟机、运行时环境、调试与监控工具等完整组件。目前已有 1060 人学习下载。通过该资源可获取官方原版安装文件与配套类库便于在 Linux 服务器上完成部署与版本锁定同时保留 javadoc 文档、时区数据及安全补丁为旧项目编译、调试和运行提供可靠支撑。1. 官网原版jdk1.6.0_45linux为什么老系统维护绕不开这个包接手一套跑了七八年的老业务系统登录服务器第一件事不是看代码而是敲java -version。屏幕上跳出1.6.0_45那一刻心里反而踏实——版本对上了后面排查问题才有基准。官网原版jdk1.6.0_45linux这个包在今天的开发环境里几乎没人主动装但在遗留系统维护、老中间件部署、特定行业软件的运行环境搭建中它仍然是绕不过去的一环。很多老系统编译时依赖的字节码版本、加密算法实现、字符集默认行为都跟这个版本绑死换成高版本JDK轻则启动报错重则业务逻辑悄悄跑偏。这篇文章面向的是需要在一台Linux机器上把这个版本装好、配好、跑起来的一线人员不讲Java历史只讲怎么落地、参数怎么设、哪里容易翻车。2. 装之前先搞清楚这个包到底该从哪来、怎么验2.1 为什么必须强调「官网原版」这四个字老系统的维护现场最怕的不是版本旧而是版本来源不明。网上流传的很多JDK压缩包有的是二次打包、有的被替换过核心jar、有的甚至夹带了改过的加密策略文件。装上去当时能跑等到某个签名校验或者SSL握手环节出问题排查方向会被彻底带偏。我一般坚持用官网归档渠道拿到的原版包文件名通常形如jdk-6u45-linux-x64.bin或jdk-6u45-linux-i586.bin前者是64位后者是32位。判断依据很简单uname -m输出x86_64就用x64输出i686或i386就用i586。选错架构的后果不是装不上而是装上了跑不起来报cannot execute binary file这个坑新手很容易踩。拿到包之后第一件事是校验完整性。官网归档一般会提供对应的校验值常见做法是比对SHA256。没有官方校验值时至少确认文件大小和类型合理别拿到一个几MB的残缺文件。# 查看文件类型确认是可执行的安装脚本而非普通压缩包 file jdk-6u45-linux-x64.bin # 计算SHA256与官方归档页提供的值比对 sha256sum jdk-6u45-linux-x64.bin # 查看当前机器架构决定用x64还是i586 uname -mfile命令的输出应该显示为ELF 64-bit LSB executable之类如果显示成gzip compressed data说明这个bin文件可能被错误处理过。sha256sum的结果必须和来源页一致不一致直接丢弃重下不要抱侥幸心理。uname -m是选架构的唯一依据不要凭感觉。2.2 安装路径的选择与目录规划JDK装哪里看似小事实则影响后续所有脚本的维护成本。常见做法有两种装到/usr/java/下或者装到/opt/下。我倾向于/usr/java/jdk1.6.0_45这种带完整版本号的路径因为一台机器上可能同时存在多个JDK版本路径里带版本号切换时改环境变量就行不会互相覆盖。安装过程本身不复杂bin包本质是一个自解压脚本。给它执行权限运行它会解压出一个目录。这里有个细节运行bin包时它会问你是否接受许可协议交互式输入在自动化脚本里很麻烦。可以用-n参数跳过交互但要注意这个参数在不同小版本上行为可能不一致最稳妥的方式还是先手动跑一遍确认。# 创建统一存放目录 mkdir -p /usr/java # 赋予执行权限 chmod x jdk-6u45-linux-x64.bin # 静默解压到当前目录-n表示不交互 ./jdk-6u45-linux-x64.bin -n # 解压后会生成 jdk1.6.0_45 目录移动到规划路径 mv jdk1.6.0_45 /usr/java/ # 确认目录结构完整 ls /usr/java/jdk1.6.0_45/bin/java-n参数的作用是跳过许可确认适合脚本化部署。mv之后要确认bin/java存在且可执行这是判断解压是否完整的直接标准。如果bin目录下文件缺失多半是下载或解压过程出了问题重新来一遍比修修补补更省时间。2.3 环境变量配置JAVA_HOME、PATH、CLASSPATH 的取舍环境变量配错是老系统上最常见的「玄学问题」来源。JAVA_HOME 必须指向JDK根目录不是bin目录也不是jre目录。PATH 里要把$JAVA_HOME/bin放在前面避免系统里已有的其他java先被找到。CLASSPATH 在现代Java项目里基本不用手动设但老系统有时依赖它加载特定jar这个要看具体应用的启动脚本怎么写的。配置写到/etc/profile.d/下单独一个文件比直接改/etc/profile更干净也方便后续卸载时清理。# 创建独立的环境变量配置文件 cat /etc/profile.d/java6.sh EOF export JAVA_HOME/usr/java/jdk1.6.0_45 export PATH$JAVA_HOME/bin:$PATH export CLASSPATH.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar EOF # 使配置立即生效 source /etc/profile.d/java6.sh # 验证版本 java -version javac -versionJAVA_HOME指向根目录PATH把JDK的bin前置CLASSPATH里的.表示当前目录dt.jar和tools.jar是JDK6时代编译和工具链需要的。source之后java -version应该输出java version 1.6.0_45如果输出的是其他版本说明PATH里有更高优先级的java用which java查一下实际调用的路径。javac -version也要确认有些场景只需要JRE但维护老系统通常需要完整JDK。3. 让老JDK在新Linux上跑起来兼容性处理与最小验证3.1 高版本glibc下的启动报错与应对把JDK6装到比较新的Linux发行版上最常见的翻车现场是启动时报Error: dl failure on line 864或者libjli.so: cannot open shared object file。原因不复杂JDK6编译时链接的glibc版本较老新系统的动态链接器行为有变化导致JVM启动时找不到它期望的库路径。这不是JDK坏了是运行环境差异。处理思路有两条。一是补一个软链接把JDK自带的lib路径暴露给动态链接器二是通过LD_LIBRARY_PATH显式指定。我一般用第一种因为对全局影响小只针对这个JDK。# 查看具体缺哪个库 ldd /usr/java/jdk1.6.0_45/bin/java | grep not found # 常见做法把JDK的lib目录加入动态链接器搜索路径 echo /usr/java/jdk1.6.0_45/jre/lib/amd64 /etc/ld.so.conf.d/java6.conf echo /usr/java/jdk1.6.0_45/jre/lib/amd64/server /etc/ld.so.conf.d/java6.conf ldconfig # 再次验证 java -versionldd用来定位缺失的共享库grep not found把问题行筛出来。/etc/ld.so.conf.d/下加配置文件是标准做法ldconfig刷新缓存。注意路径里的amd64在32位系统上要换成i386。如果ldd显示的不是「not found」而是版本符号不匹配那就不是路径问题需要更谨慎地评估是否要在这个系统上跑JDK6。3.2 时区与字符集两个容易被忽略的默认值JDK6的默认时区和字符集行为跟新版本有差异。时区方面如果系统时区文件更新过JDK6可能读不到新的时区数据导致new Date()出来的时间差几个小时。字符集方面JDK6在Linux上的默认文件编码跟随系统locale如果locale是en_US.UTF-8一般没问题但如果是POSIX或C中文就会变成乱码。验证方法很直接写一个最小的Java类打印这两项。// EnvCheck.java public class EnvCheck { public static void main(String[] args) { // 打印默认时区 System.out.println(Timezone: java.util.TimeZone.getDefault().getID()); // 打印默认字符集 System.out.println(Charset: java.nio.charset.Charset.defaultCharset().name()); // 打印文件编码相关属性 System.out.println(file.encoding: System.getProperty(file.encoding)); System.out.println(user.timezone: System.getProperty(user.timezone)); } }编译运行javac EnvCheck.java java EnvCheck看输出是否符合预期。如果时区不对可以在启动参数里加-Duser.timezoneAsia/Shanghai。如果字符集不对加-Dfile.encodingUTF-8。这两个参数在老系统的启动脚本里经常能看到不是可有可无的装饰是实打实解决过问题的。3.3 最小可运行验证编译、打包、运行三步走装完配完别急着往生产上部署先做一个最小闭环验证。写一个类编译成class打成jar再运行。这三步能过说明JDK的编译链、打包工具、运行环境都是通的。# 编译 javac -d ./classes EnvCheck.java # 打包 jar cvf envcheck.jar -C ./classes . # 运行 java -cp envcheck.jar EnvCheck-d指定class输出目录jar cvf创建jar包-C切换目录后把classes下的内容打进去。运行时的-cp指定classpath。这三条命令如果都成功说明这个JDK在这台机器上是可用的。任何一步失败错误信息都指向具体环节比直接跑一个复杂应用再去猜问题要高效得多。4. 避坑与排查老JDK部署现场的五个血泪教训4.1 现象java命令找不到但JAVA_HOME明明设了原因通常是环境变量只在当前shell生效或者配置文件没被正确加载。/etc/profile.d/下的脚本需要重新登录或source才生效而且有些发行版的非交互式shell不会加载profile。解决方式是确认echo $JAVA_HOME有输出没有的话检查文件权限和shell类型。如果是通过cron或systemd启动的服务环境变量要在服务配置里单独指定不能指望profile。4.2 现象编译时报「不支持发行版本」或class文件版本错误这是用高版本JDK编译了目标为低版本的代码或者反过来。JDK6的class文件版本号是50JDK8是52。如果编译时用了-source和-target参数但没配套设-bootclasspath编译出来的class可能引用了高版本才有的API在JDK6上运行就报NoSuchMethodError。老系统维护时编译参数要跟运行环境严格对齐别图省事。4.3 现象应用启动慢或者卡在某个加密环节JDK6早期版本对某些加密算法的支持依赖额外的策略文件默认的local_policy.jar和US_export_policy.jar有限制。如果应用用到AES-256之类的强加密可能会卡住或抛异常。解决方式是确认$JAVA_HOME/jre/lib/security/下的策略文件是否是无限制版本。这个坑在对接外部系统时特别常见因为对方用的加密强度可能超过默认策略允许的范围。4.4 现象内存明明够却报OutOfMemoryError老JDK的默认堆大小计算方式跟新版本不同在容器环境或大内存机器上默认值可能偏小。另外JDK6对MaxPermSize的依赖比较明显很多老应用需要显式设置永久代大小。启动参数里加上-Xms、-Xmx、-XX:MaxPermSize是常规操作。排查时先用jstat -gc看各区域使用情况别一上来就盲目调大。4.5 现象中文日志乱码但页面显示正常这种「一半正常一半乱码」的情况通常是日志框架的编码配置和JVM默认编码不一致导致的。页面显示走的是HTTP响应头里的编码日志走的是file.encoding。解决方式是统一在启动参数里指定-Dfile.encodingUTF-8同时检查日志配置文件里有没有硬编码其他编码。两边对齐了乱码自然消失。5. 进阶技巧多版本共存与快速切换的实用手法一台机器上同时存在JDK6和JDK8甚至更高版本是维护老系统的常态。硬改/etc/profile里的JAVA_HOME来回切换容易把其他服务搞挂。我习惯用update-alternatives或者自己写一个切换函数按需切换当前shell的JDK。update-alternatives是Debian系和RedHat系都有的工具注册多个JDK后可以用命令切换。但老系统上不一定有这个工具而且它影响的是全局默认不适合「只在这个终端里用JDK6」的场景。更轻量的做法是在~/.bashrc里定义函数。# 在 ~/.bashrc 中定义切换函数 function usejava6() { export JAVA_HOME/usr/java/jdk1.6.0_45 export PATH$JAVA_HOME/bin:$PATH echo Switched to JDK 1.6.0_45 } function usejava8() { export JAVA_HOME/usr/java/jdk1.8.0_xxx export PATH$JAVA_HOME/bin:$PATH echo Switched to JDK 1.8 }这样在需要跑老应用的终端里执行usejava6其他终端不受影响。函数里重新赋值PATH时把新JDK的bin前置避免旧路径残留。切换后用java -version确认别嫌麻烦这一步能省掉后面很多「为什么还是旧版本」的困惑。另一个实用技巧是给老应用的启动脚本里直接写死JDK路径不依赖环境变量。比如JAVA_HOME/usr/java/jdk1.6.0_45写在脚本开头这样即使运维人员误改了全局配置应用启动时用的还是正确的JDK。这个做法看起来笨但在多人维护的环境里笨办法往往最可靠。验证JDK是否被正确使用除了java -version还可以看java -XshowSettings:properties -version 21 | grep java.home这个输出更详细能看到实际的java.home路径。排查「版本不对」类问题时这个命令比java -version更有说服力。最后说一个我自己的习惯每次在一台新机器上部署完JDK6都会把安装路径、环境变量文件位置、验证命令的输出记录到一个文本文件里放在/root/下。过几个月再回来排查问题不用重新回忆当时怎么装的。这个习惯帮我省过很多次「后悔药」。老系统的维护周期长人员流动大留下清晰的部署记录比任何自动化工具都管用。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/15 14:51:58 · 阅读 1.2k 官网原版JDK 1.6.0_45 Linux安装配置与老系统维护实战
简介JDK 1.6.0_45 是 Oracle 面向 Linux 平台发布的官方原版 Java 开发工具包适合仍需维护老版本 Java 项目的开发者、运维人员及教学环境使用可解决因兼容性要求而无法升级到新版本 JDK 的问题。压缩包为 gz 格式共约 2000 个文件整体约 81MB其中包含 314 个 jar 类库、1326 个 html 文档、171 个 xml 配置、49 个 java 源码及 47 个 so 本地库等覆盖编译器、虚拟机、运行时环境、调试与监控工具等完整组件。目前已有 1060 人学习下载。通过该资源可获取官方原版安装文件与配套类库便于在 Linux 服务器上完成部署与版本锁定同时保留 javadoc 文档、时区数据及安全补丁为旧项目编译、调试和运行提供可靠支撑。1. 官网原版jdk1.6.0_45linux为什么老系统维护绕不开这个包接手一套跑了七八年的老业务系统登录服务器第一件事不是看代码而是敲java -version。屏幕上跳出1.6.0_45那一刻心里反而踏实——版本对上了后面排查问题才有基准。官网原版jdk1.6.0_45linux这个包在今天的开发环境里几乎没人主动装但在遗留系统维护、老中间件部署、特定行业软件的运行环境搭建中它仍然是绕不过去的一环。很多老系统编译时依赖的字节码版本、加密算法实现、字符集默认行为都跟这个版本绑死换成高版本JDK轻则启动报错重则业务逻辑悄悄跑偏。这篇文章面向的是需要在一台Linux机器上把这个版本装好、配好、跑起来的一线人员不讲Java历史只讲怎么落地、参数怎么设、哪里容易翻车。2. 装之前先搞清楚这个包到底该从哪来、怎么验2.1 为什么必须强调「官网原版」这四个字老系统的维护现场最怕的不是版本旧而是版本来源不明。网上流传的很多JDK压缩包有的是二次打包、有的被替换过核心jar、有的甚至夹带了改过的加密策略文件。装上去当时能跑等到某个签名校验或者SSL握手环节出问题排查方向会被彻底带偏。我一般坚持用官网归档渠道拿到的原版包文件名通常形如jdk-6u45-linux-x64.bin或jdk-6u45-linux-i586.bin前者是64位后者是32位。判断依据很简单uname -m输出x86_64就用x64输出i686或i386就用i586。选错架构的后果不是装不上而是装上了跑不起来报cannot execute binary file这个坑新手很容易踩。拿到包之后第一件事是校验完整性。官网归档一般会提供对应的校验值常见做法是比对SHA256。没有官方校验值时至少确认文件大小和类型合理别拿到一个几MB的残缺文件。# 查看文件类型确认是可执行的安装脚本而非普通压缩包 file jdk-6u45-linux-x64.bin # 计算SHA256与官方归档页提供的值比对 sha256sum jdk-6u45-linux-x64.bin # 查看当前机器架构决定用x64还是i586 uname -mfile命令的输出应该显示为ELF 64-bit LSB executable之类如果显示成gzip compressed data说明这个bin文件可能被错误处理过。sha256sum的结果必须和来源页一致不一致直接丢弃重下不要抱侥幸心理。uname -m是选架构的唯一依据不要凭感觉。2.2 安装路径的选择与目录规划JDK装哪里看似小事实则影响后续所有脚本的维护成本。常见做法有两种装到/usr/java/下或者装到/opt/下。我倾向于/usr/java/jdk1.6.0_45这种带完整版本号的路径因为一台机器上可能同时存在多个JDK版本路径里带版本号切换时改环境变量就行不会互相覆盖。安装过程本身不复杂bin包本质是一个自解压脚本。给它执行权限运行它会解压出一个目录。这里有个细节运行bin包时它会问你是否接受许可协议交互式输入在自动化脚本里很麻烦。可以用-n参数跳过交互但要注意这个参数在不同小版本上行为可能不一致最稳妥的方式还是先手动跑一遍确认。# 创建统一存放目录 mkdir -p /usr/java # 赋予执行权限 chmod x jdk-6u45-linux-x64.bin # 静默解压到当前目录-n表示不交互 ./jdk-6u45-linux-x64.bin -n # 解压后会生成 jdk1.6.0_45 目录移动到规划路径 mv jdk1.6.0_45 /usr/java/ # 确认目录结构完整 ls /usr/java/jdk1.6.0_45/bin/java-n参数的作用是跳过许可确认适合脚本化部署。mv之后要确认bin/java存在且可执行这是判断解压是否完整的直接标准。如果bin目录下文件缺失多半是下载或解压过程出了问题重新来一遍比修修补补更省时间。2.3 环境变量配置JAVA_HOME、PATH、CLASSPATH 的取舍环境变量配错是老系统上最常见的「玄学问题」来源。JAVA_HOME 必须指向JDK根目录不是bin目录也不是jre目录。PATH 里要把$JAVA_HOME/bin放在前面避免系统里已有的其他java先被找到。CLASSPATH 在现代Java项目里基本不用手动设但老系统有时依赖它加载特定jar这个要看具体应用的启动脚本怎么写的。配置写到/etc/profile.d/下单独一个文件比直接改/etc/profile更干净也方便后续卸载时清理。# 创建独立的环境变量配置文件 cat /etc/profile.d/java6.sh EOF export JAVA_HOME/usr/java/jdk1.6.0_45 export PATH$JAVA_HOME/bin:$PATH export CLASSPATH.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar EOF # 使配置立即生效 source /etc/profile.d/java6.sh # 验证版本 java -version javac -versionJAVA_HOME指向根目录PATH把JDK的bin前置CLASSPATH里的.表示当前目录dt.jar和tools.jar是JDK6时代编译和工具链需要的。source之后java -version应该输出java version 1.6.0_45如果输出的是其他版本说明PATH里有更高优先级的java用which java查一下实际调用的路径。javac -version也要确认有些场景只需要JRE但维护老系统通常需要完整JDK。3. 让老JDK在新Linux上跑起来兼容性处理与最小验证3.1 高版本glibc下的启动报错与应对把JDK6装到比较新的Linux发行版上最常见的翻车现场是启动时报Error: dl failure on line 864或者libjli.so: cannot open shared object file。原因不复杂JDK6编译时链接的glibc版本较老新系统的动态链接器行为有变化导致JVM启动时找不到它期望的库路径。这不是JDK坏了是运行环境差异。处理思路有两条。一是补一个软链接把JDK自带的lib路径暴露给动态链接器二是通过LD_LIBRARY_PATH显式指定。我一般用第一种因为对全局影响小只针对这个JDK。# 查看具体缺哪个库 ldd /usr/java/jdk1.6.0_45/bin/java | grep not found # 常见做法把JDK的lib目录加入动态链接器搜索路径 echo /usr/java/jdk1.6.0_45/jre/lib/amd64 /etc/ld.so.conf.d/java6.conf echo /usr/java/jdk1.6.0_45/jre/lib/amd64/server /etc/ld.so.conf.d/java6.conf ldconfig # 再次验证 java -versionldd用来定位缺失的共享库grep not found把问题行筛出来。/etc/ld.so.conf.d/下加配置文件是标准做法ldconfig刷新缓存。注意路径里的amd64在32位系统上要换成i386。如果ldd显示的不是「not found」而是版本符号不匹配那就不是路径问题需要更谨慎地评估是否要在这个系统上跑JDK6。3.2 时区与字符集两个容易被忽略的默认值JDK6的默认时区和字符集行为跟新版本有差异。时区方面如果系统时区文件更新过JDK6可能读不到新的时区数据导致new Date()出来的时间差几个小时。字符集方面JDK6在Linux上的默认文件编码跟随系统locale如果locale是en_US.UTF-8一般没问题但如果是POSIX或C中文就会变成乱码。验证方法很直接写一个最小的Java类打印这两项。// EnvCheck.java public class EnvCheck { public static void main(String[] args) { // 打印默认时区 System.out.println(Timezone: java.util.TimeZone.getDefault().getID()); // 打印默认字符集 System.out.println(Charset: java.nio.charset.Charset.defaultCharset().name()); // 打印文件编码相关属性 System.out.println(file.encoding: System.getProperty(file.encoding)); System.out.println(user.timezone: System.getProperty(user.timezone)); } }编译运行javac EnvCheck.java java EnvCheck看输出是否符合预期。如果时区不对可以在启动参数里加-Duser.timezoneAsia/Shanghai。如果字符集不对加-Dfile.encodingUTF-8。这两个参数在老系统的启动脚本里经常能看到不是可有可无的装饰是实打实解决过问题的。3.3 最小可运行验证编译、打包、运行三步走装完配完别急着往生产上部署先做一个最小闭环验证。写一个类编译成class打成jar再运行。这三步能过说明JDK的编译链、打包工具、运行环境都是通的。# 编译 javac -d ./classes EnvCheck.java # 打包 jar cvf envcheck.jar -C ./classes . # 运行 java -cp envcheck.jar EnvCheck-d指定class输出目录jar cvf创建jar包-C切换目录后把classes下的内容打进去。运行时的-cp指定classpath。这三条命令如果都成功说明这个JDK在这台机器上是可用的。任何一步失败错误信息都指向具体环节比直接跑一个复杂应用再去猜问题要高效得多。4. 避坑与排查老JDK部署现场的五个血泪教训4.1 现象java命令找不到但JAVA_HOME明明设了原因通常是环境变量只在当前shell生效或者配置文件没被正确加载。/etc/profile.d/下的脚本需要重新登录或source才生效而且有些发行版的非交互式shell不会加载profile。解决方式是确认echo $JAVA_HOME有输出没有的话检查文件权限和shell类型。如果是通过cron或systemd启动的服务环境变量要在服务配置里单独指定不能指望profile。4.2 现象编译时报「不支持发行版本」或class文件版本错误这是用高版本JDK编译了目标为低版本的代码或者反过来。JDK6的class文件版本号是50JDK8是52。如果编译时用了-source和-target参数但没配套设-bootclasspath编译出来的class可能引用了高版本才有的API在JDK6上运行就报NoSuchMethodError。老系统维护时编译参数要跟运行环境严格对齐别图省事。4.3 现象应用启动慢或者卡在某个加密环节JDK6早期版本对某些加密算法的支持依赖额外的策略文件默认的local_policy.jar和US_export_policy.jar有限制。如果应用用到AES-256之类的强加密可能会卡住或抛异常。解决方式是确认$JAVA_HOME/jre/lib/security/下的策略文件是否是无限制版本。这个坑在对接外部系统时特别常见因为对方用的加密强度可能超过默认策略允许的范围。4.4 现象内存明明够却报OutOfMemoryError老JDK的默认堆大小计算方式跟新版本不同在容器环境或大内存机器上默认值可能偏小。另外JDK6对MaxPermSize的依赖比较明显很多老应用需要显式设置永久代大小。启动参数里加上-Xms、-Xmx、-XX:MaxPermSize是常规操作。排查时先用jstat -gc看各区域使用情况别一上来就盲目调大。4.5 现象中文日志乱码但页面显示正常这种「一半正常一半乱码」的情况通常是日志框架的编码配置和JVM默认编码不一致导致的。页面显示走的是HTTP响应头里的编码日志走的是file.encoding。解决方式是统一在启动参数里指定-Dfile.encodingUTF-8同时检查日志配置文件里有没有硬编码其他编码。两边对齐了乱码自然消失。5. 进阶技巧多版本共存与快速切换的实用手法一台机器上同时存在JDK6和JDK8甚至更高版本是维护老系统的常态。硬改/etc/profile里的JAVA_HOME来回切换容易把其他服务搞挂。我习惯用update-alternatives或者自己写一个切换函数按需切换当前shell的JDK。update-alternatives是Debian系和RedHat系都有的工具注册多个JDK后可以用命令切换。但老系统上不一定有这个工具而且它影响的是全局默认不适合「只在这个终端里用JDK6」的场景。更轻量的做法是在~/.bashrc里定义函数。# 在 ~/.bashrc 中定义切换函数 function usejava6() { export JAVA_HOME/usr/java/jdk1.6.0_45 export PATH$JAVA_HOME/bin:$PATH echo Switched to JDK 1.6.0_45 } function usejava8() { export JAVA_HOME/usr/java/jdk1.8.0_xxx export PATH$JAVA_HOME/bin:$PATH echo Switched to JDK 1.8 }这样在需要跑老应用的终端里执行usejava6其他终端不受影响。函数里重新赋值PATH时把新JDK的bin前置避免旧路径残留。切换后用java -version确认别嫌麻烦这一步能省掉后面很多「为什么还是旧版本」的困惑。另一个实用技巧是给老应用的启动脚本里直接写死JDK路径不依赖环境变量。比如JAVA_HOME/usr/java/jdk1.6.0_45写在脚本开头这样即使运维人员误改了全局配置应用启动时用的还是正确的JDK。这个做法看起来笨但在多人维护的环境里笨办法往往最可靠。验证JDK是否被正确使用除了java -version还可以看java -XshowSettings:properties -version 21 | grep java.home这个输出更详细能看到实际的java.home路径。排查「版本不对」类问题时这个命令比java -version更有说服力。最后说一个我自己的习惯每次在一台新机器上部署完JDK6都会把安装路径、环境变量文件位置、验证命令的输出记录到一个文本文件里放在/root/下。过几个月再回来排查问题不用重新回忆当时怎么装的。这个习惯帮我省过很多次「后悔药」。老系统的维护周期长人员流动大留下清晰的部署记录比任何自动化工具都管用。希望帮到你。本文还有配套的精品资源点击获取