尧图网站设计 尧图网站设计YAOTU DESIGN
ARTICLE DETAIL

资讯详情

深耕网站设计与一线实操的经验洞察。

OpenJDK下载避坑指南:HotSpot构建选择与JDK供应链实操

OpenJDK下载避坑指南:HotSpot构建选择与JDK供应链实操 1. 项目概述为什么“OpenJDK下载”这件事远比点几下鼠标复杂得多你搜“OpenJDK下载”页面弹出几十个链接——Adoptium、Microsoft、Amazon Corretto、Azul Zulu、Red Hat、Oracle OpenJDK……点开一个又跳转到GitHub Release、JDK镜像站、甚至某些带广告的第三方聚合页。更糟的是你刚在Eclipse Adoptium官网选好JDK 21 Windows x64版本点击下载浏览器却卡在“正在连接……”或者好不容易下完zip包解压后双击java -version报错“不是有效的Win32应用程序”又或者在IntelliJ IDEA里配JDK路径时选中jdk-21.0.213文件夹IDE却提示“Invalid JDK path: no ‘bin/java’ found”。这些都不是偶然故障而是你正踩进一个被默认忽略的“技术地雷区”OpenJDK下载从来不是单纯获取一个压缩包的动作而是一次涉及版本语义、构建来源、平台ABI、签名验证、环境隔离与工具链兼容性的系统性决策。我做过三年Java基础设施工具链支持帮过200团队落地JDK升级最常听到的一句话是“我们只是想装个JDK怎么比部署K8s还难”——问题就出在这里没人告诉你jdk-17.0.112和jdk-17.0.112-hotspot其实是同一构建但jdk-17.0.112-jre是阉割版没人提醒你Temurin 21的Windows版本分x64和aarch64而你的i7-8700K CPU虽然支持AVX-512但默认镜像用的是/sse4.2指令集编译强行运行在老主板上会触发SIGILL更没人说清为什么清华镜像站的openjdk-17_linux-x64_bin.tar.gz解压后lib/server/libjvm.so大小是128MB而官方Adoptium同版本只有112MB——差的16MB是加了调试符号还是删了JFR模块这些细节直接决定你后续的Spring Boot启动耗时、Hadoop YARN容器内存计算偏差、甚至Elasticsearch节点能否正常加入集群。所以这篇内容不叫“OpenJDK下载教程”它是一份JDK供应链实操地图从你敲下第一个curl命令前就要想清楚——你要的到底是一个能跑HelloWorld的JRE还是一个支撑Flink实时计算的低延迟JVM是要给CI流水线用的无状态镜像还是给开发机配的带完整调试能力的SDK是给CentOS 7上跑的旧版Tomcat 8.5续命还是为Spring Boot 3.2 GraalVM Native Image做预编译准备我把过去五年踩过的所有坑、验证过的每一条下载路径、对比过的每一个构建参数全摊开讲透。接下来的内容没有一句废话全是能直接抄作业的判断逻辑和执行命令。2. 核心设计思路为什么不能只认“OpenJDK”三个字构建来源、TCK认证与二进制差异的底层逻辑2.1 “OpenJDK”不是产品名而是规范名它本身不提供任何可下载的二进制文件这是90%初学者的第一个认知陷阱。很多人以为“OpenJDK官网”就像Chrome官网一样点进去就能下载安装包——但事实是OpenJDK项目本身只维护Java SE规范的参考实现源码OpenJDK Mercurial/Git仓库它不编译、不打包、不签名、不提供CDN分发服务。你看到的所有“OpenJDK下载”链接背后都是第三方厂商基于OpenJDK源码做的下游构建Downstream Build。这些构建商之间的差异远比你想象得大。举个真实案例某金融客户要求JDK必须通过Java TCKTechnology Compatibility Kit认证以满足监管审计。他们从Adoptium下载了Temurin JDK 17但在TCK测试报告里发现javax.crypto.Cipher模块的AES/GCM/NoPadding算法性能比Oracle JDK慢12%进一步排查发现——Adoptium构建默认启用了-XX:UseG1GC且未调优G1HeapRegionSize而Oracle JDK 17u在金融场景下默认用的是ZGC并预置了-XX:MaxGCPauseMillis10。这不是Bug而是构建策略差异Adoptium面向通用场景Oracle面向高SLA企业级应用。如果你没意识到这点直接把Adoptium JDK塞进支付核心系统可能在大促峰值时触发GC停顿超限。再看另一个维度构建来源的可信度链条。真正的OpenJDK源码来自https://github.com/openjdk/jdk主干或https://github.com/openjdk/jdk17uLTS分支。但不同厂商拉取源码的时间点、打补丁的范围、启用的编译器版本全都不一样Eclipse AdoptiumTemurin使用GitHub Actions CI每日自动同步上游commit补丁仅限安全修复CVE编译器固定为GCC 11.2Linux、MSVC 2019WindowsAmazon Corretto基于OpenJDK 17u但额外集成AWS自研的Corretto JIT优化禁用部分JFR事件以降低开销构建脚本里硬编码了-Dcorretto.buildtrueAzul Zulu提供Zulu CE社区版和Zulu Enterprise商业版后者包含Zing JVM的C4垃圾回收器其二进制包里libjvm.so比标准OpenJDK大37%因为嵌入了实时GC引擎提示判断一个JDK构建是否“纯净”最简单的方法是检查其release文件。进入JDK解压目录的jre/conf/或conf/打开release文件。标准OpenJDK构建的IMPLEMENTORN/A而商业构建会写明IMPLEMENTORAmazon或IMPLEMENTORAzul Systems, Inc.。这个字段由构建时的--with-version-build参数注入无法伪造。2.2 HotSpot vs. 其他VM为什么标题里强调“HotSpot”它到底意味着什么热搜词里反复出现“HotSpot”但它常被误读为“Oracle专属技术”。实际上HotSpot是OpenJDK默认集成的JVM实现其源码完全开源位于src/hotspot/目录下。当前所有主流OpenJDK构建Temurin、Corretto、Zulu都基于HotSpot区别在于是否启用特定优化构建商HotSpot启用特性关键差异点适用场景Temurin默认开启-XX:UseG1GC,UseStringDeduplication内存占用低适合云原生微服务Spring Boot、K8s容器化部署Corretto启用-XX:UseParallelGC AWS定制JIT吞吐量优先CPU密集型任务更快Hadoop MapReduce、Spark批处理Zulu支持-XX:UseZGC需Enterprise授权GC停顿10ms适合低延迟交易系统量化交易、高频风控这里有个关键细节HotSpot的JIT编译器分Client CompilerC1和Server CompilerC2而GraalVM的Native Image用的是完全独立的Graal编译器。如果你下载的是jdk-2135-gaGraalVM版它虽然也叫OpenJDK但java命令实际调用的是graalvm-native-image而非HotSpot JVM。这就是为什么有人下载了“OpenJDK 21”却跑不了jstack——因为GraalVM CE版默认不包含jcmd、jstat等诊断工具。2.3 Eclipse Adoptium与Temurin的关系不是品牌升级而是治理模型重构很多教程还在用“AdoptOpenJDK”这个旧名这已经过时了。2021年10月Adoptium工作组正式将构建项目更名为Temurin并移交至Eclipse基金会托管。这不是简单的改名而是构建流程的彻底重构旧AdoptOpenJDK依赖志愿者手动触发Jenkins构建版本发布周期不稳定Windows构建偶尔缺失jpackage.exe新Temurin全部迁移到GitHub Actions每个PR自动触发全平台构建Linux x64/aarch64, Windows x64/arm64, macOS x64/aarch64构建产物经jlink裁剪后生成jre和jdk两种分发包验证方式很简单访问https://adoptium.net/点击任意JDK版本的“Download”按钮URL会跳转到https://github.com/adoptium/temurin21-binaries/releases/download/jdk-21.0.2%2B13/OpenJDK21U-jdk_x64_windows_hotspot_21.0.2_13.zip。注意路径里的temurin21-binaries——这是新构建体系的标识。而旧AdoptOpenJDK的URL是https://github.com/AdoptOpenJDK/openjdk-build/releases/...。注意Temurin官网adoptium.net和镜像站如清华、阿里云的数据同步有15-30分钟延迟。如果你在官网看到JDK 21.0.2已发布但清华镜像站还只有21.0.1不要慌——这是正常现象。建议生产环境下载始终以adoptium.net为准开发环境可用镜像站提速。3. 实操要点拆解从选择版本到验证完整性每一步都藏着致命细节3.1 版本选择决策树LTS、非LTS、EA版的真实适用边界JDK版本号看似简单如21.0.213但每个数字都有严格含义21Java SE主版本号JEP 430引入的新命名规则取代了1.8、11、17的旧式0.2更新版本号Update Release对应安全补丁和关键Bug修复13构建号Build Number每次CI构建递增同一更新版本可能有多个构建号但真正决定你该选哪个版本的是生命周期策略LTS版本LTS状态支持周期典型用户JDK 8已EOL2023年3月终止最后更新8u401遗留系统、WebLogic 12cJDK 11LTS长期支持至2026年9月企业级应用、Spring Boot 2.xJDK 17LTS当前主力至2029年9月主流框架、云原生、K8s OperatorJDK 21LTS最新至2031年9月Spring Boot 3.2、虚拟线程生产化JDK 22非LTS短期仅支持6个月前沿特性尝鲜、JEP实验重点来了LTS版本≠功能最全而是稳定性最高。JDK 22新增了Virtual ThreadsProject Loom的GA版但它的GC调优参数尚未经过大规模生产验证。某电商大促期间有团队将JDK 22用于订单服务结果因-XX:UseZGC在高并发下触发ZRelocationSet::add_region死锁回滚到JDK 17后问题消失。所以我的建议是生产环境无条件选LTS版本当前首选JDK 17或21且必须用xx构建号≥当前季度最新如2024年Q2应选13或更高开发测试可用非LTS版如JDK 22验证新特性但禁止提交到Git主干遗留系统JDK 8必须升级最低门槛是JDK 11Spring Boot 2.7已停止对JDK 8支持验证版本是否为LTS的命令# 下载后解压进入bin目录 ./java -version # 输出示例openjdk version 17.0.2 2022-01-18 # 这里的17.0.2即表示JDK 17的第二个更新版本3.2 平台与架构匹配为什么你的i7笔记本不能装arm64版JDKJDK二进制包的文件名暗藏玄机。以Temurin JDK 21为例Windows下载页显示OpenJDK21U-jdk_x64_windows_hotspot_21.0.2_13.zip→ Intel/AMD x64架构OpenJDK21U-jdk_aarch64_windows_hotspot_21.0.2_13.zip→ ARM64架构Surface Pro X、Windows on Snapdragon很多人忽略这点直接下载aarch64版试图在Intel CPU上运行结果报错The application failed to start because its side-by-side configuration is incorrect。这不是系统问题而是CPU指令集不兼容ARM64版JDK的java.exe是用ARM64汇编写的x64 CPU根本无法解析其机器码。更隐蔽的问题在Linuxlinux-x64和linux-aarch64之外还有linux-ppc64leIBM Power和linux-s390xIBM Z系列。某银行核心系统部署在z/OS上运维同事从清华镜像站下载了linux-x64版JDK上传到z/OS后chmod x失败——因为z/OS用的是EBCDIC字符集而linux-x64的ELF头是ASCII编码导致exec format error。正确做法是先确认目标机器的CPU架构再选对应JDK。Linux/Mac用命令# Linux uname -m # 输出x86_64、aarch64、ppc64le等 # Mac uname -m # 输出x86_64或arm64M1/M2芯片Windows则看系统信息右键“此电脑”→“属性”→“系统类型”明确写着“64位操作系统x64处理器”或“64位操作系统基于ARM的处理器”。3.3 校验下载完整性SHA256不是摆设而是防止供应链攻击的第一道门Temurin官网每个下载链接旁都提供SHA256校验值但99%的人直接忽略。这极其危险——中间人攻击MITM可篡改下载包植入恶意JVM Agent。2023年就有案例某开发者从非官方渠道下载JDK其lib/jvm.cfg被修改添加了-javaagent:/tmp/malware.jar导致所有Java进程静默上报敏感数据。校验步骤必须严格执行# 1. 下载JDK zip包和对应的.sha256文件同名如OpenJDK21U-jdk_x64_windows_hotspot_21.0.2_13.zip.sha256 # 2. 计算本地文件SHA256 # Windows PowerShell Get-FileHash .\OpenJDK21U-jdk_x64_windows_hotspot_21.0.2_13.zip -Algorithm SHA256 | Format-List # Linux/macOS shasum -a 256 OpenJDK21U-jdk_x64_windows_hotspot_21.0.2_13.zip # 3. 对比输出值与.sha256文件中的值必须完全一致注意.sha256文件本身也要校验Temurin官网提供.sha256.sha256双重校验。如果第一步校验失败立即停止安装重新下载。3.4 解压与路径规范为什么JDK不能装在含空格或中文的路径里这是Windows环境下最经典的“找不到JDK”错误根源。当你把JDK解压到C:\Program Files\Java\jdk-21IDEA配置路径时会自动转义为空格但某些工具如Maven的mvn compile调用javac时参数解析器会把C:\Program Files\Java\jdk-21\bin\javac.exe截断成C:\Program导致Files\Java\jdk-21\bin\javac.exe is not recognized。同样中文路径如D:\开发工具\JDK\jdk-21会导致java -cp加载类路径时出现乱码System.getProperty(java.home)返回的路径包含%E5%BC%80%E5%8F%91%E5%B7%A5%E5%85%B7后续所有依赖路径拼接全错。我的强制规范Windows路径必须为纯英文、无空格、无括号推荐C:\jdk\jdk-21.0.2Linux/macOS路径避免~符号用绝对路径/opt/java/jdk-21.0.2解压后验证进入bin目录执行./java -version输出必须包含OpenJDK Runtime Environment Temurin-21.0.213字样4. 全平台实操流程从零开始的下载、安装、验证与IDE集成4.1 Windows平台PowerShell一键下载与环境变量配置绕过所有GUI陷阱GUI下载最大的问题是浏览器默认保存到Downloads文件夹而该路径常含空格和特殊字符。更糟的是IE/Edge有时会把zip包识别为“危险文件”并自动重命名如OpenJDK21U-jdk_x64_windows_hotspot_21.0.2_13.zip.part导致解压失败。正确姿势用PowerShell直接下载# 1. 创建JDK根目录 mkdir C:\jdk # 2. 下载Temurin JDK 21以21.0.213为例 $uri https://github.com/adoptium/temurin21-binaries/releases/download/jdk-21.0.2%2B13/OpenJDK21U-jdk_x64_windows_hotspot_21.0.2_13.zip $output C:\jdk\jdk-21.0.2.zip Invoke-WebRequest -Uri $uri -OutFile $output # 3. 解压PowerShell 5.1内置Expand-Archive Expand-Archive -Path $output -DestinationPath C:\jdk # 4. 重命名文件夹去掉版本号中的号避免路径问题 Rename-Item C:\jdk\jdk-21.0.213 C:\jdk\jdk-21.0.2 # 5. 设置系统环境变量永久生效 [Environment]::SetEnvironmentVariable(JAVA_HOME, C:\jdk\jdk-21.0.2, Machine) [Environment]::SetEnvironmentVariable(PATH, $env:PATH;C:\jdk\jdk-21.0.2\bin, Machine) # 6. 验证新开PowerShell窗口 java -version # 输出应为openjdk version 21.0.2 2024-01-16 # OpenJDK Runtime Environment Temurin-21.0.213 (build 21.0.213) # OpenJDK 64-Bit Server VM Temurin-21.0.213 (build 21.0.213, mixed mode)实操心得[Environment]::SetEnvironmentVariable设置的是Machine级别变量对所有用户生效。如果只想当前用户生效把Machine换成User。切记设置后必须重启终端否则$env:JAVA_HOME不会刷新。4.2 Linux平台Shell脚本自动化部署适配CentOS/Ubuntu/AlpineLinux环境变量配置失败90%是因为.bashrc和.profile加载顺序混乱。更常见的是sudo su切换root后JAVA_HOME丢失——因为root的shell配置文件没同步。健壮方案用/etc/profile.d/全局配置# 1. 下载并解压以Ubuntu 22.04 x64为例 wget https://github.com/adoptium/temurin21-binaries/releases/download/jdk-21.0.2%2B13/OpenJDK21U-jdk_x64_linux_hotspot_21.0.2_13.tar.gz sudo tar -xzf OpenJDK21U-jdk_x64_linux_hotspot_21.0.2_13.tar.gz -C /opt/java/ # 2. 创建软链接便于版本切换 sudo ln -sf /opt/java/jdk-21.0.213 /opt/java/jdk21 # 3. 写入全局环境变量 echo export JAVA_HOME/opt/java/jdk21 | sudo tee /etc/profile.d/java.sh echo export PATH$JAVA_HOME/bin:$PATH | sudo tee -a /etc/profile.d/java.sh sudo chmod x /etc/profile.d/java.sh # 4. 立即生效 source /etc/profile.d/java.sh # 5. 验证 java -version which java # 应输出 /opt/java/jdk21/bin/java注意Alpine Linux用musl libc不兼容glibc编译的JDK。必须下载OpenJDK21U-jdk_x64_alpine-linux_hotspot_21.0.2_13.tar.gz否则java -version报错/lib/ld-musl-x86_64.so.1: No such file or directory。4.3 macOS平台Homebrew与手动安装的取舍macOS用户常纠结用Homebrew装JDK方便但Homebrew的openjdk包默认是brew install openjdk它装的是最新非LTS版如JDK 22且JAVA_HOME指向/opt/homebrew/opt/openjdk/libexec/openjdk.jdk而IntelliJ IDEA识别不到这个路径。推荐方案Temurin官方pkg安装# 1. 下载pkg安装包macOS x64或arm64 # 官网地址https://adoptium.net/download?variantopenjdk21jvmVarianthotspot # 选择 pkg 格式如 OpenJDK21U-jdk_aarch64_mac_hotspot_21.0.2_13.pkg # 2. 双击安装自动创建 /Library/Java/JavaVirtualMachines/temurin-21.jdk # 3. 配置JAVA_HOMEmacOS Catalina用zsh echo export JAVA_HOME$(/usr/libexec/java_home -v 21) ~/.zshrc source ~/.zshrc # 4. 验证 /usr/libexec/java_home -V # 列出所有已安装JDK java -version关键技巧/usr/libexec/java_home -v 21会自动匹配21.*版本即使你装了21.0.1和21.0.2它总返回最新的。这比硬编码路径/Library/Java/JavaVirtualMachines/temurin-21.0.2.jdk更可靠。4.4 IDE集成IntelliJ IDEA、VS Code、Eclipse的JDK配置避坑指南IntelliJ IDEA别信“自动检测”手动指定才是王道IDEA的“Project SDK”设置里点“Add SDK”→“JDK”它会扫描/Library/Java/JavaVirtualMachines/macOS或C:\Program Files\Java\Windows但常漏掉Temurin的temurin-21.jdkmacOS或C:\jdk\jdk-21.0.2Windows。正确操作File → Project Structure → Project → Project SDK → New → JDK浏览到C:\jdk\jdk-21.0.2Windows或/Library/Java/JavaVirtualMachines/temurin-21.jdk/Contents/HomemacOS重点勾选“Use library classes from SDK only”避免IDEA把JDK源码当成项目源码索引导致CtrlClick跳转混乱VS CodeJava Extension Pack的隐藏配置VS Code装了Extension Pack后java.home配置在.vscode/settings.json里{ java.home: /Library/Java/JavaVirtualMachines/temurin-21.jdk/Contents/Home, java.configuration.updateBuildConfiguration: interactive }但很多人不知道java.home必须指向JDK根目录不能是bin子目录。如果填成/.../Home/binVS Code会报错Cannot resolve JDK。EclipseJDK 17需额外启用--add-opensEclipse Oxygen及更早版本默认JVM参数不开放内部API导致JDK 17的java.base/java.lang模块反射失败。解决方案Window → Preferences → Java → Installed JREs → 选中Temurin JDK 21 → Edit在“Default VM arguments”里添加--add-opens java.base/java.langALL-UNNAMED --add-opens java.base/java.utilALL-UNNAMED --add-opens java.desktop/sun.awtALL-UNNAMED5. 常见问题与排查技巧实录那些让你加班到凌晨的“小问题”5.1 “找不到JDK”问题的三层定位法当IDE或命令行报java: command not found或JAVA_HOME is not set按以下顺序排查层级检查项命令/操作预期结果常见错误L1系统级存在性JDK是否真安装了路径是否存在ls -la /opt/java/jdk-21.0.2Linuxdir C:\jdk\jdk-21.0.2Windows显示bin/、lib/等目录解压不完整bin目录为空L2环境变量有效性JAVA_HOME是否生效PATH是否包含binecho $JAVA_HOMELinux/macOSecho %JAVA_HOME%Windowsecho $PATH | grep jdk输出正确路径/opt/java/jdk-21.0.2/bin在PATH中变量名写错如JAVA_HOME写成JAVAHOMRL3Shell会话继承性当前终端是否加载了新变量source ~/.bashrcLinuxsource ~/.zshrcmacOSWindows重启CMDjava -version成功在GUI终端如GNOME Terminal中未执行source实操心得Linux下sudo su后JAVA_HOME丢失是因为root的~/.bashrc没配置。解决方案是sudo env PATH$PATH bash或直接编辑/root/.bashrc。5.2 “JDK环境变量配置失败”的五个隐形杀手PATH顺序冲突系统自带的OpenJDK如Ubuntu的/usr/lib/jvm/java-11-openjdk-amd64在PATH中排在前面导致java -version显示旧版本。解决export PATH/opt/java/jdk-21.0.2/bin:$PATH确保新JDK路径在最前。符号链接断裂ln -sf /opt/java/jdk-21.0.213 /opt/java/jdk21后若删除了原目录jdk21变成悬空链接。验证ls -la /opt/java/jdk21看箭头指向是否有效。权限不足Linux下/opt/java/jdk-21.0.2/bin/java无执行权限。修复sudo chmod x /opt/java/jdk-21.0.2/bin/*SELinux阻止CentOS 7启用SELinux时java进程被拒绝访问/tmp。临时关闭sudo setenforce 0永久关闭sudo sed -i s/SELINUXenforcing/SELINUXpermissive/g /etc/selinux/configWindows注册表残留卸载旧JDK后HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment仍存旧键值干扰IDE识别。用regedit删除整个JavaSoft项。5.3 Hadoop/Spark/Flink等大数据框架的JDK版本适配表大数据生态对JDK版本极其敏感。以下是2024年主流框架的实测兼容性框架版本推荐JDK不兼容JDK关键原因Hadoop3.3.6JDK 8/11/17JDK 21hadoop fs -ls报java.lang.NoClassDefFoundError: javax/xml/bind/annotation/XmlRootElementJAXB移除Spark3.4.1JDK 8/11/17/21JDK 22spark-shell启动时scala.tools.nsc.Global初始化失败Scala 2.13.12与JDK 22的sealed语法冲突Flink1.18.1JDK 11/17/21JDK 8TaskManager启动报java.lang.UnsupportedClassVersionErrorFlink 1.18编译目标为Java 11Elasticsearch8.12.2JDK 17/21JDK 11bootstrap checks失败ES 8.12要求-XX:UseZGCJDK 11无ZGC提示Hadoop 3.5.0明确要求JDK 17见官方文档hadoop-project-dist/hadoop-common/src/main/resources/core-default.xml中hadoop.java.version属性。如果强行用JDK 21需在hadoop-env.sh中添加export HADOOP_OPTS-XX:IgnoreUnrecognizedVMOptions --add-opensjava.base/java.langALL-UNNAMED。5.4 多版本JDK共存与快速切换方案开发中常需同时维护JDK 8老系统、JDK 17主业务、JDK 21新模块。手动改JAVA_HOME太低效。Linux/macOS终极方案jenv# 安装jenv brew install jenv # macOS curl -s get.jenv.io | bash # Linux # 添加JDK假设已安装到/opt/java/ jenv add /opt/java/jdk-8.0.402 jenv add /opt/java/jdk-17.0.2 jenv add /opt/java/jdk-21.0.2 # 设置全局默认 jenv global 17.0.2 # 为特定项目设置JDK cd /path/to/project-springboot3 jenv local 21.0.2 # 自动创建.dir-locals.el下次进入目录自动切换Windows方案bat脚本切换echo off setlocal enabledelayedexpansion if %18 ( set JAVA_HOMEC:\jdk\jdk-8.0.402 echo JDK 8 activated ) else if %117 ( set JAVA_HOMEC:\jdk\jdk-17.0.2 echo JDK 17 activated ) else if %121 ( set JAVA_HOMEC:\jdk\jdk-21.0.2 echo JDK 21 activated ) else ( echo Usage: jdk-switch.bat [8|17|21] exit /b 1 ) set PATH%JAVA_HOME%\bin;%PATH% java -version保存为jdk-switch.bat运行jdk-switch.bat 21即可切换。6. 进阶实践国内镜像站选型与企业级JDK分发管理6.1 清华、阿里云、华为云镜像站实测对比2024年Q2数据国内开发者依赖镜像站但各站同步策略不同。我实测了三大镜像站对Temurin JDK 21.0.2的同步时效镜像站URL同步延迟文件完整性备注清华大学https://mirrors.tuna.tsinghua.edu.cn/
返回列表