这些年陆陆续续帮同事装过不少次 JDK 1.8尤其是刚换 Mac 的同事几乎都要在安装这一步卡一下。macOS 上的 JDK 安装其实不复杂但坑也不少intel 芯片和 Apple Silicon 下载哪个包、环境变量写进哪个文件、装完 java -version 还是提示 command not found、机器上已经有好几个 JDK 不知道切到哪个……这些问题我基本每次都遇到一遍。这篇就专门聊聊 macOS 下 JDK 1.8 的完整安装流程以及我自己踩过的坑和最终稳定使用的方案。可能有人会问现在 JDK 都出到 21、25 了为什么还要回头装 1.8其实不少中小团队的老项目还在 Java 8 上跑部分中间件、大数据组件、Gradle 旧版本也只对 Java 8 支持最好。对这些人来说“JDK 1.8 是当前主流版本”依然是现实。这篇内容主要适合三类人刚换 Mac 需要配 Java 开发环境的新人、要在本机维护多个 JDK 版本的开发者、以及帮同事“救火”时需要一套稳妥方案的运维或老手。1. 为什么现在 macOS 上还要装 JDK 1.81.1 存量项目的“主力版本”标签很多人一听到 JDK 1.8第一反应是“老古董”。但放到真实业务环境里它仍然是存量项目的绝对主力。以我接触过的不少中小公司为例核心业务系统从 2015 年到现在一路迭代pom.xml 里写的 source/target 还是 1.8中间件用的 Zookeeper、Kafka、Hadoop 生态也对 Java 8 有最成熟的兼容性支撑。换 JDK 不是改个版本号那么简单涉及依赖兼容、JVM 参数调优经验、线上故障排查工具链迁移成本并不低。另外很多开发者在 Mac 上写代码不等于生产环境也跑在 Mac 上。公司服务器普遍是 CentOS 7 或更老的系统预装的 OpenJDK 8 一大堆。如果本地不装一个同版本 JDK就会出现“本地好好的一上测试环境就报错”的诡异问题。所以在 macOS 上装 JDK 1.8本质上是为了保证开发环境与生产环境的版本一致性。1.2 “主流”这个词在不同场景下的判断标题里说“目前主流版本的 jdk”这个判断要看语境。如果看 Oracle 官方技术支持时间线Java 8 的免费商业更新早就停了但社区里最常用的 OpenJDK 8 发行版、Adoptium/Temurin 8 等仍在持续维护很多公共云镜像、基础镜像默认还是 Java 8。比如不少 CI/CD 流水线用的 maven:3.8-jdk-8 镜像说明 Java 8 在自动化构建链路里依然有很强的存在感。再从学习生态看大量老牌教程、书籍、培训机构课程仍以 Java 8 语法和 API 为基础。对刚入行的人来说装一个 JDK 1.8 学习 Spring Boot 2.x、MyBatis、JSP 等传统技术栈反而是最匹配的资源。装新 JDK 不是不行而是很多案例、参数配置、第三方库文档都默认用 Java 8 演示版本不对容易学得一头雾水。1.3 在 Mac 上装 JDK 1.8 要面临的三个现实差异macOS 和其他系统有个明显区别它不像 Windows 那样有个“下一步下一步”的安装向导也不像 Linux 那样解压 tar.gz 就能全局用。macOS 更习惯用 .dmg 安装包把 JDK 装到 /Library/Java/JavaVirtualMachines 目录再用 /usr/libexec/java_home 这个系统命令统一管理路径。理解这个机制后面配置环境变量会顺手很多。其次从 macOS Catalina 开始默认 shell 是 zsh环境变量文件从 .bash_profile 换成了 .zshrc。如果你在网上搜到老文章让你去改 ~/.bash_profile那大概率配置完仍不生效。这不是操作失误而是系统层面默认 shell 变了。再者Apple Silicon 的 Mac 要特别注意架构问题。JDK 1.8 官方原版只有 x64 版本在 M1/M2/M3 芯片上需要 Rosetta 2 转译运行而部分 OpenJDK 发行版比如 Azul Zulu提供了原生 arm64 的 Java 8。到底选哪种后面我会给出我的建议。2. 安装前确认三件事芯片、现有 JDK 和下载渠道2.1 先确认你的 Mac 是哪一颗芯片这一步很多人会跳过但实际上下错安装包占安装失败原因的一半以上。点左上角苹果图标选“关于本机”看“芯片”一栏。显示“Apple M1/M2/M3”就是 arm64 架构显示“Intel Core i5/i7”就是 x86_64 架构。也可以在终端执行 uname -m输出 arm64 对应 Apple Silicon输出 x86_64 对应 Intel。为什么要先确认这个因为 JDK 1.8 不像新版 JDK 那样分得那么细同一家发行版往往同时提供 x64 和 arm64 两个 macOS 包。选错了轻则系统提示“已损坏无法打开”重则装上了但 JVM 以 Rosetta 转译模式运行部分原生库加载异常。特别是做大数据、JNI 本地调用的项目架构不匹配的坑会非常难排查。2.2 检查机器上已有的 JDK 版本避免装重了很多人的 Mac 不是第一次装 Java。可能之前为了某个工具自动装了 JDK 17也可能自带了一个 OpenJDK。建议安装前先执行这段命令/usr/libexec/java_home -V如果有输出可以看到系统识别到的所有 JDK 及对应路径。如果提示 Unable to find any JVMs matching说明当前没有任何可用的 JDK直接装就行。这一步能帮你提前知道机器上是否已有 JDK、JAVA_HOME 是否配置过、之后安装的 1.8 会不会和旧版本冲突。顺便提一句macOS 不像 Linux 那样有 update-alternatives 这种系统级切换命令。它更推荐的方式是每个 JDK 独立安装包放在统一目录然后用 java_home 按版本号去找路径。理解这一点你就能明白为什么后面配置 JAVA_HOME 时要用 $(/usr/libexec/java_home -v 1.8) 这种写法而不是硬编码一个固定路径。2.3 下载渠道怎么选Oracle JDK、Adoptium 还是 Azul Zulu先说 Oracle JDK 1.8。它是最“正统”的版本很多老项目的坑都是按这个版本踩平填好的但有两个问题一是从改版后下载需要登录 Oracle 账号二是它的 macOS 版本只有 x64Apple Silicon 用户装完只能用 Rosetta 跑而且 Oracle 对 Java 8 的免费更新已经停止很久。如果不是公司有硬性规定要求必须用 Oracle JDK我个人不太推荐把它作为新环境的第一选择。更推荐的是 Adoptium也就是以前的 AdoptOpenJDK的 Temurin 8或者 Azul Zulu 8。这两个都是社区活跃、长期维护的 OpenJDK 发行版完全兼容 JDK 1.8 的 API而且都有专门的 macOS arm64 版本Apple Silicon 用户可以直接原生运行不用装 Rosetta。Azul Zulu 的下载页会明确给出“macOS 11 (Apple Silicon) - Java 8”的选项Adoptium 的 Archive 页面也能找到对应产物。它们和 Oracle JDK 在命令行工具、class 文件格式、Java 语言特性上是完全一致的日常开发几乎没有感知差异。如果你是新手不知道怎么选我建议直接下 Azul Zulu 8 for macOS (arm64/x64)因为它对 macOS 的适配做得比较细致安装包提供 .dmg 格式装完还能自动帮你把 java 命令链接到系统目录比手动解压 tar.gz 省事很多。3. 完整安装步骤从下载到环境变量一次搞定3.1 下载阶段的具体操作以 Adoptium Temurin 8 为例打开官网后进到 “Download” 页在 Version 里选 Java 8Operating System 选 macOSArchitecture 根据前面确认的信息选 x64 或 aarch64Package Type 推荐选 .dmg。点下载后会得到一个类似 OpenJDK8U-jdk_x64_mac_hotspot_8uXXX.dmg 的文件。Oracle JDK 的下载路径稍微曲折一点。它需要你先接受许可协议再登录账号然后到 “macOS x64” 分类下找 jdk-8uXXX-macosx-x64.dmg。这里有个小技巧Oracle 下载页面里文件名带 dmg 的才是图形化安装包带 tar.gz 的是纯命令行版本。如果你不想折腾登录账号跳过 Oracle 完全没问题。下载时注意版本号里的 Update 数字比如 8u202、8u333、8u402。理论上更新版本会包含更多安全修复但部分老项目对过新的更新版本有兼容性问题尤其是 8u202 之后 Oracle 调整了部分授权和部署策略。如果你所在项目没有特殊要求选最新 8u 版本即可如果项目文档里明确写了“只能在 8u201/8u202 上运行”那就严格按项目要求来。3.2 dmg 安装包执行流程拿到 .dmg 后双击挂载会看到类似 “Java 8 Update 402.pkg” 的安装器图标。双击 pkg系统可能弹出“来自互联网的下载”提示点击继续即可。之后一路“继续 → 安装”输入 Mac 的开机密码授权等待进度条走完安装就完成了。这里有一个 macOS 特有的细节安装完成后JDK 会被放到 /Library/Java/JavaVirtualMachines 目录下而不是像 Windows 那样装到 Program Files。你可以用下面命令验证ls /Library/Java/JavaVirtualMachines/正常会看到一个类似 jdk-8u402.jdk 或 zulu-8.jdk 的文件夹。这个目录就是 macOS 统一管理 JDK 的地方后续所有 JDK 都会以 .jdk 文件夹的形式出现在这里。安装完 dmg 之后你可能以为自己就能直接用了。但实际情况是打开终端执行 java -version 大概率还是报错。这完全正常因为 macOS 不会自动把 JAVA_HOME 和 PATH 配好需要手动设置环境变量。3.3 配置 JAVA_HOME 与 PATHzsh 环境实测写法macOS 新版默认 shell 是 zsh所以环境变量要写到 ~/.zshrc 里。执行vi ~/.zshrc把下面这段加到文件末尾如果之前有旧的 JAVA_HOME 配置建议先注释掉再添加新行export JAVA_HOME$(/usr/libexec/java_home -v 1.8) export PATH$JAVA_HOME/bin:$PATH第一行的意思是让系统自动找当前 Mac 上所有 Java 8 版本对应的 Home 目录。这种写法比我直接写死 /Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home 更灵活以后如果你装了别的 Java 8 小版本不用改配置它自动指向最新可用路径。保存退出后执行source ~/.zshrc然后验证java -version如果输出里有 java version 1.8.0_xxx”说明安装和配置都成功了。再验证一下编译工具javac -version这里要提醒一个新手常犯的错误很多教程会叫你执行 echo $JAVA_HOME 来验证如果输出为空不代表配置失败。可能是因为你写到了 .bash_profile 而当前 shell 是 zsh也可能是因为 source 的目标文件写错了。最直接的验证方式是 java -version只要它能正常输出版本号JAVA_HOME 就算生效了。3.4 不推荐手动解压 tar.gz除非你有特殊需求网上很多教程喜欢让人下载 tar.gz 然后解压到 /Library/Java/JavaVirtualMachines再手动修改目录名。这种做法不是不行但对新手来说容易踩两个坑一是目录名如果没按 .jdk 结尾/usr/libexec/java_home 可能识别不到二是没有 pkg 安装器帮你处理文件权限某些 JDK 内部脚本执行时可能会遇到 Permission denied。我的建议是能用 dmg/pkg 就用 dmg/pkg省心且规范。tar.gz 主要留给这种情况你的项目需要特定版本特定目录名比如需要同时保留两个 8u 小版本并手动切换或者你想把 JDK 放到自定义目录比如 ~/dev/jdk而不是系统目录。如果是后者那环境变量里就别用 /usr/libexec/java_home 了直接写 export JAVA_HOME你的自定义路径。4. 多版本 JDK 共存与切换真实开发中的高频需求4.1 一台 Mac 装了多个 JDK怎么互不干扰日常开发中常常要面对这个场景老项目要 JDK 8新项目要 JDK 17或者某个 IDE 插件强制要求 JDK 11。如果你已经在 Mac 上装了多个 JDK比如先装了 JDK 17现在再装 JDK 8那么前面第 2 节里的检查就派上用场了。安装完成后执行/usr/libexec/java_home -V可以看到所有已安装的 JDK 版本和路径。当前命令行的 java 用的是哪个版本取决于 PATH 里哪个 JDK 的 bin 目录排在最前面。而在我们的配置中~/.zshrc 里 export PATH$JAVA_HOME/bin:$PATH 会把 JAVA_HOME 对应的版本放在最前面所以 JAVA_HOME 指向谁java 命令用的就是谁。4.2 我的多版本切换方案alias 配合 java_home既然不同项目需要不同版本手工改 .zshrc 太痛苦。我自己的做法是在 ~/.zshrc 里配置几个 aliasalias jdk8export JAVA_HOME$(/usr/libexec/java_home -v 1.8); export PATH$JAVA_HOME/bin:$PATH; java -version alias jdk17export JAVA_HOME$(/usr/libexec/java_home -v 17); export PATH$JAVA_HOME/bin:$PATH; java -version这样哪天切版本就在终端执行 jdk8 或者 jdk17当前终端窗口立即生效不用退出重开。这个方案的好处是不用安装额外的版本管理工具逻辑直观团队同事接手时也容易理解。缺点是每个新开的终端窗口都会回到默认 JAVA_HOME需要手动再执行一次 alias。如果你对这个“记忆”有要求可以写成更复杂的 zsh 函数每次进入目录自动检测项目需要的 JDK 版本但那就是另一个话题了。如果你需要更多自动化管理macOS 远没有 Linux 的 sdkman 生态强大但 sdkman 也是可以用的。安装 sdkman 后可以执行 sdk install java 8.0.402-tem然后用 sdk use java 8.0.402-tem 随意切换当前 shell 的 JDK。sdkman 适合喜欢命令行管理的用户但它会把 JDK 安装在 ~/.sdkman/candidates/java 而不是系统目录和某些 IDE 的自动检测机制可能不一致。两套方案各有利弊我更推荐先用手动 alias 方案理解原理之后再决定要不要引入工具。4.3 IDE 里 JDK 路径怎么填Mac 用户必看配置好终端后还会遇到一个新手经常问的问题IDEA 或 Eclipse 里要求填 JDK home path到底填哪个答案是 .jdk 文件夹里的 Contents/Home。比如/Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home如果你不想手动记在终端执行/usr/libexec/java_home -v 1.8输出结果就是你要填的路径。注意不要填到 /Library/Java/JavaVirtualMachines 就结束了那只是 JDK 的安装根目录真正的 bin/java 在这层目录的 Contents/Home/bin 下。IDEA 新版本一般也能自动识别但识别失败的场景并不少见手动指定反而最稳。5. 常见报错与排查技巧都是实际会踩的坑5.1 输入 java -version 提示 command not found这是最常见的错误。原因通常有两个一是环境变量没配置终端根本找不到 java 命令二是配置写错了文件比如写到了 ~/.bash_profile 但当前用的是 zsh。排查思路按顺序来先执行 ls /Library/Java/JavaVirtualMachines/确认 JDK 是否真的装了。如果目录为空说明安装没成功重装 dmg。如果目录有 .jdk 文件夹再执行 echo $SHELL 看当前 shell 是什么。如果是 /bin/zsh环境变量就要写在 ~/.zshrc如果是 /bin/bash才写在 ~/.bash_profile。最后检查 ~/.zshrc 文件的语法是否有明显的引号错误很多时候是复制别人的配置时少了反引号。5.2 配置完 JAVA_HOME 后 java 版本还是旧的这个我遇到过好几次。原因多半是机器上本来就装了 JDK 17而且某个工具比如 Homebrew把它的 bin 目录也加到了 PATH 里位置可能在你的配置之前。你可以执行which -a java看看系统找到了几个 java。输出会按 PATH 顺序列出第一个就是当前实际使用的。如果你发现 /usr/bin/java 排在最前面那说明你配置的 PATH 没有覆盖系统默认路径。macOS 系统自带一个 /usr/bin/java 的 stub它本身不算 JDK但会干扰环境变量优先级。解决办法确保 JAVA_HOME 配置在 .zshrc 里并且在 export PATH... 这一行里把 $JAVA_HOME/bin 放在最前面。我习惯写成export PATH$JAVA_HOME/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin而不是简单地在末尾追加。这样只要 JAVA_HOME 正确java 一定优先用 JDK 8。5.3 双击 pkg 安装时提示“无法打开”或“已损坏”这个问题本质上和 JDK 无关而是 macOS Gatekeeper 对未签名 pkg 或下载文件的隔离属性判断。很多开发者第一次遇到都会慌以为安装包有问题。最简单的处理方式右键点击 pkg 文件选择“打开”在弹出窗口里再点一次“打开”往往就能绕过首次弹窗。如果仍然提示已损坏大概率是你的下载过程触发系统隔离标记。可以在终端执行sudo xattr -dr com.apple.quarantine ~/Downloads/你的安装包.pkg这行命令的意思是清除下载文件的隔离属性让系统认为它是本地文件然后重新双击安装。需要注意这一步仅用于官方渠道正常下载的安装包如果你从非官方渠道下载了修改过的安装包这个操作会有安全风险。这也是为什么我一直强调下载渠道要选官方或正规发行版的原因。5.4 Apple Silicon 上装完 JDK 8 后运行异常如果你用的是 M1/M2/M3 芯片且安装了 Oracle JDK 8 的 x64 版本某一些使用 JNI 本地库的项目可能会报这样或那样的底层错误比如找不到 native library 或 UnsatisfiedLinkError。这是因为 x64 版本在 ARM 上通过 Rosetta 转译运行对于纯 Java 应用关系不大但涉及本地方法调用时会有兼容性问题。解决方案有两个一是换用 arm64 原生版本比如 Azul Zulu 8 for macOS (Apple Silicon) 或 Temurin 8 的 aarch64 版本二是给 Terminal 开启“使用 Rosetta 打开”选项让整个终端环境在转译模式下运行。前者更干净因为应用本身以原生架构运行性能更好后者适合你无法更换 JDK 发行版、只能使用特定 Oracle 版本的情况。我自己实测下来Zulu 的 arm64 JDK 8 在 M1 Mac 上运行老项目的 Spring Boot 应用表现稳定和 Intel Mac 上的 Oracle JDK 8 区别感知不明显。所以如果你碰到架构问题不用犹豫直接换发行版。5.5 环境变量配置后终端重启就失效如果你发现当前终端窗口配置好了一关掉重开又不行了那么十有八九是只改了当前 shell 的环境变量而没写入配置文件。有同学会直接在终端执行 export JAVA_HOMExxx看起来有效但那个变量只在当前进程存在新开窗口自然就没了。正确做法是把 export 语句写入 ~/.zshrc保存后执行 source ~/.zshrc。另外注意如果你同时存在 ~/.zshrc 和 ~/.zprofile有些情况下 .zprofile 会在 .zshrc 之前执行如果里面设置了旧的 JAVA_HOME可能会覆盖掉 .zshrc 的值。检查方法很简单打开 .zprofile 看看有没有相关配置有就一起改。6. 安装后的验证清单与个人推荐配置6.1 一个新装好的 JDK 8至少做这 5 项验证安装配置完后不要只看一个 java -version 就说完成。我一般会按这个顺序验证第一java -version 确认当前默认版本确实是 1.8。第二javac -version 确认编译器可用因为有些发行版把 JDK 拆分了只装 JRE 会导致 javac 缺失。第三echo $JAVA_HOME 确认路径存在最好再用 ls 看一下该路径下有没有 bin/java。第四写一个最简单的 Hello.java 编译运行确认 JVM 能真正启动类文件而不是只在命令行工具层面正常。第五在 IDEA 里建一个空 Java 项目把 Project SDK 指到刚装的 JDK运行 main 方法确认 IDE 里的编译运行链路通畅。这五步看着繁琐但能覆盖从命令行到 IDE 的完整开发链路。很多“装好了但项目跑不起来”的后续问题都是因为在某一步偷懒没验证导致问题留到了之后更难排查。6.2 我目前在实际环境中使用的组合前面讲了很多方案最后分享一下我自己比较顺手的组合生产环境老项目用 Azul Zulu 8 for macOS因为它在 Apple Silicon 上有原生支持而且带 JavaFX 相关组件历史项目里偶尔会用到本地新项目用 Homebrew 安装的 openjdk17两个版本通过 alias 切换。日常开发时默认 JAVA_HOME 指向 1.8因为我的大部分工作还是在老项目上。下载安装这块我优先走 .dmg 安装包版本号宁可多花一分钟确认也不要装完再卸。之前踩过一个坑装了某个发行版的 8u202 版本后老项目里用了内部 API结果编译直接报错后来仔细查才发现是更新版本移除了部分包。这类问题从日志上看非常像代码 bug实际原因却让人意想不到所以版本选择上一定要谨慎。另外我会把 .zshrc 中 JDK 相关配置统一放到文件末尾并加上注释分隔线比如# JDK 8 (default) export JAVA_HOME$(/usr/libexec/java_home -v 1.8) export PATH$JAVA_HOME/bin:$PATH # JDK 17 (switch manually) alias jdk17export JAVA_HOME$(/usr/libexec/java_home -v 17); export PATH$JAVA_HOME/bin:$PATH; java -version这样半年后回来改配置一眼就能看明白这些命令是干什么的。开发环境这种事最怕的从来不是不会配而是配完之后自己都忘了当初怎么配的。6.3 关于“安装成功”这件事我的判断标准很多人在 Mac 上装完 JDK看到 java -version 输出版本号就放心了。但我的判断标准是命令行能用、IDE 能用、项目能编译运行三者全部通过才算真正完成。因为实际开发中你大概率不会只用终端敲命令IDEA、Maven、Gradle、Docker 里的 Java 进程都会依赖系统 JDK。如果只验证了前两项后面遇到构建工具找不到 JDK、容器内 java -version 版本不对等问题照样让人抓狂。最后再提一个扩展思路如果你需要经常在多台 Mac 间切换环境可以考虑把 JDK 安装包和 .zshrc 配置沉淀成一份自己的初始化脚本用 Homebrew 批量安装常用工具再配合一份固定不变的配置模板。这样换新机器时执行一次脚本就能把 JDK 8、Git、Maven、IDEA 等环境全部初始化好省掉很多重复劳动。我在实际经历中已经这么维护了两三台开发机效果还挺稳定推荐你也试试。
macOS 安装 JDK 1.8 完整指南：环境配置、版本切换与常见坑
这些年陆陆续续帮同事装过不少次 JDK 1.8尤其是刚换 Mac 的同事几乎都要在安装这一步卡一下。macOS 上的 JDK 安装其实不复杂但坑也不少intel 芯片和 Apple Silicon 下载哪个包、环境变量写进哪个文件、装完 java -version 还是提示 command not found、机器上已经有好几个 JDK 不知道切到哪个……这些问题我基本每次都遇到一遍。这篇就专门聊聊 macOS 下 JDK 1.8 的完整安装流程以及我自己踩过的坑和最终稳定使用的方案。可能有人会问现在 JDK 都出到 21、25 了为什么还要回头装 1.8其实不少中小团队的老项目还在 Java 8 上跑部分中间件、大数据组件、Gradle 旧版本也只对 Java 8 支持最好。对这些人来说“JDK 1.8 是当前主流版本”依然是现实。这篇内容主要适合三类人刚换 Mac 需要配 Java 开发环境的新人、要在本机维护多个 JDK 版本的开发者、以及帮同事“救火”时需要一套稳妥方案的运维或老手。1. 为什么现在 macOS 上还要装 JDK 1.81.1 存量项目的“主力版本”标签很多人一听到 JDK 1.8第一反应是“老古董”。但放到真实业务环境里它仍然是存量项目的绝对主力。以我接触过的不少中小公司为例核心业务系统从 2015 年到现在一路迭代pom.xml 里写的 source/target 还是 1.8中间件用的 Zookeeper、Kafka、Hadoop 生态也对 Java 8 有最成熟的兼容性支撑。换 JDK 不是改个版本号那么简单涉及依赖兼容、JVM 参数调优经验、线上故障排查工具链迁移成本并不低。另外很多开发者在 Mac 上写代码不等于生产环境也跑在 Mac 上。公司服务器普遍是 CentOS 7 或更老的系统预装的 OpenJDK 8 一大堆。如果本地不装一个同版本 JDK就会出现“本地好好的一上测试环境就报错”的诡异问题。所以在 macOS 上装 JDK 1.8本质上是为了保证开发环境与生产环境的版本一致性。1.2 “主流”这个词在不同场景下的判断标题里说“目前主流版本的 jdk”这个判断要看语境。如果看 Oracle 官方技术支持时间线Java 8 的免费商业更新早就停了但社区里最常用的 OpenJDK 8 发行版、Adoptium/Temurin 8 等仍在持续维护很多公共云镜像、基础镜像默认还是 Java 8。比如不少 CI/CD 流水线用的 maven:3.8-jdk-8 镜像说明 Java 8 在自动化构建链路里依然有很强的存在感。再从学习生态看大量老牌教程、书籍、培训机构课程仍以 Java 8 语法和 API 为基础。对刚入行的人来说装一个 JDK 1.8 学习 Spring Boot 2.x、MyBatis、JSP 等传统技术栈反而是最匹配的资源。装新 JDK 不是不行而是很多案例、参数配置、第三方库文档都默认用 Java 8 演示版本不对容易学得一头雾水。1.3 在 Mac 上装 JDK 1.8 要面临的三个现实差异macOS 和其他系统有个明显区别它不像 Windows 那样有个“下一步下一步”的安装向导也不像 Linux 那样解压 tar.gz 就能全局用。macOS 更习惯用 .dmg 安装包把 JDK 装到 /Library/Java/JavaVirtualMachines 目录再用 /usr/libexec/java_home 这个系统命令统一管理路径。理解这个机制后面配置环境变量会顺手很多。其次从 macOS Catalina 开始默认 shell 是 zsh环境变量文件从 .bash_profile 换成了 .zshrc。如果你在网上搜到老文章让你去改 ~/.bash_profile那大概率配置完仍不生效。这不是操作失误而是系统层面默认 shell 变了。再者Apple Silicon 的 Mac 要特别注意架构问题。JDK 1.8 官方原版只有 x64 版本在 M1/M2/M3 芯片上需要 Rosetta 2 转译运行而部分 OpenJDK 发行版比如 Azul Zulu提供了原生 arm64 的 Java 8。到底选哪种后面我会给出我的建议。2. 安装前确认三件事芯片、现有 JDK 和下载渠道2.1 先确认你的 Mac 是哪一颗芯片这一步很多人会跳过但实际上下错安装包占安装失败原因的一半以上。点左上角苹果图标选“关于本机”看“芯片”一栏。显示“Apple M1/M2/M3”就是 arm64 架构显示“Intel Core i5/i7”就是 x86_64 架构。也可以在终端执行 uname -m输出 arm64 对应 Apple Silicon输出 x86_64 对应 Intel。为什么要先确认这个因为 JDK 1.8 不像新版 JDK 那样分得那么细同一家发行版往往同时提供 x64 和 arm64 两个 macOS 包。选错了轻则系统提示“已损坏无法打开”重则装上了但 JVM 以 Rosetta 转译模式运行部分原生库加载异常。特别是做大数据、JNI 本地调用的项目架构不匹配的坑会非常难排查。2.2 检查机器上已有的 JDK 版本避免装重了很多人的 Mac 不是第一次装 Java。可能之前为了某个工具自动装了 JDK 17也可能自带了一个 OpenJDK。建议安装前先执行这段命令/usr/libexec/java_home -V如果有输出可以看到系统识别到的所有 JDK 及对应路径。如果提示 Unable to find any JVMs matching说明当前没有任何可用的 JDK直接装就行。这一步能帮你提前知道机器上是否已有 JDK、JAVA_HOME 是否配置过、之后安装的 1.8 会不会和旧版本冲突。顺便提一句macOS 不像 Linux 那样有 update-alternatives 这种系统级切换命令。它更推荐的方式是每个 JDK 独立安装包放在统一目录然后用 java_home 按版本号去找路径。理解这一点你就能明白为什么后面配置 JAVA_HOME 时要用 $(/usr/libexec/java_home -v 1.8) 这种写法而不是硬编码一个固定路径。2.3 下载渠道怎么选Oracle JDK、Adoptium 还是 Azul Zulu先说 Oracle JDK 1.8。它是最“正统”的版本很多老项目的坑都是按这个版本踩平填好的但有两个问题一是从改版后下载需要登录 Oracle 账号二是它的 macOS 版本只有 x64Apple Silicon 用户装完只能用 Rosetta 跑而且 Oracle 对 Java 8 的免费更新已经停止很久。如果不是公司有硬性规定要求必须用 Oracle JDK我个人不太推荐把它作为新环境的第一选择。更推荐的是 Adoptium也就是以前的 AdoptOpenJDK的 Temurin 8或者 Azul Zulu 8。这两个都是社区活跃、长期维护的 OpenJDK 发行版完全兼容 JDK 1.8 的 API而且都有专门的 macOS arm64 版本Apple Silicon 用户可以直接原生运行不用装 Rosetta。Azul Zulu 的下载页会明确给出“macOS 11 (Apple Silicon) - Java 8”的选项Adoptium 的 Archive 页面也能找到对应产物。它们和 Oracle JDK 在命令行工具、class 文件格式、Java 语言特性上是完全一致的日常开发几乎没有感知差异。如果你是新手不知道怎么选我建议直接下 Azul Zulu 8 for macOS (arm64/x64)因为它对 macOS 的适配做得比较细致安装包提供 .dmg 格式装完还能自动帮你把 java 命令链接到系统目录比手动解压 tar.gz 省事很多。3. 完整安装步骤从下载到环境变量一次搞定3.1 下载阶段的具体操作以 Adoptium Temurin 8 为例打开官网后进到 “Download” 页在 Version 里选 Java 8Operating System 选 macOSArchitecture 根据前面确认的信息选 x64 或 aarch64Package Type 推荐选 .dmg。点下载后会得到一个类似 OpenJDK8U-jdk_x64_mac_hotspot_8uXXX.dmg 的文件。Oracle JDK 的下载路径稍微曲折一点。它需要你先接受许可协议再登录账号然后到 “macOS x64” 分类下找 jdk-8uXXX-macosx-x64.dmg。这里有个小技巧Oracle 下载页面里文件名带 dmg 的才是图形化安装包带 tar.gz 的是纯命令行版本。如果你不想折腾登录账号跳过 Oracle 完全没问题。下载时注意版本号里的 Update 数字比如 8u202、8u333、8u402。理论上更新版本会包含更多安全修复但部分老项目对过新的更新版本有兼容性问题尤其是 8u202 之后 Oracle 调整了部分授权和部署策略。如果你所在项目没有特殊要求选最新 8u 版本即可如果项目文档里明确写了“只能在 8u201/8u202 上运行”那就严格按项目要求来。3.2 dmg 安装包执行流程拿到 .dmg 后双击挂载会看到类似 “Java 8 Update 402.pkg” 的安装器图标。双击 pkg系统可能弹出“来自互联网的下载”提示点击继续即可。之后一路“继续 → 安装”输入 Mac 的开机密码授权等待进度条走完安装就完成了。这里有一个 macOS 特有的细节安装完成后JDK 会被放到 /Library/Java/JavaVirtualMachines 目录下而不是像 Windows 那样装到 Program Files。你可以用下面命令验证ls /Library/Java/JavaVirtualMachines/正常会看到一个类似 jdk-8u402.jdk 或 zulu-8.jdk 的文件夹。这个目录就是 macOS 统一管理 JDK 的地方后续所有 JDK 都会以 .jdk 文件夹的形式出现在这里。安装完 dmg 之后你可能以为自己就能直接用了。但实际情况是打开终端执行 java -version 大概率还是报错。这完全正常因为 macOS 不会自动把 JAVA_HOME 和 PATH 配好需要手动设置环境变量。3.3 配置 JAVA_HOME 与 PATHzsh 环境实测写法macOS 新版默认 shell 是 zsh所以环境变量要写到 ~/.zshrc 里。执行vi ~/.zshrc把下面这段加到文件末尾如果之前有旧的 JAVA_HOME 配置建议先注释掉再添加新行export JAVA_HOME$(/usr/libexec/java_home -v 1.8) export PATH$JAVA_HOME/bin:$PATH第一行的意思是让系统自动找当前 Mac 上所有 Java 8 版本对应的 Home 目录。这种写法比我直接写死 /Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home 更灵活以后如果你装了别的 Java 8 小版本不用改配置它自动指向最新可用路径。保存退出后执行source ~/.zshrc然后验证java -version如果输出里有 java version 1.8.0_xxx”说明安装和配置都成功了。再验证一下编译工具javac -version这里要提醒一个新手常犯的错误很多教程会叫你执行 echo $JAVA_HOME 来验证如果输出为空不代表配置失败。可能是因为你写到了 .bash_profile 而当前 shell 是 zsh也可能是因为 source 的目标文件写错了。最直接的验证方式是 java -version只要它能正常输出版本号JAVA_HOME 就算生效了。3.4 不推荐手动解压 tar.gz除非你有特殊需求网上很多教程喜欢让人下载 tar.gz 然后解压到 /Library/Java/JavaVirtualMachines再手动修改目录名。这种做法不是不行但对新手来说容易踩两个坑一是目录名如果没按 .jdk 结尾/usr/libexec/java_home 可能识别不到二是没有 pkg 安装器帮你处理文件权限某些 JDK 内部脚本执行时可能会遇到 Permission denied。我的建议是能用 dmg/pkg 就用 dmg/pkg省心且规范。tar.gz 主要留给这种情况你的项目需要特定版本特定目录名比如需要同时保留两个 8u 小版本并手动切换或者你想把 JDK 放到自定义目录比如 ~/dev/jdk而不是系统目录。如果是后者那环境变量里就别用 /usr/libexec/java_home 了直接写 export JAVA_HOME你的自定义路径。4. 多版本 JDK 共存与切换真实开发中的高频需求4.1 一台 Mac 装了多个 JDK怎么互不干扰日常开发中常常要面对这个场景老项目要 JDK 8新项目要 JDK 17或者某个 IDE 插件强制要求 JDK 11。如果你已经在 Mac 上装了多个 JDK比如先装了 JDK 17现在再装 JDK 8那么前面第 2 节里的检查就派上用场了。安装完成后执行/usr/libexec/java_home -V可以看到所有已安装的 JDK 版本和路径。当前命令行的 java 用的是哪个版本取决于 PATH 里哪个 JDK 的 bin 目录排在最前面。而在我们的配置中~/.zshrc 里 export PATH$JAVA_HOME/bin:$PATH 会把 JAVA_HOME 对应的版本放在最前面所以 JAVA_HOME 指向谁java 命令用的就是谁。4.2 我的多版本切换方案alias 配合 java_home既然不同项目需要不同版本手工改 .zshrc 太痛苦。我自己的做法是在 ~/.zshrc 里配置几个 aliasalias jdk8export JAVA_HOME$(/usr/libexec/java_home -v 1.8); export PATH$JAVA_HOME/bin:$PATH; java -version alias jdk17export JAVA_HOME$(/usr/libexec/java_home -v 17); export PATH$JAVA_HOME/bin:$PATH; java -version这样哪天切版本就在终端执行 jdk8 或者 jdk17当前终端窗口立即生效不用退出重开。这个方案的好处是不用安装额外的版本管理工具逻辑直观团队同事接手时也容易理解。缺点是每个新开的终端窗口都会回到默认 JAVA_HOME需要手动再执行一次 alias。如果你对这个“记忆”有要求可以写成更复杂的 zsh 函数每次进入目录自动检测项目需要的 JDK 版本但那就是另一个话题了。如果你需要更多自动化管理macOS 远没有 Linux 的 sdkman 生态强大但 sdkman 也是可以用的。安装 sdkman 后可以执行 sdk install java 8.0.402-tem然后用 sdk use java 8.0.402-tem 随意切换当前 shell 的 JDK。sdkman 适合喜欢命令行管理的用户但它会把 JDK 安装在 ~/.sdkman/candidates/java 而不是系统目录和某些 IDE 的自动检测机制可能不一致。两套方案各有利弊我更推荐先用手动 alias 方案理解原理之后再决定要不要引入工具。4.3 IDE 里 JDK 路径怎么填Mac 用户必看配置好终端后还会遇到一个新手经常问的问题IDEA 或 Eclipse 里要求填 JDK home path到底填哪个答案是 .jdk 文件夹里的 Contents/Home。比如/Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home如果你不想手动记在终端执行/usr/libexec/java_home -v 1.8输出结果就是你要填的路径。注意不要填到 /Library/Java/JavaVirtualMachines 就结束了那只是 JDK 的安装根目录真正的 bin/java 在这层目录的 Contents/Home/bin 下。IDEA 新版本一般也能自动识别但识别失败的场景并不少见手动指定反而最稳。5. 常见报错与排查技巧都是实际会踩的坑5.1 输入 java -version 提示 command not found这是最常见的错误。原因通常有两个一是环境变量没配置终端根本找不到 java 命令二是配置写错了文件比如写到了 ~/.bash_profile 但当前用的是 zsh。排查思路按顺序来先执行 ls /Library/Java/JavaVirtualMachines/确认 JDK 是否真的装了。如果目录为空说明安装没成功重装 dmg。如果目录有 .jdk 文件夹再执行 echo $SHELL 看当前 shell 是什么。如果是 /bin/zsh环境变量就要写在 ~/.zshrc如果是 /bin/bash才写在 ~/.bash_profile。最后检查 ~/.zshrc 文件的语法是否有明显的引号错误很多时候是复制别人的配置时少了反引号。5.2 配置完 JAVA_HOME 后 java 版本还是旧的这个我遇到过好几次。原因多半是机器上本来就装了 JDK 17而且某个工具比如 Homebrew把它的 bin 目录也加到了 PATH 里位置可能在你的配置之前。你可以执行which -a java看看系统找到了几个 java。输出会按 PATH 顺序列出第一个就是当前实际使用的。如果你发现 /usr/bin/java 排在最前面那说明你配置的 PATH 没有覆盖系统默认路径。macOS 系统自带一个 /usr/bin/java 的 stub它本身不算 JDK但会干扰环境变量优先级。解决办法确保 JAVA_HOME 配置在 .zshrc 里并且在 export PATH... 这一行里把 $JAVA_HOME/bin 放在最前面。我习惯写成export PATH$JAVA_HOME/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin而不是简单地在末尾追加。这样只要 JAVA_HOME 正确java 一定优先用 JDK 8。5.3 双击 pkg 安装时提示“无法打开”或“已损坏”这个问题本质上和 JDK 无关而是 macOS Gatekeeper 对未签名 pkg 或下载文件的隔离属性判断。很多开发者第一次遇到都会慌以为安装包有问题。最简单的处理方式右键点击 pkg 文件选择“打开”在弹出窗口里再点一次“打开”往往就能绕过首次弹窗。如果仍然提示已损坏大概率是你的下载过程触发系统隔离标记。可以在终端执行sudo xattr -dr com.apple.quarantine ~/Downloads/你的安装包.pkg这行命令的意思是清除下载文件的隔离属性让系统认为它是本地文件然后重新双击安装。需要注意这一步仅用于官方渠道正常下载的安装包如果你从非官方渠道下载了修改过的安装包这个操作会有安全风险。这也是为什么我一直强调下载渠道要选官方或正规发行版的原因。5.4 Apple Silicon 上装完 JDK 8 后运行异常如果你用的是 M1/M2/M3 芯片且安装了 Oracle JDK 8 的 x64 版本某一些使用 JNI 本地库的项目可能会报这样或那样的底层错误比如找不到 native library 或 UnsatisfiedLinkError。这是因为 x64 版本在 ARM 上通过 Rosetta 转译运行对于纯 Java 应用关系不大但涉及本地方法调用时会有兼容性问题。解决方案有两个一是换用 arm64 原生版本比如 Azul Zulu 8 for macOS (Apple Silicon) 或 Temurin 8 的 aarch64 版本二是给 Terminal 开启“使用 Rosetta 打开”选项让整个终端环境在转译模式下运行。前者更干净因为应用本身以原生架构运行性能更好后者适合你无法更换 JDK 发行版、只能使用特定 Oracle 版本的情况。我自己实测下来Zulu 的 arm64 JDK 8 在 M1 Mac 上运行老项目的 Spring Boot 应用表现稳定和 Intel Mac 上的 Oracle JDK 8 区别感知不明显。所以如果你碰到架构问题不用犹豫直接换发行版。5.5 环境变量配置后终端重启就失效如果你发现当前终端窗口配置好了一关掉重开又不行了那么十有八九是只改了当前 shell 的环境变量而没写入配置文件。有同学会直接在终端执行 export JAVA_HOMExxx看起来有效但那个变量只在当前进程存在新开窗口自然就没了。正确做法是把 export 语句写入 ~/.zshrc保存后执行 source ~/.zshrc。另外注意如果你同时存在 ~/.zshrc 和 ~/.zprofile有些情况下 .zprofile 会在 .zshrc 之前执行如果里面设置了旧的 JAVA_HOME可能会覆盖掉 .zshrc 的值。检查方法很简单打开 .zprofile 看看有没有相关配置有就一起改。6. 安装后的验证清单与个人推荐配置6.1 一个新装好的 JDK 8至少做这 5 项验证安装配置完后不要只看一个 java -version 就说完成。我一般会按这个顺序验证第一java -version 确认当前默认版本确实是 1.8。第二javac -version 确认编译器可用因为有些发行版把 JDK 拆分了只装 JRE 会导致 javac 缺失。第三echo $JAVA_HOME 确认路径存在最好再用 ls 看一下该路径下有没有 bin/java。第四写一个最简单的 Hello.java 编译运行确认 JVM 能真正启动类文件而不是只在命令行工具层面正常。第五在 IDEA 里建一个空 Java 项目把 Project SDK 指到刚装的 JDK运行 main 方法确认 IDE 里的编译运行链路通畅。这五步看着繁琐但能覆盖从命令行到 IDE 的完整开发链路。很多“装好了但项目跑不起来”的后续问题都是因为在某一步偷懒没验证导致问题留到了之后更难排查。6.2 我目前在实际环境中使用的组合前面讲了很多方案最后分享一下我自己比较顺手的组合生产环境老项目用 Azul Zulu 8 for macOS因为它在 Apple Silicon 上有原生支持而且带 JavaFX 相关组件历史项目里偶尔会用到本地新项目用 Homebrew 安装的 openjdk17两个版本通过 alias 切换。日常开发时默认 JAVA_HOME 指向 1.8因为我的大部分工作还是在老项目上。下载安装这块我优先走 .dmg 安装包版本号宁可多花一分钟确认也不要装完再卸。之前踩过一个坑装了某个发行版的 8u202 版本后老项目里用了内部 API结果编译直接报错后来仔细查才发现是更新版本移除了部分包。这类问题从日志上看非常像代码 bug实际原因却让人意想不到所以版本选择上一定要谨慎。另外我会把 .zshrc 中 JDK 相关配置统一放到文件末尾并加上注释分隔线比如# JDK 8 (default) export JAVA_HOME$(/usr/libexec/java_home -v 1.8) export PATH$JAVA_HOME/bin:$PATH # JDK 17 (switch manually) alias jdk17export JAVA_HOME$(/usr/libexec/java_home -v 17); export PATH$JAVA_HOME/bin:$PATH; java -version这样半年后回来改配置一眼就能看明白这些命令是干什么的。开发环境这种事最怕的从来不是不会配而是配完之后自己都忘了当初怎么配的。6.3 关于“安装成功”这件事我的判断标准很多人在 Mac 上装完 JDK看到 java -version 输出版本号就放心了。但我的判断标准是命令行能用、IDE 能用、项目能编译运行三者全部通过才算真正完成。因为实际开发中你大概率不会只用终端敲命令IDEA、Maven、Gradle、Docker 里的 Java 进程都会依赖系统 JDK。如果只验证了前两项后面遇到构建工具找不到 JDK、容器内 java -version 版本不对等问题照样让人抓狂。最后再提一个扩展思路如果你需要经常在多台 Mac 间切换环境可以考虑把 JDK 安装包和 .zshrc 配置沉淀成一份自己的初始化脚本用 Homebrew 批量安装常用工具再配合一份固定不变的配置模板。这样换新机器时执行一次脚本就能把 JDK 8、Git、Maven、IDEA 等环境全部初始化好省掉很多重复劳动。我在实际经历中已经这么维护了两三台开发机效果还挺稳定推荐你也试试。
