★ FEATURED ARTICLE 简介JDK 1.8 64位Linux版压缩包面向需要在Linux环境搭建Java 8开发与运行环境的开发者也适合维护兼容旧版本项目、部署服务端应用的技术人员。包内共1589个文件整体约185.21MB以701个jar库文件、230个xml配置与描述文件、72个so本地库、49个properties配置、42个html文档及字体、证书等资源为主构成较完整的JDK发行目录可用于编译、调试、运行和监控Java程序。已有1208人学习说明其在Java 8环境准备场景中具有一定参考价值。资源涵盖javac、java、javadoc、jconsole、jvisualvm等常用工具入口并附带核心类库、本地依赖和说明文档便于读者理解JDK 1.8的目录组成配合Lambda表达式、Stream API、新日期时间API等特性进行练习与项目适配也能为旧项目复现和Linux服务器环境核验提供基础材料。1. 从一台干净的 Linux 机器说起jdk1.8-64位Linux版.zip 装错一次会卡在哪一台刚交付的 Linux 机器登录进去只有最基本的命令项目组丢来一个 jdk1.8-64位Linux版.zip说“解压、配个环境变量就能跑”。真照着做十有八九会在java -version那一步翻车要么命令找不到要么版本还是旧的要么服务一启动就报内存保留失败。jdk1.8 这个版本在存量 Java 项目里出现频率很高尤其是老服务、构建机和教学实验环境64 位 Linux 包看着简单实际牵扯架构、权限、PATH 优先级和 alternatives 抢占。下面按一台干净机器的落地顺序把装什么、放哪、怎么配、坏了怎么救拆开。2. 安装前检查jdk1.8-64位Linux版.zip 的架构、权限与目录规划压缩包拿到手先别急着unzip。我见过最常见的翻车不是 JDK 本身有问题而是机器是aarch64包却是按x86_64打的或者旧 Java 还挂在/usr/bin/java上新环境变量写了也没抢到前面。安装前把架构、旧版本、目录三件事查清楚后面能少走很多弯路。2.1 先确认 64 位内核与 CPU 架构先看内核和用户态位数不用猜uname -m getconf LONG_BITuname -m在常见 x86 机器上应返回x86_64getconf LONG_BIT应返回64。如果第一条返回aarch64说明 CPU 架构不是这套包常见的 x86_64 目标jdk1.8-64位Linux版.zip 里的bin/java很可能直接报“无法执行二进制文件”。这不是环境变量能救的得换对应架构的包。第二条返回32时也要注意系统用户态是 32 位跑 64 位 JDK 会缺基础库java -version可能连启动都过不去。顺手看一下落盘空间。JDK 解压后不算大但构建机、CI 节点经常把/usr/local单独分区装到一半空间满了解压出来的目录是残缺的后面报错很玄学df -h /usr/local df -h /tmp/tmp用来放上传包和解压临时目录/usr/local用来放最终安装目录。两个位置都要有足够余量。不要把压缩包直接传到/root再让普通用户去读权限边界一乱后面服务账号启动时读不到JAVA_HOME下的文件排查成本比重新上传高得多。2.2 检查旧 Java 与包管理冲突装新 JDK 之前先看机器上已经有什么type -a java javac 2/dev/null readlink -f $(command -v java) 2/dev/null rpm -qa | grep -i jdk || true dpkg -l | grep -i jdk || truetype -a会把当前 shell 能找到的java、javac全列出来顺序就是 PATH 的命中顺序readlink -f用来追软链最终落到哪个真实路径。rpm和dpkg两条按发行版选一条执行目的是看有没有通过包管理器装过旧 JDK。常见做法是如果旧 JDK 是系统包带的而且还有别的服务依赖它不要上来就删先把新 JDK 放到独立目录用JAVA_HOME和 alternatives 控制优先级。直接卸载系统包可能把依赖它的构建脚本、监控脚本一起弄坏这种血泪经验在共享构建机上尤其常见。还要看 alternatives 当前接管了哪些命令update-alternatives --list java 2/dev/null || true update-alternatives --list javac 2/dev/null || true如果输出里已经有多个路径说明机器上存在多版本并存。此时新装的 jdk1.8 要么提高 alternatives 优先级要么让$JAVA_HOME/bin在 PATH 里排前面。两条路都行但不要只改一半只改java不改javac后面编译和运行版本对不上报错会很难看。2.3 目录规划与权限边界我一般把 JDK 放在/usr/local/jdk1.8父目录用/usr/local/java做多版本收纳。目录名不要带空格也不要放在某个用户的 home 下。服务账号、构建账号、定时任务都可能用同一个 JDK放在 home 下迟早会遇到“当前用户能跑、服务用户跑不了”的权限问题。先建父目录并收紧权限sudo mkdir -p /usr/local/java sudo chown root:root /usr/local/java sudo chmod 755 /usr/local/javaroot:root表示归 root 所有755表示其他用户可读可进入、不可写。JDK 是运行基础件不需要普通用户往里写文件。应用自己的配置、日志、临时目录另放/opt或/data不要把应用写权限开到 JDK 目录里。如果机器上要多版本并存可以保留一个软链sudo ln -sfn /usr/local/jdk1.8 /usr/local/java/default这个软链不是必须的但后面写启动脚本时/usr/local/java/default/bin/java比到处写死版本目录更好维护。注意软链只是入口真正要验证的还是它指向的真实目录里有没有bin/java、jre/lib这些内容。3. 解压与落盘jdk1.8 压缩包从上传到 /usr/local 的完整动作jdk1.8-64位Linux版.zip 的安装动作本身不复杂复杂的是中间少一步校验、多一层目录、权限给错。我的习惯是上传到/tmp先测试压缩包完整性再解压到临时目录确认bin/java的真实位置最后才移动到/usr/local/jdk1.8。这样即使包坏了也不会污染最终目录。3.1 上传后先做完整性检查把包放到/tmp后先看大小和压缩包结构cd /tmp ls -lh jdk1.8-64位Linux版.zip unzip -t jdk1.8-64位Linux版.zip sha256sum jdk1.8-64位Linux版.zipls -lh看文件大小是否和下载页标注一致unzip -t只测试压缩包完整性不释放文件最后出现No errors detected才继续sha256sum用来和传输前后的摘要对比。如果下载页给了校验值就拿这里的结果去比没给校验值至少确认文件大小不是 0unzip -t不报错。中文文件名在 shell 里要加引号不然遇到空格或特殊字符会被拆成多个参数。有些最小化系统没有unzip先补工具command -v unzip || sudo yum install -y unzip # deb 系机器改用 # sudo apt-get update sudo apt-get install -y unzipcommand -v unzip用来判断命令是否存在不存在才走安装。rpm 系和 deb 系二选一不要两条都硬跑。装完再执行一次unzip -t确认不是“工具刚装好、包还没验”的状态。3.2 解压到临时目录并确认顶层结构不要直接解压到/usr/local/jdk1.8先落到临时目录看清楚结构sudo rm -rf /usr/local/java/jdk1.8-untar sudo mkdir -p /usr/local/java/jdk1.8-untar sudo unzip -q /tmp/jdk1.8-64位Linux版.zip -d /usr/local/java/jdk1.8-untar find /usr/local/java/jdk1.8-untar -maxdepth 2 -type d | sort-d指定解压目录-q静默输出避免刷屏。find只看两层目录目的是确认压缩包里面是直接有bin还是多套了一层jdk1.8.0_xxx。很多 JDK 压缩包解压后会多一层版本目录如果你把JAVA_HOME指到外层$JAVA_HOME/bin/java就不存在后面所有配置都会跟着错。如果find输出里看到类似/usr/local/java/jdk1.8-untar/jdk1.8.0_xxx/bin说明真正的主目录是jdk1.8.0_xxx这一层如果看到/usr/local/java/jdk1.8-untar/bin说明压缩包本身没有顶层目录主目录就是解压目录。两种情况都能处理关键是别凭感觉写JAVA_HOME。3.3 改名、授权与挂软链下面这段先自动定位bin/java的父目录再备份旧目录、移动新目录JAVA_BIN$(find /usr/local/java/jdk1.8-untar -type f -path */bin/java | head -n 1) JDK_SRC$(dirname $(dirname $JAVA_BIN)) echo $JDK_SRC [ -x $JDK_SRC/bin/java ] || { echo 未找到 jdk1.8 的 bin/java; exit 1; } if [ -e /usr/local/jdk1.8 ]; then sudo mv /usr/local/jdk1.8 /usr/local/jdk1.8.bak.$(date %Y%m%d%H%M%S) fi sudo mv $JDK_SRC /usr/local/jdk1.8find -path */bin/java找的是可执行文件位置dirname连用两次得到 JDK 根目录[ -x ... ]做一次兜底找不到就退出避免把空变量传给mv。旧目录不是直接删而是加时间戳备份这样发现服务起不来还能快速回退。备份目录确认没用后再手动清理不要在生产机上用rm -rf赌运气。移动完成后统一权限sudo chown -R root:root /usr/local/jdk1.8 sudo find /usr/local/jdk1.8 -type d -exec chmod 755 {} \; sudo find /usr/local/jdk1.8 -type f -exec chmod 644 {} \; sudo chmod 755 /usr/local/jdk1.8/bin/* /usr/local/jdk1.8/jre/bin/*目录给755普通文件给644bin和jre/bin下的可执行文件给755。不要图省事全目录777JDK 不需要写权限放开写权限只会让后面权限问题更难查。最后直接调用绝对路径验证一次/usr/local/jdk1.8/bin/java -version /usr/local/jdk1.8/bin/javac -version这一步不依赖环境变量能先确认二进制本身可执行。如果这里就报cannot execute binary file回到 2.1 查架构如果报缺库查系统基础库和 32/64 位匹配不要继续往下配 PATH。3.4 用 alternatives 挂载 java 与 javacdeb 系常见update-alternativesrpm 系常见alternatives命令名不同思路一样。下面以update-alternatives为例sudo update-alternatives --install /usr/bin/java java /usr/local/jdk1.8/bin/java 1800 sudo update-alternatives --install /usr/bin/javac javac /usr/local/jdk1.8/bin/javac 1800 sudo update-alternatives --config java最后的数字1800是优先级数字越大越容易在自动模式下被选中。--config java会列出候选项手动选一次能确认新路径已经注册。javac也要单独注册不然会出现java是 1.8、javac还是旧版本的情况。rpm 系机器把update-alternatives换成alternatives即可参数顺序基本一致。我一般让 PATH 指向$JAVA_HOME/binalternatives 只作为兜底。两条路同时开不是不行但排查时要先看type -a java到底命中了哪一条。如果 PATH 和 alternatives 指向不同目录版本号就会像变戏法一样一会儿对一会儿不对。4. 配置环境变量JAVA_HOME、PATH、CLASSPATH 三个参数的取舍JDK 装完不等于配好。JAVA_HOME决定应用和脚本去哪里找 JDKPATH决定你在终端里敲java时命中哪个二进制CLASSPATH则经常被过度配置。jdk1.8 时代很多老教程会让你把dt.jar、tools.jar全塞进全局 CLASSPATH这种做法放到现在很容易把应用自己的 classpath 搅乱除非旧应用明确要求否则不要全局写死。4.1 写一个独立的 /etc/profile.d/jdk1.8.sh我习惯用/etc/profile.d下的独立脚本不直接改/etc/profilesudo tee /etc/profile.d/jdk1.8.sh /dev/null EOF # jdk1.8 全局环境变量登录 shell 生效 export JAVA_HOME/usr/local/jdk1.8 export PATH$JAVA_HOME/bin:$PATH # 只有旧脚本读取 JRE_HOME 时再打开 # export JRE_HOME$JAVA_HOME/jre # CLASSPATH 默认不写死老应用需要时放到自己的启动脚本里 EOF sudo chmod 644 /etc/profile.d/jdk1.8.shtee用 sudo 写入系统目录EOF里的单引号让变量在写入时不被当前 shell 展开保证文件里保留$JAVA_HOME和$PATH的原样。PATH把$JAVA_HOME/bin放在最前面新的java、javac才会优先命中。JRE_HOME不是所有场景都要jdk1.8 自带jre目录老脚本明确读它时再加。CLASSPATH全局不写避免应用启动脚本自己的 classpath 被覆盖。权限给644就够了root 可写其他用户可读。不要给777环境变量文件被普通用户改掉后面所有登录 shell 都可能被带偏。4.2 让配置生效并确认优先级当前 shell 不会自动读取新文件手动 source 一次source /etc/profile.d/jdk1.8.sh hash -r echo $JAVA_HOME type -a java java -version javac -versionsource只影响当前 shell新开的登录 shell 会自动读/etc/profile.d。hash -r清掉 shell 对java路径的缓存避免明明 PATH 改了、命令还走旧路径。type -a java会按顺序列出所有命中项第一行才是你实际执行的。java -version和javac -version要一起看两个版本不一致就回到 3.4 检查 alternatives 和 PATH。如果echo $JAVA_HOME输出为空先确认当前 shell 是不是登录 shell再确认文件权限和文件名。/etc/profile.d下的脚本通常只被登录 shell 读取非登录 shell、cron、服务管理器不一定会加载它这也是后面服务启动找不到 Java 的常见原因。4.3 sudo、服务管理器与多用户场景的变量继承sudo java -version和直接java -version可能不是一回事。sudo 可能使用自己的secure_path不继承当前用户的 PATH。先验证登录 shell 下的结果sudo -i bash -lc echo $JAVA_HOME; java -version-i模拟登录环境-lc让 bash 读取登录脚本。这里能读到JAVA_HOME说明全局配置没问题读不到就检查/etc/profile.d/jdk1.8.sh是否被登录 shell 加载。服务管理器通常不读/etc/profile.d更稳的做法是在服务单元里显式写环境变量[Service] EnvironmentJAVA_HOME/usr/local/jdk1.8 EnvironmentPATH/usr/local/jdk1.8/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin ExecStart/usr/local/jdk1.8/bin/java -jar /opt/app/app.jarEnvironment把JAVA_HOME和PATH直接传给服务进程ExecStart再用绝对路径启动。这样即使系统环境变量被改服务也不会莫名其妙换 JDK。容器场景同理在构建文件或启动脚本里写JAVA_HOME不要指望容器自动继承宿主机 shell 的环境。4.4 CLASSPATH 什么时候才写全局 CLASSPATH 能不写就不写。老应用确实需要时放到应用自己的启动脚本里export APP_HOME/opt/app export CLASSPATH$APP_HOME/conf:$APP_HOME/lib/*conf放配置文件lib/*由 JVM 展开加载 jar。这里的*不要被 shell 提前展开所以放在双引号里更稳。不要把 JDK 的tools.jar、dt.jar塞进全局 CLASSPATHjdk1.8 的编译工具通常由javac自己处理全局塞进去只会让不同应用的依赖互相污染。判断标准很简单应用启动脚本里已经写了-cp或-classpath就以启动脚本为准只有旧脚本明确读CLASSPATH环境变量时才按上面的方式补。配置越少后面排查越容易。5. 常见问题排查jdk1.8 装完 java -version 不对的 5 个现场jdk1.8-64位Linux版.zip 解压成功不代表java -version一定对。下面这 5 个现场我在不同机器上都遇到过按“现象 → 原因 → 解决”记下来下次遇到先对照不要上来就重装。5.1 现象java: command not found现象/usr/local/jdk1.8/bin/java -version能跑但直接敲java -version提示找不到命令。原因$JAVA_HOME/bin没有进 PATH或者当前 shell 没加载/etc/profile.d/jdk1.8.sh。非登录 shell、cron、部分服务启动脚本不会自动读 profile 文件。解决先看文件和当前 PATHls -l /etc/profile.d/jdk1.8.sh source /etc/profile.d/jdk1.8.sh echo $PATH type -a java如果 source 后能跑说明配置内容没问题问题在加载时机。cron 或服务脚本里直接写绝对路径或者在脚本开头显式source /etc/profile.d/jdk1.8.sh。不要依赖“登录时一定会读”的假设。5.2 现象java -version 还是旧版本现象JAVA_HOME已经指向/usr/local/jdk1.8java -version仍显示旧版本。原因PATH 里旧路径排在前面或者 shell 缓存了旧命令位置也可能是 alternatives 把/usr/bin/java指回了旧 JDK。解决按顺序查type -a java readlink -f $(command -v java) hash -r update-alternatives --list java 2/dev/null || truetype -a第一行是实际命中的路径readlink -f看软链最终指向hash -r清缓存最后一条看 alternatives 候选。让$JAVA_HOME/bin排在 PATH 前面或者把 alternatives 优先级调高二选一不要两边都改一半。5.3 现象javac 与 java 版本不一致现象java -version是 1.8javac -version还是旧版本编译出来的 class 运行时报版本不匹配。原因只给java做了软链或 alternativesjavac还指向旧目录。PATH 里也可能出现java走新目录、javac走/usr/bin的情况。解决分别追两个命令的真实路径readlink -f $(command -v java) readlink -f $(command -v javac)两个路径的父目录应该都落到/usr/local/jdk1.8。不一致就补javac的 alternatives或者确认$JAVA_HOME/bin在 PATH 最前面。编译和运行用同一套 JDK是最省事的做法。5.4 现象JAVA_HOME 指错一层应用找不到 lib/tools.jar现象java能跑但应用启动时报找不到tools.jar、lib下某个文件或者JAVA_HOME/bin/java不存在。原因压缩包解压后多了一层版本目录JAVA_HOME指到了外层。比如真实路径是/usr/local/jdk1.8/jdk1.8.0_xxx/bin/java配置却写成/usr/local/jdk1.8。解决用find确认bin/java的真实位置find /usr/local/jdk1.8 -maxdepth 3 -type f -path */bin/java ls -l /usr/local/jdk1.8/bin/javaJAVA_HOME应该指向bin的上一级。如果多了一层要么把内层内容移上来要么把JAVA_HOME改成内层真实路径。改完重新 source再跑java -version和javac -version。5.5 现象服务启动报 Could not reserve enough space for object heap现象命令行跑java -version正常服务一启动就报Could not reserve enough space for object heap或者堆内存初始化失败。原因常见有三种实际跑的是 32 位 Java容器或 cgroup 限制了内存但-Xmx写得比限制还大老版本 JDK8 对容器内存限制识别不完整默认堆按宿主机内存算。解决先看 VM 设置和系统内存java -XshowSettings:vm -version 21 | grep -E Max. Heap Size|VM settings free -m cat /sys/fs/cgroup/memory/memory.limit_in_bytes 2/dev/null || true如果输出里出现 32 位字样回到 2.1 确认包和系统位数。内存受限的环境里显式写小堆参数例如-Xms256m -Xmx512m不要只写-Xmx不写-Xms。容器里还要确认 cgroup 限制JDK8 老版本识别不到容器上限时显式参数比默认值可靠。6. 装完验证用 HelloJdk8 跑通 jdk1.8 的编译与运行链路别只看java -version。版本号对得上不代表javac和运行链路都对。我会在/tmp下写一个最小程序把编译、运行、java.home一次跑完mkdir -p /tmp/jdk8-check cd /tmp/jdk8-check cat HelloJdk8.java EOF public class HelloJdk8 { public static void main(String[] args) { System.out.println(java.version System.getProperty(java.version)); System.out.println(java.home System.getProperty(java.home)); System.out.println(os.arch System.getProperty(os.arch)); p a hrefhttps://download.csdn.net/download/u013214151/11235717 stylecolor:#ec7500;font-size:14px; 本文还有配套的精品资源点击获取 /a img altmenu-r.4af5f7ec.gif srchttps://csdnimg.cn/release/wenkucmsfe/public/img/menu-r.4af5f7ec.gif stylewidth:16px;margin-left:4px;vertical-align:text-bottom;cursor:text; /p
阅读完成 · 觉得有帮助？
